Skip to main content
Free checker - no signup required

Free FCrDNS Checker

Test forward-confirmed reverse DNS for every mail-server IP behind your MX. Reads each PTR record, resolves it forward again to confirm it matches, and explains where to fix a missing or invalid PTR.

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.

What "no valid FCrDNS" in a rejection message means

When a receiving server refuses a connection with wording such as "this IP has been blocked because it has no valid FCrDNS", it is reporting one thing only: the connecting IP failed the two-way reverse-DNS check. The receiver looked up the PTR record for that IP and either found none, or found a hostname that did not resolve forward to the same address. Because this test runs at connection time, the rejection happens before SPF, DKIM, DMARC, or the message content is ever evaluated — which is why a domain with flawless authentication can still be refused outright. Fix the IP named in the bounce, and note that it is the address of whatever actually opened the connection: your own mail server, your smart host, or your outbound filtering cluster, which is not always the host listed in your MX record.

Where the PTR record is actually set, provider by provider

PTR records live in the reverse zone for an IP block, and that zone belongs to whoever assigned the IP — so this is almost never a change you make in the DNS panel that holds your A and MX records. If you send through Microsoft 365, Google Workspace, or a hosted ESP, the outbound IPs belong to the provider and they publish their own PTR records; there is nothing for you to set. If you run your own server on a VPS or cloud instance, the reverse record is set in that provider's console — DigitalOcean derives the PTR from the Droplet name, Hetzner and Linode expose an editable reverse-DNS field per address, and AWS requires a reverse-DNS request for an Elastic IP. On a dedicated or colocated server, including cPanel/WHM machines, WHM itself cannot publish a PTR; raise it with the host or the transit provider that assigned the range. Cloudflare is a frequent point of confusion: it manages your forward zone, so enabling it changes nothing about reverse DNS for a mail IP unless Cloudflare also assigned that IP. Whichever route applies, the hostname you choose must also have a forward A or AAAA record pointing back to the same address, or the check still fails.

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.
My mail was rejected for "no valid FCrDNS" — what do I fix?
Fix the reverse DNS of the exact IP quoted in the rejection, not your domain records. That IP needs a PTR record pointing at a hostname you control, and that hostname needs a forward A or AAAA record resolving back to the same IP. Check which host actually made the connection first — with a smart host or an outbound filtering cluster the sending IP is often not the one in your MX record.
Do I need to fix FCrDNS if I send through Microsoft 365 or Google Workspace?
No. Those providers send from IP ranges they own and they publish forward-confirmed PTR records for them already, so there is nothing for you to configure and nothing you can change. FCrDNS only becomes your responsibility for IPs assigned to you — your own mail server, a VPS, or a dedicated outbound relay.
Can I add a PTR record in Cloudflare or my normal DNS panel?
Not for a mail-server IP you did not receive from them. Your DNS panel holds the forward zone (A, AAAA, MX, TXT); the PTR lives in the reverse zone for the IP block, which is controlled by whoever assigned the address. Set it in your hosting or cloud provider console, or ask the IP owner to set it, then confirm the hostname resolves forward 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