Based on RFC 1035 for the PTR record and the in-addr.arpa domain, RFC 8499 for the reverse DNS terminology, and RFC 1912 for forward and reverse consistency.
A PTR record maps an IP address back to a hostname. It is the reverse of an A record. An A record answers "what is the address for this name?", and a PTR record answers "what is the name for this address?".
PTR stands for Pointer, and the record is defined in RFC 1035 Section 3.3.12. PTR records make reverse DNS work: they live in a special zone, in-addr.arpa for IPv4 and ip6.arpa for IPv6, where the lookup runs from address to name instead of name to address.
Here is the part most search results bury. The reason people end up reading about PTR records is almost always email. A receiving mail server checks the reverse DNS of the IP that just connected to it, and a missing or sloppy PTR record is one of the fastest ways to get your mail rejected or filed as spam. We see the other side of this every day: DMARCTrust runs a reverse DNS (PTR) lookup on every sending IP in your DMARC reports to figure out which server sent each message, so we will use that worked example later.
What you will learn
A PTR record, in plain language
Most DNS records run forward: you start with a name and ask for data. A PTR record runs the other way. You start with an IP address and ask "which hostname claims this address?". RFC 1035 defines the PTR resource record as a domain name that "points to some location in the domain name space," and reverse DNS is the main thing it is used for.
Compare the two directions with one host:
Notice the PTR record does not store the IP as you normally write it. It lives at a name built from the address, written backwards, with in-addr.arpa on the end. The next section explains why.
Why the address is written backwards: in-addr.arpa
DNS reads names from most specific on the left to least specific on the right. mail.example.com narrows from the com top level, down to example, down to the mail host. IPv4 addresses read the opposite way: the left-most octet is the most general (the network), the right-most is the most specific (the host).
To fit IP addresses into the name tree, RFC 1035 Section 3.5 reverses the octets and appends the special domain in-addr.arpa. The RFC's own example: data for the address 10.2.0.52 lives at 52.0.2.10.in-addr.arpa. The reversal, in the RFC's words, "though awkward to read, allows zones to be delegated which are exactly one network of address space." In plain terms: it lets the owner of a network block control the reverse records for just their addresses, the same way the owner of a domain controls names under it.
IPv6 uses the same idea in the ip6.arpa zone, but every single hex digit of the fully expanded address becomes its own label, reversed. That is why IPv6 reverse names are long. You rarely type them by hand; tools and provider control panels build them for you.
FCrDNS: the check mail servers actually run
A PTR record on its own proves nothing. Anyone who controls a reverse zone can point an IP at any name they like, including a name they do not own. So a receiving mail server does not trust a PTR record by itself. It runs Forward-Confirmed reverse DNS (FCrDNS), a two-step check that makes the two directions agree.
If step 2 returns a different IP, or the hostname has no A record at all, FCrDNS fails. The check is cheap, hard to fake without controlling both the forward zone and the reverse zone, and it weeds out the large share of spam that comes from IPs with no reverse DNS or with generic, auto-generated names. RFC 1912 puts the underlying expectation bluntly: "Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all."
PTR records and email deliverability
Reverse DNS has been an informal sender-quality signal for decades. In February 2024 it became a hard rule at the two largest consumer mailbox providers.
| Provider | PTR requirement |
|---|---|
| Every sending IP must have "valid forward and reverse DNS records, also called PTR records," and the sending IP must match the hostname in its PTR record. This is in the requirements for all senders, repeated for senders of 5,000+ messages a day. | |
| Yahoo | "Publish valid, meaningful, non-generic reverse DNS (PTR) records for all of your sending IPs." Yahoo adds that reverse DNS should reflect your domain and not look like a dynamically-assigned IP. |
Three failure modes get mail penalized, in rough order of how often we see them:
- No PTR record at all. The sending IP has nothing in the reverse zone. Receivers see an anonymous IP and discount it.
-
Generic PTR record. The reverse name is the provider's default, something like
192-0-2-10.static.example-isp.net. It exists, but it says "leased IP," not "mail server," which is exactly what Yahoo warns against. - FCrDNS mismatch. A PTR record exists, but the hostname it names does not resolve back to the same IP, so the forward-confirm step fails.
Most people never set a PTR record. If you send through Google Workspace, Microsoft 365, or an email service provider like SendGrid, Mailgun, or Amazon SES, those providers own the sending IPs and already publish correct PTR records on them. You only configure a PTR record when you run your own mail server on an IP you control. If that is not you, this is a thing to understand, not a thing to fix.
Who controls your PTR record
This is the single biggest source of confusion. A PTR record is not set where the rest of your DNS lives. The reverse zone for an IP range is delegated to the organization that owns the addresses, normally your hosting provider, cloud platform, or ISP. Your domain registrar cannot touch it.
So the workflow is different from every other record in this documentation:
- To set an A, MX, TXT, or CNAME record, you edit your domain's DNS zone.
- To set a PTR record, you ask the owner of the IP, usually through a control-panel field labeled "Reverse DNS" or "rDNS," or by opening a support request.
People lose hours here. They add a record to their forward zone, the reverse lookup still returns the provider default, and nothing they do in their registrar changes it, because the PTR record lives in a zone they were never delegated.
Mistakes that break a PTR record
Pointing a PTR record at a CNAME
RFC 1912 Section 2.4 is explicit: "PTR records must point back to a valid A record, not a alias defined by a CNAME." Point your PTR at the real, canonical hostname that has its own A or AAAA record resolving back to the same IP. If the target is itself a CNAME, reverse DNS checks can fail.
Forgetting an IP on a multi-homed server
If a mail server sends from more than one IP, every sending IP needs its own matching PTR record. RFC 1912 calls this out directly: "If a host is multi-homed... make sure that all IP addresses have a corresponding PTR record (not just the first one)." A server that sends from a second IP with no reverse DNS will see intermittent, hard-to-diagnose deliverability problems.
Setting the PTR but not the matching forward record
A PTR record only passes FCrDNS if the hostname it names has a forward A or AAAA record pointing back to the same IP. Set both sides. Setting the reverse and forgetting the forward is the most common reason a "configured" PTR still fails the check.
How DMARCTrust uses PTR records in your reports
Here is the operator's-eye view. A DMARC aggregate report lists the source IP addresses that sent mail claiming to be from your domain, but it does not tell you which server each IP is. A raw report is a wall of numbers like 209.85.220.41.
To turn those numbers into something readable, DMARCTrust runs a reverse DNS (PTR) lookup on every sending IP in your reports. When the IP has a PTR record, we get a hostname back, derive the sending domain from it, and match it to a known email provider, so you see "Google" instead of an opaque address. When an IP has no PTR record, we record that too, which is itself a useful signal: a sender with no reverse DNS is worth a second look.
That is the same FCrDNS-adjacent identity check a receiving mail server runs, applied to the senders in your own reports. It is why your source insights can name the services sending as your domain instead of leaving you to look up each IP by hand.
One thing we do not do: the free domain checker inspects the published records on a domain (DMARC, SPF, DKIM, MX), not the reverse DNS of your own mail server's IP. To verify your own PTR record, query it directly with dig -x <your-ip>, or ask the provider that owns the IP.
How to check a PTR record yourself
A reverse DNS lookup is one command. On macOS or Linux:
On Windows, nslookup 192.0.2.10 does the reverse lookup. If dig -x returns nothing, the IP has no PTR record. If it returns a generic, ISP-style name, that is the "non-generic" problem Yahoo flags. If the forward lookup returns a different IP than you started with, FCrDNS fails.
Frequently asked questions
What is the difference between an A record and a PTR record?
An A record maps a hostname to an IPv4 address (AAAA does the same for IPv6); a PTR record does the reverse, mapping an IP address back to a hostname. They also live in different places. A and AAAA records are in your normal forward zone, while PTR records are in the reverse zone (in-addr.arpa or ip6.arpa) controlled by whoever owns the IP block.
Do I need a PTR record to send email?
If you run your own mail server, yes. Since February 2024, Google and Yahoo require every sending IP to have valid forward and reverse DNS, and Google requires the IP to match the hostname in its PTR record. If you send through Google Workspace, Microsoft 365, or an email service provider, that provider already publishes the PTR record on its sending IPs, so you do not set one yourself.
What is FCrDNS?
Forward-Confirmed reverse DNS. A reverse (PTR) lookup turns the sending IP into a hostname, then a forward (A or AAAA) lookup of that hostname must resolve back to the same IP. When both agree, the IP passes. Mail servers use it as a low-cost identity check on the server connecting to them.
Who sets my PTR record?
Whoever controls the IP block, not whoever runs your DNS. The reverse zone is delegated to the owner of the addresses, usually your hosting provider, cloud platform, or ISP. You ask them, often through a "Reverse DNS" or "rDNS" field, not your domain registrar.
Does a PTR record affect DMARC?
Not directly. DMARC checks SPF and DKIM alignment against the From header domain and does not read PTR records. But both point the same way for deliverability, and DMARC aggregate reports list the sending IPs, which you can reverse-resolve to identify each sender. DMARCTrust runs that PTR lookup for you on every sender IP in your reports.
Related guides and resources
Standards and specifications
- RFC 1035 - Domain Names, Implementation and Specification (PTR in Section 3.3.12, in-addr.arpa in Section 3.5)
- RFC 8499 - DNS Terminology (reverse DNS, reverse lookup)
- RFC 1912 - Common DNS Operational and Configuration Errors (PTR and A consistency, Sections 2.1 and 2.4)
- RFC 3596 - DNS Extensions to Support IP Version 6 (ip6.arpa reverse zone)
Tools
- DMARC checker - inspect the DNS and authentication records on any domain
- MX lookup - see the mail servers a domain publishes
- DMARC record generator - build your DMARC TXT record step by step