Reverse DNS rots quietly, and your mail goes with it

Most deliverability problems announce themselves. A bounce arrives with a reason code, a complaint rate climbs on a dashboard, a blocklist sends a notification. Reverse DNS is not like that. When it breaks, nothing errors, nothing bounces, and no alert fires. Your mail simply starts being weighted differently by receivers who never tell you why.

What forward-confirmed actually means

Reverse DNS turns an IP address back into a hostname, via a PTR record. Forward-confirmed reverse DNS — FCrDNS — means the loop closes: the hostname you get back resolves forward to the same IP you started from.

$ dig -x 203.0.113.10 +short
  mta1.example.net.

$ dig mta1.example.net +short
  203.0.113.10

→ forward-confirmed

Two lookups, and they have to agree. Compromised machines and hastily-provisioned spam infrastructure rarely close that loop, because closing it requires control of both the reverse zone (which belongs to whoever owns the IP block) and the forward zone (which belongs to you). Receivers know this, so an open loop is a meaningful negative signal — and a closed one is a cheap, verifiable positive.

Why it rots

The failure mode is almost always administrative rather than technical:

• An IP gets reassigned. Your provider moves you to a different address and the PTR record for the new one still says something generic, or nothing at all.
• A forward record changes. Someone tidies up DNS, drops an A record that looked unused, and the reverse lookup now points at a hostname that resolves nowhere.
• A hostname is renamed. The PTR says mta1, the forward zone now calls it smtp1, and the loop is broken in one direction only.
• Nobody ever set it. New IP, new sending, and the reverse zone was never touched because sending worked well enough in testing.

None of these produce an error. Mail keeps flowing. What changes is a probability, and probabilities do not page anyone.

How to check, and how often

Checking is trivial — the two dig commands above, run against every IP you actually send from. The hard part is every and repeatedly.

You need the full set of sending IPs, not the one you remember. If your provider sends you from a pool, that is the whole pool. And you need it re-run on a schedule, because a check that passed in March is a statement about March.

A daily scan is not excessive. It costs two DNS lookups per IP and it catches a reassignment within a day rather than within a quarter of degraded delivery.

The related check people miss

While you are in there: the hostname in your PTR record should also match the hostname the server announces in its SMTP HELO/EHLO greeting. A machine that calls itself one thing at the protocol level and resolves to another is another small inconsistency, and receivers add those up.

220 mta1.example.net ESMTP

That name, the PTR, and the forward record should all be the same string. Three places, one value.

Where Pharos fits

Pharos re-scans forward-confirmed reverse DNS across its sending set every day and alerts on drift, rather than setting it at provisioning time and trusting it thereafter. You can verify the current state yourself with the two commands above — that is the point of publishing the hostname.