Reverse DNS / PTR / FCrDNS Checker
Enter an IPv4 or IPv6 address. We look up the PTR record, then resolve that hostname forward and check whether it points back to the original IP. That round-trip is the FCrDNS check most mail servers run before they accept your mail.
Try an example: 8.8.8.8 · 1.1.1.1 · 2001:4860:4860::8888
Validation results
How this reverse DNS and FCrDNS checker works
A PTR record is the reverse of an A or AAAA record. It maps an IP back to a hostname. PTRs live in a dedicated reverse zone, not in your forward zone:
1.2.3.4 → 4.3.2.1.in-addr.arpa PTR mail.example.com
2001:db8::25 → 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa PTR mail.example.comFCrDNS (Forward-Confirmed Reverse DNS, RFC 8601) is the round-trip check. Take the PTR result, resolve it forward, and confirm it lands back on the IP you started with. If the two directions don't agree, receivers treat the IP as untrusted.
Type an IPv4 or IPv6 address above. The checker runs the PTR lookup, then the forward A or AAAA query on whatever hostname comes back, and reports whether the round trip closes. It also flags the usual failure modes: a generic cloud PTR like ec2-54-201-12-9.us-west-2.compute.amazonaws.com that doesn't match the EHLO banner, multiple PTRs on the same IP, or a missing IPv6 PTR on a dual-stack relay.
Who actually owns your PTR?
Not you. The reverse zone for an IP block belongs to whoever holds the allocation, your hosting provider, ISP, or cloud platform. You file a ticket and they set the PTR. AWS, Azure and GCP let you set it yourself for elastic IPs, but the request still flows through their console rather than your domain's DNS.
That split is why FCrDNS breaks so often. The forward record sits in your zone. The PTR sits in someone else's. When one moves and the other doesn't, the round trip fails.
Why this matters
Gmail, Yahoo and Outlook all require valid FCrDNS on the sending IP. Gmail and Yahoo turned this on in February 2024 as part of the bulk-sender rules. Microsoft followed for Outlook.com, Hotmail and Live in May 2025. Mail from an IP with no PTR, or a PTR that doesn't round-trip, gets a poor reputation score or a hard reject. The Outlook bounce text usually says access denied, the sending IP address has no PTR record.
IPv6 is stricter. Gmail rejects v6 mail outright if FCrDNS fails. If you can't get a valid v6 PTR set, send from IPv4 only until you can.
Our take: the PTR your provider gives you by default is almost always a generic cloud name. That's fine for a web server. It's not fine for a mail relay. Receivers compare the PTR against the EHLO hostname and the rDNS-on-the-banner; a mismatch costs you reputation even when FCrDNS technically passes.
What to do: point the PTR at a hostname you actually control, like mail.example.com, then publish a matching A or AAAA in your zone, then make EHLO announce the same name. All three have to agree.
Where to go next
For the record-type background, see the DNS record types reference. To run FCrDNS across every host that serves a domain's mail, use the MX inspector. If your sending IP is also showing up in spam reports, the blacklist checker queries 80+ DNSBLs in one pass.
Frequently Asked Questions
Common questions about reverse DNS, PTR records, and FCrDNS.
Why does FCrDNS fail when the PTR looks correct?
The PTR returns a hostname, but resolving that hostname forward gives a different IP, or no answer at all. The two directions have to agree on the same IP for FCrDNS to pass.
Three usual causes. The PTR points at a stale hostname left over from the previous tenant of that IP. You never published the matching A or AAAA in your forward zone. The forward record points at a load-balancer VIP that isn't the IP doing the actual sending. Fix whichever side is wrong, and remember TTLs on reverse zones can be long.
I don't have a PTR. Who sets it?
Not you, not in your zone. PTRs live in the reverse zone owned by whoever holds the IP allocation. For a dedicated server, that's your hosting provider or ISP. For cloud, it's the console: AWS lets you set a PTR on an Elastic IP via the EC2 console (and only after AWS lifts the port 25 throttle), Azure exposes it on the Public IP resource, GCP under the External IP.
Once the PTR is set to a hostname you control, publish the matching A or AAAA in your forward zone. FCrDNS won't pass on the PTR alone.
Is a generic cloud PTR good enough?
For a web server, fine. For a mail relay, no. Generic PTRs like ec2-54-201-12-9.us-west-2.compute.amazonaws.com or azure-13-77-42-1.cloudapp.net technically round-trip, but receivers score them as untrusted because the hostname doesn't belong to the sending organisation.
Spamhaus and the major receivers also pattern-match these names against their "generic rDNS" lists. Mail from such IPs gets greylisted, deferred, or sent to spam even when SPF, DKIM and DMARC all pass. Set the PTR to a hostname under your own domain instead.
Does IPv6 need its own PTR?
Yes, and Gmail is stricter on v6 than v4. A v6 sender with no PTR, or a PTR that fails FCrDNS, gets a hard reject from Gmail, not a soft fail. The bounce is usually 550-5.7.1 ... IPv6 sending guidelines.
If your provider won't set a v6 PTR (some still don't on shared blocks), disable IPv6 outbound on your mail server and send from IPv4 only. A working v4 path beats a broken v6 one every time.