Why the PTR record alone proves nothing
A reverse DNS entry can simply be asserted. Whoever leases an IP address controls its reverse zone and can put whatever they like in it — including mail.well-known-bank.example. The PTR record on its own is therefore a self-declaration, not a confirmation.
FCrDNS — forward-confirmed reverse DNS — closes that gap by walking the path back:
- Look up the PTR record for
203.0.113.10→mail.example.com - Look up the A and AAAA records for
mail.example.com - Check whether
203.0.113.10is among them
The decisive point is that the two directions are controlled by different parties. The reverse zone belongs to the operator of the address block, the forward zone to the holder of the domain. If both agree, two independent parties have committed to the same statement. That is what makes FCrDNS evidence and the PTR record alone an assertion.
What AnalyzeMy.Email checks
The check runs in three places, because it says something different in each:
- For the sending IP — adding the return direction to the HELO/rDNS comparison.
- For every MX host of the domain, with the matching query type: A records are checked against the IPv4 address, AAAA against the IPv6 address.
- For every IP resolved from the SPF record — this reveals whether the authorized addresses belong to named mail servers at all.
Lookups run through our own resolver with an explicit time limit rather than the operating system's name resolution — that cannot be capped reliably and would block the entire analysis on failure.
What a failure means
Major providers treat missing or unconfirmed FCrDNS as a hard criterion. Google and Microsoft name it explicitly in their requirements for sending systems; some servers refuse the connection outright without valid FCrDNS, others raise the spam score substantially.
The common causes are soberingly mundane:
- No PTR set — with many cloud providers that is the state on delivery.
- PTR points at the provider's default name, such as
ip-203-0-113-10.hoster.example, for which no matching A record exists. - PTR set, A record forgotten — the return direction exists, the forward one does not.
- Only IPv4 maintained — the server sends over IPv6, where the PTR record is missing entirely.
Setting it up correctly
- Set the PTR with the operator of the address block — that is your hoster, not your domain's DNS provider. There is usually a dedicated field in the server control panel.
- Use the same name as in HELO. HELO name, PTR record and A record should be identical; then everything lines up at once.
- Maintain both address families as soon as the server also sends over IPv6.
- Wait after changing: reverse zones often carry long TTLs, and many checkers add a cache of their own.