What is forward-confirmed reverse DNS (FCrDNS)?

Forward-confirmed reverse DNS — FCrDNS, sometimes called full-circle or iprev — means two DNS records agree with each other:

1. The sending IP has a PTR record pointing to a hostname.
2. That hostname has an A or AAAA record pointing back to the same IP.

Either half alone proves nothing. A PTR record can claim any hostname at all, because it is published by whoever controls the IP block. The forward lookup is what confirms the claim: the owner of the hostname has to agree by publishing a record pointing back.

203.0.113.10          →  PTR   mta1.pharosinfra.net     (reverse)
mta1.pharosinfra.net  →  A     203.0.113.10             (forward, confirms it)

Why receivers care

A machine sending legitimate mail is configured infrastructure. Somebody named it, published DNS for it, and intends it to send. A compromised laptop on a home connection is not, and its IP either has no PTR record or has the generic one its ISP assigned — the kind that looks like host-203-0-113-10.dynamic.example-isp.net.

So FCrDNS is a cheap, hard-to-fake signal of whether the sending machine is a mail server or a machine that has been turned into one. Large receivers weight it heavily. Some refuse the connection outright when it is missing, before any of your authentication is evaluated.

It is checked at connection time, against the IP. Nothing in the message affects it.

Why it rots

Unlike SPF or DKIM, FCrDNS is usually set once, at provisioning, by a different person from the one who owns deliverability. Then:

• The IP is reassigned, and the new owner inherits a PTR record naming a host that no longer resolves to it.
• The hostname is retired in a cleanup and the A record goes with it. The PTR stays, now pointing at nothing.
• An IP is added to a pool and nobody sets a PTR for the new one.
• The forward zone is migrated to a new DNS provider and one record does not make the trip.

None of these produce an error. No bounce, no alert, no failed check anywhere in your stack. Mail that delivered fine last quarter is simply weighted differently by receivers who never tell you why. It is the quietest failure in email, which is why it deserves a scheduled check rather than a one-time setup step.

How to check it

# Reverse: what hostname does the IP claim?
dig +short -x 203.0.113.10
mta1.pharosinfra.net.

# Forward: does that hostname agree?
dig +short mta1.pharosinfra.net
203.0.113.10

Both must return, and the IPs must match. An empty first answer means no PTR. A mismatch means the confirmation fails, which is treated much the same as having none.

For mail you did not send yourself, read the Received: headers of a delivered message. The receiving server records what it found:

Received: from mta1.pharosinfra.net (mta1.pharosinfra.net [203.0.113.10])

The hostname appearing twice — once as claimed, once as verified in brackets — is the confirmation. When it fails you tend to see unknown or a bare IP instead.

Who can set it

Only whoever controls the IP block, which means your hosting or sending provider, not you. If you send through a provider, FCrDNS on their IPs is their responsibility and worth asking about specifically — it is rarely on a feature list. If you run your own sending host, it is a support request to your host for the PTR, and a record in your own zone for the forward half.

Pharos re-scans forward-confirmed PTR on its sending IPs daily rather than at provisioning, because this is a check that passes for a year and then stops. Reverse DNS rots quietly goes through how it happens in practice.