Normal DNS turns a name into an address. Reverse DNS does the opposite: you hand it an IP address and it tells you what name that address claims. For browsing it barely matters, but for email it can decide whether your messages arrive at all, and the record lives somewhere most people never think to look.
There's no separate reverse DNS system. It's ordinary DNS with a trick in the naming. An IPv4 address is written backwards, octet by octet, and put under a special domain called in-addr.arpa. So a lookup for 192.0.2.25 becomes a query for a PTR record at:
25.2.0.192.in-addr.arpaThe reversal exists because DNS delegates from right to left (.com, then example.com, then www.example.com), while IP addresses get more specific from left to right. Flipping the address lets the owner of 192.0.2.0/24 be delegated the 2.0.192.in-addr.arpa zone, just like a domain.
IPv6 does the same thing under ip6.arpa, except every hex digit (nibble) is reversed separately. 2001:db8::25 expands to 32 nibbles and becomes a very long name ending in 8.b.d.0.1.0.0.2.ip6.arpa. Nobody types those by hand, which is why the tools do it for you.
The quickest way is our reverse DNS lookup, which takes an IP and returns the hostname. From a terminal, any of these work:
dig -x 192.0.2.25 +short
nslookup 192.0.2.25
host 192.0.2.25dig -x builds the in-addr.arpa name for you. If it prints nothing, there's no PTR record. For a real-world comparison, dig -x 8.8.8.8 +short returns dns.google., which is what a tidy setup looks like.
A PTR record on its own proves very little, though, for a reason that trips people up.
Your domain's DNS host controls forward records like A and MX. It does not control reverse DNS. The in-addr.arpa zone for an address belongs to whoever owns the IP block, which means your ISP, your hosting company or your cloud provider.
That has two consequences. First, you can't add a PTR record in the same panel as your A records, however hard you look. Second, anyone who controls an IP block can set its PTR to any name they like, including yours. There's nothing stopping the owner of 198.51.100.7 pointing it at mail.example.com without your permission.
This is why mail servers don't trust the PTR alone. They do forward-confirmed reverse DNS: look up the PTR, then resolve that hostname forward and check it returns the original IP. The second step only passes if the domain owner has also published a matching A (or AAAA) record, so the two sides have to agree. I covered the same round-trip technique for verifying crawlers, and it works for exactly the same reason.
Where to actually set it:
mail.example.com.host-192-0-2-25.dynamic.example.net, and most consumer ISPs won't change it. That's a strong hint you shouldn't be running a mail server there anyway.in-addr.arpa zone. For blocks smaller than a /24, RFC 2317 describes the CNAME trick ISPs use to delegate reverse DNS for part of a /24.Spam from infected home machines and throwaway servers has one thing in common: nobody bothered with reverse DNS. Checking for it is cheap and removes a lot of junk, so receivers lean on it.
Google is explicit. Its sender guidelines apply to everyone sending to Gmail, not only bulk senders, and say the public IP of a sending server must have a PTR record that resolves to a hostname, with forward and reverse lookups matching. Mail over IPv6 gets a specific rejection message about PTR records and authentication, so a server that sends over IPv6 needs a PTR on its IPv6 address too, not just the IPv4 one.
Many self-hosted mail servers enforce the same thing. Postfix, for example, has two options. reject_unknown_reverse_client_hostname rejects a client whose IP has no PTR at all. The stricter reject_unknown_client_hostname also rejects when the PTR name doesn't resolve forward, or resolves to a different address. Both default to a temporary 450 reply, so the sender sees delays and retries before the eventual bounce.
Even where it isn't a hard rule, a missing or generic PTR feeds into the spam score. If you're working through a deliverability problem, it belongs on the same checklist as the items in why emails go to spam.
For a mail server, aim for all of these to line up:
mail.example.com.HELO/EHLO greeting. On Postfix that's the myhostname setting.The PTR doesn't have to match your From domain. A server with PTR mail.example.net can send for example.com perfectly well. What matters is that the name is real, resolves back, and doesn't look like a dynamic residential address. Names containing strings like "dynamic", "dhcp", "pool" or the IP address itself are treated with suspicion by some filters, so a plain mail.example.com is safer than 192-0-2-25.example.com.
If you send through a service like Google Workspace, Microsoft 365 or a transactional email provider, none of this is your job. They own the sending IPs and manage the PTR records. You only need to deal with reverse DNS when you run the sending server yourself.
No. Browsers never look up the PTR of the server they connect to, and search engines don't rank sites on it. It matters for email, for some logging and security tools, and for verifying things like crawler traffic.
Technically yes, but don't. Some software picks one at random and some fails the check entirely when there are several. One IP, one PTR, one matching forward record is the setup that works everywhere.
PTR records are cached like any other DNS record, for as long as their TTL says. The TTL is set by whoever runs the reverse zone, usually your provider, so check again after it has had time to expire. Our post on DNS propagation explains the caching side.
Usually not, because it can only point to one name and other customers share the address. If you need your own reverse DNS for mail, you need a dedicated IP, or a mail provider that handles sending for you.
0 comments
No comments yet. Be the first.