Reverse DNS, FCrDNS, And Why Mail Servers Care

Reverse DNS is the lookup that turns a sending IP address into a hostname through a PTR record, and forward-confirmed reverse DNS (FCrDNS) is the check that the hostname the PTR returns resolves forward, via an A or AAAA record, back to that same IP. Mail servers care because a sending IP with no PTR, or a PTR that does not confirm, is one of the strongest cheap signals of an unmanaged or abusive host. Gmail will refuse such mail outright with 550 5.7.25, and that is not a soft scoring penalty, it is a rejection at the door.

A managed mail server is expected to have clean reverse DNS. Botnets and compromised residential hosts almost never do, because they do not control the PTR for the IP they are sending from. So receivers use the presence and consistency of reverse DNS as a fast, reliable filter before they spend effort on content or authentication.

PTR records and the .arpa zone

Forward DNS maps a name to an IP using an A record (IPv4) or AAAA record (IPv6). Reverse DNS goes the other way, mapping an IP to a name using a PTR record, and it lives in a special reverse zone under in-addr.arpa for IPv4 (or ip6.arpa for IPv6). The IP is reversed octet by octet to form the query name.

# forward: name -> IP
mail.example.com.        IN  A      203.0.113.10

# reverse: IP -> name (note the reversed octets under in-addr.arpa)
10.113.0.203.in-addr.arpa.  IN  PTR  mail.example.com.

The critical detail: you do not control the PTR by editing your own domain's zone. The PTR for an IP is delegated to whoever controls that IP block, which is your hosting provider or the RIR-assigned owner. To set or fix a PTR you go through your provider's control panel or open a request, not your domain registrar.

You can read it from the command line:

$ dig -x 203.0.113.10 +short
mail.example.com.

$ dig +short mail.example.com
203.0.113.10

If the first command returns the hostname and the second returns the original IP, the reverse DNS forward-confirms.

What FCrDNS actually verifies

FCrDNS, also called iprev, is the two-step check a receiving MTA runs against the connecting IP:

1. Reverse lookup: PTR query on the connecting IP returns a hostname.
2. Forward lookup: A/AAAA query on that hostname must return a set of IPs that includes the original connecting IP.

If step two does not include the original IP, the reverse DNS does not confirm, and the check fails. A PTR that points to a name which does not resolve back is treated almost the same as having no PTR at all. The verification matters because it proves the IP's owner deliberately associated that IP with that hostname in both directions, which an attacker spraying from a hijacked host cannot fake.

# what the receiver effectively does
ptr   = reverse_lookup(connecting_ip)        # 203.0.113.10 -> mail.example.com
ips   = forward_lookup(ptr)                  # mail.example.com -> {203.0.113.10}
fcrdns_pass = connecting_ip in ips           # true only if it round-trips

The HELO/EHLO name fits into the picture

When your server connects, it announces itself in the SMTP HELO/EHLO command. Best practice, and what receivers expect, is for that HELO name, the PTR hostname, and the forward A record to all agree and all point at the sending IP.

220 mx.receiver.net ESMTP
EHLO mail.example.com
250-mx.receiver.net Hello mail.example.com [203.0.113.10]

Here the connecting IP 203.0.113.10 has a PTR of mail.example.com, mail.example.com forward-resolves to 203.0.113.10, and the server announced EHLO mail.example.com. Everything aligns. Receivers may run FCrDNS on the HELO name too; alignment across all three is the clean configuration, and a HELO that is a bare or mismatched name draws suspicion even when the PTR itself is fine.

What breaks without it

The failure modes are concrete:

• No PTR at all. Gmail rejects with 550 5.7.25 ... does not have a PTR record, and enforcement of this got noticeably stricter through late 2025. Other receivers defer or spam-folder.
• PTR exists but does not forward-confirm. The hostname in the PTR does not resolve back to the IP, so FCrDNS fails and you get the same negative treatment as missing reverse DNS, plus the appearance of a misconfiguration.
• Generic provider PTR. The IP resolves to something like 203-0-113-10.dynamic.isp.example, which screams residential or unmanaged and earns a heavy spam penalty even though it technically confirms.
• HELO mismatch. The PTR is fine but the server announces a HELO name that does not match, which weakens the overall trust signal.

# the rejection you see when the PTR is missing
550-5.7.25 The IP address sending this message does not have a PTR record
550 5.7.25 setup, or the corresponding forward DNS entry does not point to
the sending IP address.

The fix is always the same shape: set the PTR through your IP provider to a real hostname in a domain you control, publish a matching forward A/AAAA record for that hostname, and announce that same name in HELO/EHLO. Then confirm with dig -x and a forward dig that it round-trips.

Saying it out loud

In an interview: "Reverse DNS maps the sending IP to a hostname via a PTR record in the in-addr.arpa zone, and FCrDNS, or iprev, confirms that hostname forward-resolves back to the same IP. Receivers care because a managed mail server has clean, confirming reverse DNS and a botnet does not, so it is a cheap, reliable filter. I set the PTR through the IP's owner, not my registrar, publish a matching A record, and announce the same name in HELO so all three align. The concrete failure is Gmail's 550 5.7.25, an outright rejection for a missing or non-confirming PTR, and enforcement tightened in late 2025. I verify with dig -x for the PTR and a forward dig to confirm the round trip." That answer shows you know reverse DNS is owner-delegated, that FCrDNS is the two-way confirmation, and exactly which error tells you it is broken.