Deliverability
Reverse DNS checker
Look up the PTR record for an IP address, and see what it is worth fixing for mail.
Free, no accountLive check
Result
The verdict appears here once you press Look up the PTR record.
What this is
This reverse dns lookup asks for the PTR record published at the name built backwards from an IP address - the lookup a receiving mail server runs on every connection it accepts - and says what a missing or unexpected answer is actually worth, rather than treating it as a flat failure.
A PTR record answers "what hostname does this address belong to", the opposite direction from the ordinary A or AAAA lookup. It lives at a special name built backwards out of the address under in-addr.arpa for IPv4 (RFC 1035 §3.5) or ip6.arpa for IPv6 (RFC 3596 §2.5), which is the only way to ask for it: there is no separate "reverse lookup" query type.
A sending mail server is expected to have one, because receiving servers use it as part of judging whether a connection is worth trusting. On its own a PTR record only says a name was published for the address; it says nothing yet about whether that name resolves forward to the same address again.
How to read the result
The facts above are the whole answer: the address entered, the PTR hostname it resolves to (or a dash when there is none), and the exact backwards-built name that was actually queried, so the lookup can be checked by hand against any other resolver.
A warning here means the PTR record is missing, which is common and worth fixing rather than alarming - it never turns this result red. A reserved address gets its own note instead, because no public PTR record was ever going to exist for it.
One of our guides, "What Google and Yahoo require from bulk senders, and how to prove you meet it," walks through why both companies ask for this specific record and where it sits among their other bulk-sender rules.
Common mistakes
What goes wrong most often, and how to tell.
- Treating a missing PTR record as a fault with the addressA sending IP with no PTR record is a common, fixable gap, not evidence the address itself is faulty. Whoever controls the IP - often a hosting provider rather than the domain owner - needs to add the record; nothing about the IP changes by looking at it.
- Stopping at the PTR record and calling it enoughA PTR record only names a hostname; it does not prove that hostname resolves forward to the same address again. Google's own guidelines check both directions, which is why this page checks one hop and fcrdns-checker checks both.
- Expecting a public PTR record on a private addressAn address inside a private, loopback or documentation range was never assigned a public PTR record in the first place, so an empty answer there says nothing about mail delivery at all.
Questions
What people ask about this tool.
- It is the DNS record that answers "what hostname does this IP address belong to" - the reverse of the usual lookup, which answers "what address does this hostname have." A sending mail server is expected to have one published for its own address.
- Google's own sender guidelines state that the sending IP address must match the IP address of the hostname specified in the PTR record, which needs a PTR record to exist before that check can even run. A missing one is worth fixing, though many receivers still accept mail without it.
- No, and on purpose: that second hop is a different check, forward-confirmed reverse DNS, which fcrdns-checker runs in full. This page answers only the first question - what hostname, if any, the address resolves backwards to.
- Yes. The lookup works the same way, built backwards from the address under ip6.arpa instead of in-addr.arpa, with every nibble of the expanded address reversed into its own label. This tool accepts either kind of address in the same field.
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.