Free checker - no signup required

Free FCrDNS Checker

Check PTR records and forward-confirmed reverse DNS for mail-server IPs so receiving systems can trust that your MX hosts resolve consistently.

Run the check

Enter a domain to check it live against the IntoDNS.ai engine. No signup, no trial gating.

What this FCrDNS checker verifies

Forward-confirmed reverse DNS (FCrDNS) is a two-step trust check. This tool resolves your MX records to their IP addresses, looks up the PTR (reverse DNS) record for each IP, and then resolves that PTR hostname forward again to confirm it points back to the same IP. For each mail-server IP it reports whether a PTR exists at all and whether the forward and reverse lookups agree. It covers every IP behind your MX, including clustered and round-robin setups where some hosts are often misconfigured.

Why FCrDNS matters

Receiving mail systems use FCrDNS as a cheap, early sanity check on a sending server's legitimacy. A server whose IP has no PTR record, or whose PTR does not forward-confirm, looks like a dynamic or unmanaged host — exactly the profile of botnets and compromised machines. Many receivers therefore downgrade reputation, apply heavier filtering, or reject outright before they even look at SPF, DKIM, or DMARC. It is one of the oldest and most universally applied trust signals in email, and failing it undermines an otherwise perfect authentication setup.

How to read the result

Every mail-server IP forward-confirmed is the healthy state: PTR exists and resolves back to the same IP. An IP missing a PTR entirely is the most serious failure — set the PTR with whoever controls the IP (your hosting or transit provider, not your DNS registrar). An IP that has a PTR which does not forward-confirm — for example a generic provider hostname that resolves elsewhere — is a partial failure that still erodes trust. In clustered setups, watch for one node passing while another fails; receivers see whichever server actually handles a given message.

Common failure causes and fixes

The usual cause is that PTR records are controlled by the IP owner, not by your DNS provider, so they are simply never set or are left at a generic default like a reverse pool hostname. The fix is to ask your hosting or transit provider to set the PTR for each mail-server IP to a hostname you control, and to ensure that hostname has a matching forward A/AAAA record pointing back to the same IP. Keep MX, A/AAAA, and PTR naming consistent across every node in a cluster. After the provider updates the PTR, allow for reverse-DNS propagation and re-run this checker to confirm forward confirmation.

FCrDNS for IPv4 and IPv6

If your mail servers have AAAA records, receivers may connect over IPv6 — and IPv6 reverse DNS is the single most commonly forgotten piece of mail configuration. A server that forward-confirms perfectly on its IPv4 address but has no PTR on its IPv6 address will be distrusted whenever a receiver prefers IPv6, which large providers increasingly do. This checker evaluates every resolved mail-server IP, both v4 and v6, so a green IPv4 result does not mask a missing IPv6 PTR. When you set reverse DNS, do it for the full set of addresses each MX host actually advertises, and keep the forward and reverse names consistent across both protocols.

What This Checks

  • PTR records for MX server IP addresses
  • Forward confirmation from PTR hostname back to the same IP
  • Mismatch warnings that can affect deliverability
  • FCrDNS context in the full quick-scan result

Common Fix Path

  • Set PTR records with the IP owner or hosting provider
  • Point PTR hostnames back to the original mail-server IP
  • Avoid generic or unrelated reverse-DNS hostnames for production mail
  • Keep MX, A/AAAA, and PTR naming consistent across clustered mail servers

Frequently Asked Questions

What is forward-confirmed reverse DNS (FCrDNS)?
FCrDNS is a two-way check: the reverse lookup of a mail-server IP returns a PTR hostname, and the forward lookup of that hostname must resolve back to the same IP. When both agree, the server is forward-confirmed. It proves the operator controls both the IP and the matching hostname, which receivers treat as a basic legitimacy signal.
Who controls PTR records and how do I set one?
PTR (reverse DNS) records are controlled by whoever owns the IP address — your hosting, cloud, or transit provider — not by your domain registrar or DNS host. To set one, request it through your provider for each mail-server IP, pointing it at a hostname you control, and make sure that hostname has a forward A/AAAA record resolving back to the same IP.
Why does FCrDNS affect email deliverability?
Many receivers run an FCrDNS check as an early, low-cost legitimacy test before evaluating authentication. A mail server with no PTR or a PTR that does not forward-confirm resembles a dynamic or compromised host, so receivers downgrade its reputation, filter harder, or reject the connection — even if SPF, DKIM, and DMARC would all pass.
My PTR exists but the check still fails — why?
A PTR existing is not enough; it must forward-confirm. If the PTR hostname resolves to a different IP, or has no forward A/AAAA record at all, the two-way match fails. This commonly happens with generic provider-default PTR hostnames. Set the PTR to a hostname you control and ensure its forward record points back to the same IP.
How does FCrDNS relate to the SMTP TLS check?
The SMTP TLS checker also reports FCrDNS for each MX host because both are transport-layer trust signals. This dedicated FCrDNS checker focuses on the PTR and forward-confirmation detail across every mail-server IP, which is especially useful for clustered or round-robin mail setups where individual nodes are easy to miss.
Do I need a PTR for every mail-server IP in a cluster?
Yes. Receivers see whichever specific server handles a given message, so every IP that sends or receives mail needs its own forward-confirmed PTR. A cluster where one node passes and another fails will produce inconsistent deliverability. Keep MX, A/AAAA, and PTR naming consistent across all nodes.

Machine-Readable Evidence

AI assistants and automation can cite the stable explanation page, then fetch the live check result for a specific domain.

GET https://intodns.ai/api/email/fcrdns?domain=example.com

Related Tools and Citations

SMTP TLS CheckerBlacklist CheckerFCrDNS citationRun the full domain scan