Reverse DNS (PTR) Checker

🛡 Deliverability & security

Look up the PTR record for an IP and confirm forward-confirmed reverse DNS (FCrDNS) — the check many receivers run before they’ll accept your mail.

No sign-up required Runs on our own infrastructure Also available via API
Try:

Runs on our diagnostic API. We don’t attach your input to an account for these free tools; short-lived rate-limit/security logs may exist, and requests are rate-limited per IP.

Every conversation about email deliverability eventually reaches the boring, unglamorous setting that quietly decides a surprising number of rejections: reverse DNS. It’s the DNS lookup that goes the other way — from an IP address back to a hostname — and if your sending IP doesn’t have it set up correctly, a lot of receivers won’t even finish the conversation with your mail server. It’s also one of the easiest things to get right, which makes it a needless reason to sit in the spam folder.

Forward vs. reverse DNS, in plain terms

Normal (forward) DNS answers “what IP does mail.example.com point to?” — an A record. Reverse DNS answers the opposite: “what hostname does 203.0.113.10 belong to?” That answer lives in a PTR record, in the special in-addr.arpa zone. The catch that trips people up: PTR records aren’t set in your normal DNS zone — they’re controlled by whoever owns the IP, which is your hosting provider or ISP. So fixing reverse DNS usually means opening a ticket rather than editing a zone file.

What “forward-confirmed” (FCrDNS) means — and why it’s the real test

Having a PTR record isn’t enough on its own. Receivers want forward-confirmed reverse DNS (FCrDNS): the PTR gives a hostname, and that hostname’s A record must point back to the same IP. The loop has to close.

203.0.113.10        --PTR-->  mail.example.com mail.example.com    --A---->  203.0.113.10     ✓ forward-confirmed

FCrDNS is what separates a properly-run mail server from a random box on a dynamic connection. Anyone can be handed an IP; only the legitimate operator can make the forward and reverse records agree. This tool checks both directions and tells you whether the loop closes.

Why receivers care so much

Reverse DNS is one of the very first things a receiving server can check — before your message, before content filtering, sometimes before SPF. Here’s what a good PTR buys you, and why a missing or mismatched one hurts:

  • It filters the obvious junk. A huge share of spam comes from compromised home machines on dynamic ranges with no proper rDNS. Rejecting mail from IPs with no PTR — or with generic, dynamic-looking PTRs like host-203-0-113-10.dynamic.isp.net — is a cheap, effective first filter, and several major receivers do exactly that.
  • It’s a reputation signal. A clean, static, matching PTR says “a real organisation runs this mail server,” and feeds the reputation systems at Gmail, Microsoft and others.
  • Blocklists assume it. Lists like SpamRats maintain entire zones (RATS-NoPtr, RATS-Dyna) for IPs with missing or dynamic reverse DNS — so a bad PTR can literally get you blocklisted.

How to fix a missing or wrong PTR

  1. Pick the hostname your mail server should identify as — usually the same name it uses in its SMTP HELO/EHLO greeting (e.g. mail.yourdomain.com).
  2. Set the forward record. Publish an A record for that hostname pointing to your sending IP (this you do in your own DNS).
  3. Ask your host/ISP to set the PTR. Because they control the IP’s reverse zone, request a PTR for the IP pointing to that same hostname. Some providers expose this in the control panel; others need a support ticket.
  4. Confirm it forward-confirms. Re-run this checker until it reports valid FCrDNS. Consistency is the whole point — the HELO name, the A record and the PTR should all agree.

Where reverse DNS fits in the bigger picture

Reverse DNS is a foundational piece of outbound sender identity, next to a matching HELO and clean IP reputation. It’s deliberately not something a domain-only scan can confirm for your real sending IP — which is why our Email Health Check covers the inbound/DNS side and marks outbound reputation “not tested,” and why the Outbound Deliverability Test reports the PTR/FCrDNS of the IP you actually send from. Line up reverse DNS, SPF, DKIM and DMARC and you’ve covered the identity checks behind most “why is my mail bouncing?” tickets. The deliverability cheat sheet has the rest.

Frequently asked questions

Where do I set a PTR record?
Not in your normal DNS. PTR records live in the reverse zone controlled by whoever owns the IP — your host/ISP. Set it in their panel or via a ticket.
What is forward-confirmed reverse DNS (FCrDNS)?
The PTR resolves to a hostname, and that hostname’s A record resolves back to the same IP — the loop closes both ways. It’s the check receivers actually rely on.
Do I really need reverse DNS to send email?
For a dedicated sending IP, effectively yes — several major receivers reject mail without it. On a shared ESP IP the ESP handles it; run your own server and it’s on you.
My PTR is set but mail still fails — why?
Confirm it forward-confirms, that the hostname matches your HELO, and that the IP isn’t blocklisted. A generic, dynamic-looking PTR is nearly as bad as none.