FCrDNS: what the circle between name and address says about a mail server
A server has two identities: the address it sits on and the name that belongs to it. For a mail server those two should match — not because an RFC prescribes the circle, but because receiving servers walk it in practice when a message arrives. This article shows which questions are then asked, where they are asked, and what an open circle practically means.
Reverse DNS walks the whole circle in one request: our server asks the name for its addresses (A and AAAA, with a CNAME recorded separately as alias), reverses every public address among them (PTR), and asks every PTR name that came back forward again. In your browser the outcome is read per address — and every name, every address and every missed question is named.
What the tool does not do stands with it explicitly: it asks no mail server what it makes of the circle, it walks the circle at one resolver at one moment, and what falls outside its ceiling of three addresses and two names per address it names not-inspected rather than absent.
1. The walk, leg by leg
The first question is forward: which addresses does this name point at (A and AAAA), and is the name itself perhaps an alias (CNAME)? The second question is reverse: which name belongs to this address — the PTR record. Here sits the detail that surprises zone owners: the PTR does not stand in your own domain zone but in the reverse zone of the address block, and that zone is usually managed by the provider or hoster who hands out the block, not by the owner of the domain. A perfectly maintained zone with a missing PTR is therefore not the zone owner’s carelessness, and the road to repair is often a ticket to the ISP.
The third question closes the circle: the PTR name is looked up again and should come out, with an A or AAAA answer, at the very address it was reached from. RFC 1912 §2.1 formulates that as zone advice — “make sure your PTR and A records match”, with the explicit note that a PTR must point at a valid A record and not at an alias defined by a CNAME — and RFC 5321 §2.3.5 calls the name that thus matches the primary hostname of the host: the name the host gives itself and would state in an EHLO.
2. What keeps a circle open
Practice knows several shapes of a circle that does not close. No PTR at all — many VPS providers hand out only a generic provider hostname, or nothing. A PTR that points at another name than the one that pointed back — the PTR name answers with an A record at a different address, often an old server or a load balancer. A PTR that itself points at a CNAME alias, exactly what RFC 1912 §2.1 warns against. And a forward answer that names private addresses — split-horizon zones letting public DNS advertise a LAN address — which cannot be reversed and are therefore named as private addresses, without a reverse question.
Reverse DNS reports every shape apart: open, no PTR, private address, and “not measurable” when the question failed — because a resolver that did not answer is a missed measurement, not a measured absence. For mail the circle is the ground under the EHLO name: RFC 5321 §4.1.1.1 prescribes that a client without a reverse answer should send an address literal, and lets a receiving server check name against address — with the border stated directly behind it: it may not refuse mail on that check alone. In practice many filters look at the PTR anyway; an open circle is therefore a warning, not a proven rejection.
3. One resolver, one moment — and the cache in between
The walk is made by one resolver: that of this server. One cached, delayed or half-expired answer can show a circle as open that is closed elsewhere — DNS answers cache, and reverse zones are served by other parties than forward domain zones. For those who want to see the difference between resolvers themselves, DNS compare stands ready, and TTL and caching explains how long answers ride along.
The circle also moves along with the infrastructure: a migration to a new address block, another hoster or a changed mail configuration cuts it open without anything being visible in the domain zone. During an outage or a move at the mail side it is sensible to walk the circle before and after the change — the export button of the tool lays both measurements as JSON on disk, and with Report comparison you lay them side by side.
4. What this measurement does not claim
The circle is not reputation. The walk says something about the consistency between name and address, not about whether the address stands on a blocklist or lands in a filter; for that Blacklist check and the blocklist article stand ready, and for the identity of the signing keys SPF, DKIM and DMARC. The security of the nameservers themselves — the signatures that authenticate DNS answers — likewise stands with DNSSEC check.
And the border RFC 5321 draws itself remains the core of the story: a receiving server may walk name and address against each other and tune its behaviour on it, but it may not refuse mail on that check alone. This tool measures the circle and reports what it found — what a platform then makes of it is that platform’s judgement, not this measurement.