Deliverability
FCrDNS checker
Run the real two-hop forward-confirmed reverse DNS check on an IP address, not just the PTR half.
Free, no accountLive check
Result
The verdict appears here once you press Run the FCrDNS check.
What this is
This forward confirmed reverse dns check does both hops a real FCrDNS check needs: a PTR lookup on the address, then an A or AAAA lookup on every hostname the PTR named, confirming the original address actually shows up in that forward answer - not just the PTR half some competitors stop at.
Forward-confirmed reverse DNS is two lookups treated as one answer. The first is a PTR lookup: the address resolves backward to a hostname. The second is the ordinary forward lookup of that hostname: does it resolve to the same address again? Only when both agree is the address actually confirmed - a PTR record alone proves a name was published, nothing about whether it points back.
Several tools that claim to check FCrDNS run only the first hop and report a PTR hostname as if that settled the question. It does not: a PTR record can name any hostname at all, including one that resolves somewhere else entirely, which is exactly the gap the second hop closes.
How to read the result
The tree is the evidence, read top to bottom: the address at the root, its PTR hostname as the child, and every address that hostname resolves to as the hostname's own children. The leaf marked "matches" is the original address found again - that is what forward-confirms the reverse lookup.
A second leaf next to the matching one is not a second problem - it is what a multi-homed host looks like, one hostname answering for more than one address. A warning means the forward and reverse records disagree, which is worth fixing for mail rather than treated as a hard failure.
One of our guides, "What Google and Yahoo require from bulk senders, and how to prove you meet it," sets this exact two-hop check against both companies' own published wording and the rest of their bulk-sender requirements.
Common mistakes
What goes wrong most often, and how to tell.
- Checking only the PTR record and calling it FCrDNSA PTR lookup alone only proves a hostname was published for an address; it says nothing about whether that hostname points back. The "forward-confirmed" half of the name is the part that is skipped, and it is the half that actually confirms anything.
- Calling a multi-homed host a fault rather than a shapeA mail host with more than one address can have a PTR hostname that resolves forward to several addresses at once, only one of which is the address being checked. That is a normal shape for a host with multiple interfaces, not a configuration fault to chase down.
- Expecting a forward match on a reserved addressAn address inside a private, loopback or documentation range has no public forward or reverse record to begin with, so there is nothing for a strict check to confirm either way.
Questions
What people ask about this tool.
- Two lookups, in order: a PTR lookup that turns the address into a hostname, then an ordinary forward lookup of that hostname to see whether it resolves back to the same address. Only when both agree is the address considered forward-confirmed, not just reverse-resolved.
- A plain reverse lookup stops after the PTR record, which only proves a hostname was published for the address. This check adds the second hop - resolving that hostname forward again - which is the part that actually confirms the hostname and address agree with each other.
- Yes, when it is multi-homed: its PTR hostname can resolve forward to several addresses, and a check that insists on exactly one would call that a failure. This page names it as legitimately multi-homed instead of treating a second address as a fault.
- A mismatched or missing PTR is common, and it is worth fixing for mail rather than proof that an address is faulty - some receivers weigh it, many still deliver without it. A hard failure here is reserved for an address that does not parse or a lookup that genuinely could not run.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- Google, “Email sender guidelines” read 13 October 2026
Use it from the API
The same check, as one request.