There’s a DNS record that decides whether your mail gets delivered, that no standard actually requires, and that you frequently cannot set yourself even if you want to. It’s the reverse record — the PTR — and the way it quietly gatekeeps email is one of the stranger load-bearing accidents on the internet.
Most people meet it the hard way. You stand up a mail server, everything looks right — MX records, SPF, DKIM, a valid certificate — and your messages still land in spam or get bounced at the door with something like “client host rejected: cannot find your reverse hostname.” You didn’t forget a record. You forgot a record you didn’t know you were responsible for, and possibly one you don’t even control.
Forward DNS goes one way. Reverse goes the other.
Normal DNS answers “what’s the address for this name?” You ask for example.com, you get back an address like 93.184.216.34. Reverse DNS answers the opposite question: “what name belongs to this address?” Given an IP, return a hostname.
The clever, slightly absurd part is how it’s stored. There’s no separate reverse database — it’s all just DNS, the same tree, the same query machinery. To look up an IPv4 address, you reverse its octets, glue on .in-addr.arpa, and ask for a PTR record. So 93.184.216.34 becomes a query for 34.216.184.93.in-addr.arpa. The reversal is there because DNS names get more specific right-to-left (www.example.com narrows as you read left), while IP addresses get more specific left-to-right. Flip the octets and the address slots neatly into the DNS hierarchy, with each network delegated like any other zone. IPv6 does the same thing under ip6.arpa, except you reverse all 32 hex nibbles, which produces the kind of query string nobody types twice.
Here’s the catch that surprises people: forward and reverse DNS are controlled by completely different parties. You own example.com, so you control its forward records. But the reverse zone for an IP belongs to whoever owns the IP block — your ISP or hosting provider. You don’t get to publish a PTR for an address you’re merely renting. You have to ask them, or use whatever control panel they expose. For a sub-/24 allocation there’s even a special mechanism, RFC 2317 classless delegation, to hand you reverse control of a slice of an address range. The point stands: the reverse record lives on the other side of an ownership line from everything else you manage.
The check that actually matters: FCrDNS
A PTR record on its own proves almost nothing, because the person who owns the IP block can point it at any name they like. I could set the reverse for my server to mail.google.com and the lookup would dutifully return it. That’s where forward-confirmed reverse DNS comes in — FCrDNS, also called iprev, full-circle, or double-reverse DNS.
The idea is to close the loop:
- Take the IP. Look up its PTR record. Get a hostname.
- Take that hostname. Look up its A (or AAAA) record. Get a list of IPs.
- Check that the original IP is in that list.
If the circle closes, the result is FCrDNS-valid. And the reason it’s meaningful is exactly that ownership split from before. To forge it, you’d need to control both the reverse zone (which means controlling the IP block) and the forward zone you’re pointing at. Setting a PTR to mail.google.com gets you nowhere, because Google’s A records for that name don’t list your IP, and the forward confirmation fails. The check isn’t strong cryptography — it’s a cheap proof that the same entity controls both ends, which turns out to be enough to filter a lot of garbage.
RFC 1912 wrote this down back in 1996, and its advice is almost quaint in its plainness: “Make sure your PTR and A records match.” It’s an Informational RFC. It does not, and cannot, require anything. The formal home for the check as a named mechanism is iprev, defined as an authentication method in the Authentication-Results work (RFC 8601). But notice what’s missing: nowhere in the SMTP standard, RFC 5321, does it say a server must have valid reverse DNS. The entire regime is best-practice and convention.
How a convention became a wall
Convention, except that the big receivers enforce it like law.
Mail servers were among the first to use FCrDNS as a spam signal, and the logic is sound. A legitimate mail server is a deliberately configured machine; its operator can arrange a matching PTR with a few minutes of effort. A spam-spewing botnet node sitting on a residential connection has a reverse name like 203-0-113-44.dyn.example-isp.net — generic, obviously dynamic, and not matching anything it claims to be. So receivers started rejecting connections from IPs with no PTR, or with a generic-looking one, often before the message body is even sent. Postfix ships this as reject_unknown_client_hostname: no resolvable, forward-confirmed reverse name, no conversation.
The major providers all bake it in. Google’s sender guidelines flatly require every sending IP to have a matching PTR record, and they’re stricter still for IPv6 — send over v6 without proper reverse DNS and Gmail will reject you outright. Outlook and Yahoo check it too. None of them are obligated to by any standard. They do it because, twenty-some years on, the absence of a clean reverse record remains one of the most reliable tells that a host has no business sending mail.
So you end up with this genuinely odd situation. The record isn’t mandated. It’s governed by an Informational RFC whose strongest verb is “should.” And yet it has become a hard prerequisite for one of the internet’s core functions — to the point where “no PTR” is a more fatal email-delivery problem than a missing DMARC policy, which actual standards do define.
What to take from it
If you run anything that sends mail, reverse DNS is not optional, regardless of what the RFCs technically say. Three things follow from how it works:
You may not control it, so find out early. The PTR lives with whoever owns the IP. On a VPS or dedicated host there’s usually a panel field for it; on shared or cloud setups you might have to file a request, or you might be stuck — which is a real argument for sending through a provider whose IPs already have clean reverse DNS.
Make the loop close. A PTR pointing at a hostname that doesn’t resolve back to the same IP can be worse than no PTR at all, because it reads as misconfiguration. Set the reverse to a real hostname, give that hostname a forward record containing the IP, and ideally use the same name your server announces in its HELO. All three lining up is what the strict receivers are quietly checking.
And if your mail is mysteriously getting rejected while every record you do control looks perfect, check the one you might not. The reverse record is the easiest thing on the internet to forget, precisely because it’s the one piece of your mail identity that lives on someone else’s side of the fence.