Reverse DNS and PTR Records: How They Work and Why Mail Servers Check Them

A normal ("forward") DNS lookup turns a name into an address: dns.google → 8.8.8.8. A reverse lookup goes the other way: given 8.8.8.8, which hostname does it belong to?

$ dig -x 8.8.8.8 +short
dns.google.

The answer comes from a PTR (pointer) record. Unlike most DNS records, PTR records are not published in the zone of the domain they point to. They live in a special part of the DNS tree built from the IP address itself.

To look up the PTR for 8.8.8.8, the resolver reverses the octets and appends in-addr.arpa:

$ dig -x 8.8.8.8
;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.  80963  IN  PTR  dns.google.

The octets are reversed because DNS names become more specific from right to left (www.example.com), while IP addresses become more specific from left to right. Reversing them lets the DNS delegate authority the same way IP space is allocated: IANA delegates 8.in-addr.arpa toward a regional registry, the registry delegates a block to the organisation that holds it, and that organisation publishes the individual PTR records.

IPv6 uses ip6.arpa and reverses every hex nibble, which produces long names — dig -x 2001:4860:4860::8888 queries a name with 32 labels — but the principle is identical.

The consequence: the PTR record for an IP is controlled by whoever holds the IP block, not whoever owns the domain. You can't add a PTR record in your domain's DNS settings. For a home connection that's your ISP; for a cloud server it's the cloud provider; for a dedicated server it's the hosting company.

Anyone who controls an IP block can make its PTR record say anything — including mail.google.com. A PTR record on its own proves nothing.

Forward-confirmed reverse DNS closes that gap with a second lookup:

1. Look up the PTR for the IP: 8.8.8.8 → dns.google.
2. Look up the A (or AAAA) records for that hostname: dns.google → 8.8.8.8, 8.8.4.4.
3. If the original IP is in that list, the reverse DNS is forward-confirmed.

$ dig dns.google A +short
8.8.8.8
8.8.4.4

8.8.8.8 is in the list, so it passes. The check works because the forward record is controlled by the domain owner. For both lookups to agree, the IP owner and the domain owner must have set them up together.

The Reverse DNS Lookup does both steps for every PTR the IP returns and shows whether each one forward-confirms.

Reverse DNS matters most for email. Most receiving mail servers look up the PTR of the connecting IP before accepting a message, and many reject or heavily penalise mail from an IP with no PTR or one that doesn't forward-confirm.

Google's sender guidelines require it outright: sending IPs must have a PTR record that resolves to a hostname whose A or AAAA record points back to the same IP. Failing that causes rejections or spam-foldering at Gmail regardless of SPF, DKIM or DMARC. The why emails go to spam guide covers the rest of the requirements.

Mail servers also look at what the hostname says. A PTR like 203-0-113-45.dynamic.example-isp.net signals a residential connection, and many spam filters block mail from dynamic-looking hostnames outright. A good mail server PTR:

• Forward-confirms.
• Is a name in a domain you control, such as mail.example.com.
• Matches, or is closely related to, the hostname the server announces in its SMTP HELO/EHLO greeting.

It doesn't have to match the domain in your From address — one server can send for many domains — but it should look like a deliberately configured mail server, not a home connection.

Readable logs and traceroutes. Network tools show PTR names instead of bare IPs, and those names often encode useful information. Backbone router names commonly include an airport code or city and an interface name, so a traceroute through ae-1.r21.lon01.example.net tells you the path went through London.

Verifying search engine crawlers. Anyone can put "Googlebot" in a User-Agent string. Google's documented way to verify a real Googlebot is FCrDNS: the PTR of the requesting IP must end in googlebot.com, google.com or googleusercontent.com, and that hostname must resolve back to the same IP. Bing documents the same method with search.msn.com.

One IP, many names. An IP can have more than one PTR record. Some shared IPs return dozens, which is technically valid but makes the result less meaningful, and some software only reads the first. For a mail server, publish exactly one.

No PTR at all is normal for many IPs. Plenty of consumer, mobile and cloud addresses have no reverse record or a generic auto-generated one. That's fine for browsing; it only matters if the IP sends email or needs to be identified.

Because the PTR lives with the IP's owner, the steps depend on where the IP comes from:

Cloud providers let you set it yourself for addresses you've reserved. AWS lets you set reverse DNS on Elastic IPs from the console (sending mail on port 25 still needs a separate request to lift its default limit); Google Cloud, Azure, DigitalOcean, Hetzner, Linode and Vultr all expose a reverse DNS or PTR field in the console or API. Most require the forward A record to exist first, so they can confirm you control the name.

Dedicated servers and colocation: ask the hosting company, or use their control panel if it has a reverse DNS option.

Business internet connections with static IPs: the ISP sets it on request. Some ISPs will delegate the reverse zone for a larger block to your own nameservers.

Residential connections: you generally can't, and dynamic IPs shouldn't be sending mail directly anyway. Send through your provider's or a mail service's SMTP relay.

The order that works every time:

1. Create the forward record: mail.example.com A 203.0.113.10.
2. Set the PTR for 203.0.113.10 to mail.example.com with whoever owns the IP.
3. Wait for the TTLs to expire, then run the Reverse DNS Lookup and confirm the result shows a forward-confirmed match.