Free tool
This is the only tool on the site that takes an IP address rather than a domain name — the PTR record belongs to the address. It reads that record, then walks the path back the other way: does the hostname it returns answer, in turn, for that same address? That round trip, and not the PTR record on its own, is what the servers receiving your mail look at.
The mechanism
A reverse query is not a special kind of query: it is an ordinary one, asked about a name built out of the address. Step through the four moments, and switch cases to watch the loop close — or head off somewhere else.
The case
The starting address
203.0.113.10
The name actually queried
10.113.0.203.in-addr.arpa
What the PTR record answers
…
What that hostname answers, in return
…
The four octets are written backwards and followed by in-addr.arpa. That is the whole secret: the address becomes an ordinary domain name. In IPv6, it is the 32 hexadecimal digits, one per label, followed by ip6.arpa.
Example addresses: documentation ranges from RFC 5737 and RFC 3849. Example names: RFC 2606. The format of the names queried comes from RFC 1035 § 3.5 and RFC 3596 § 2.5.
The question that keeps coming back
Can I create this PTR record at my domain's registrar?
No
This is the founding confusion of the whole subject, and it costs hours. A PTR record does not live in your domain's zone: it lives in in-addr.arpa, a parallel tree that follows ADDRESSES rather than NAMES, delegated along the allocation chain. You can add as many lines labelled “PTR” to your zone as you like: no server anywhere will read them. The line that counts is filled in at whoever assigned you the address.
So where, then?
At the host, on the machine's page. The field is called “reverse DNS”, “PTR” or “rDNS” and sits next to the address. It usually takes effect immediately.
At the operator, by ticket or through its customer area. It holds the zone for the block your address belongs to; nobody else can write in its place.
At your end, in the reverse zone the regional internet registry delegated to you — or the one your operator delegates by alias, if your block is smaller than a /24.
The PTR record alone says almost nothing. What matters fits in one question: does the hostname it announces come back to the address you started from?
Almost never a typo. Almost always a record created in the wrong place, or half a job done.
What causes it: A PTR record does not live in your zone. It lives in in-addr.arpa — or ip6.arpa for IPv6 — a parallel tree delegated along the chain of address allocation. It therefore belongs to whoever rents you the address, not to whoever sold you the domain name. You can add as many lines labelled “PTR” to your own zone as you like: no server anywhere will ever read them.
What fixes it: Look for “reverse DNS”, “PTR” or “rDNS” in the console of the host running the server, or of the operator providing the address. With most of them it is a free-text field next to the address; with a few, a support ticket.
What causes it: The new address did receive a PTR record pointing at the server's hostname, but that hostname's A record still points at the old address. The PTR record is correct and the loop is broken — and this tool sees it, where checks that merely read the PTR record report that all is well.
What fixes it: Fix the hostname's A record in your zone, not the PTR record. Then run this check again: it is the return leg, and only that, which has to land on the address you started from.
What causes it: The hostname declared is a CNAME pointing at another name. Resolution often ends up working, but not everywhere, and RFC 1912 § 2.1 explicitly advises against it: a PTR record should name a host that carries an A record of its own, not an alias.
What fixes it: Point the PTR record at the hostname that carries the A record — the server's own — rather than at the marketing alias dressed over it.
What causes it: This is the quietest failure of the four. The server was configured years ago on its IPv4 address, then the host assigned it an IPv6 one. When the recipient publishes an AAAA record, the connection goes out over IPv6 — and that is the address, with no PTR record, that gets checked on arrival.
What fixes it: Check both of your server's addresses in this tool, one at a time. Then create the missing PTR record, or disable IPv6 on the sending service until it exists.
There is no such thing as a “reverse query” in DNS. There is an ordinary PTR query, asked about a name built out of the address. Here is how that name is built, and who owns the zone that carries it.
| What you type | The name actually queried | Who owns the zone |
|---|---|---|
| 203.0.113.10 (IPv4) | 10.113.0.203.in-addr.arpa | The four octets, reversed, followed by in-addr.arpa — RFC 1035 § 3.5. The zone is delegated along with the address block, so to the operator or host that holds it. |
| 2001:db8::1 (IPv6) | 1.0.0.….0.8.b.d.0.1.0.0.2.ip6.arpa | The address's 32 hexadecimal digits, one per label, reversed, followed by ip6.arpa — RFC 3596 § 2.5. Thirty-four labels in all, which is why nobody ever writes it out by hand. |
| A full /24 block | 0.113.0.203.in-addr.arpa | The zone delegated by the regional internet registry to whoever received the block. This is the first level at which an end customer can sometimes be handed their own PTR records. |
| A block smaller than a /24 | delegated by alias | A /24 cannot be cut into quarters inside in-addr.arpa. RFC 2317 works around the limit by placing one alias per address, pointing at a zone the customer runs themselves. This is the arrangement you meet at operators renting out addresses one at a time. |
Example addresses: documentation ranges from RFC 5737 (IPv4) and RFC 3849 (IPv6).
At whoever holds the address, never at the domain's registrar. The in-addr.arpa zone is delegated along the chain of address allocation: from IANA to the regional internet registry, from the registry to the operator, from the operator to the host. In practice: a “reverse DNS” field in your server's console with most hosts, a support ticket with the rest. If you rent a server, it is your host. If you are on shared hosting, you are not sending from your own address and the question does not arise for you.
To reach a Gmail inbox, yes, and it is written down. Google's sender guidelines have required since 1 February 2024 that sending domains or IPs have “valid forward and reverse DNS records, also referred to as PTR records”, and add that “the sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record” — which is precisely the loop this tool checks. On the Microsoft 365 side, a message whose sending address has no valid PTR record gets an explicit rejection, “550 5.7.364 … invalid or missing PTR (reverse DNS) record”. Not every recipient demands a PTR record, but a great many factor it into their scoring.
No, and they complement each other. SPF starts from the domain and lists the addresses allowed to send on its behalf: that is the forward direction. The PTR record starts from the address and declares the hostname it carries: that is the reverse direction. A server can pass SPF and fail on its PTR record, and the other way round. Neither excuses the other.
Nothing forbids it, and this tool will tell you how many it finds. But the order in which they are served to you is not guaranteed, and nothing says which one a remote server will keep for its check. On an address that sends mail, a single hostname — the one the server announces in its HELO — settles the question.
Because the PTR record is only one of the checks. It says the machine is properly declared; it says nothing about the content of the message, the reputation of the address, or the SPF, DKIM and DMARC alignment of the sending domain. A correct PTR record is an entry condition, not a pass.
Yes, in both directions. An IPv6 address is queried inside ip6.arpa, and the return leg is checked against A and AAAA records alike. Check both of your server's addresses separately: a server whose IPv4 address alone carries a PTR record fails as soon as the recipient publishes an AAAA record.
Where the authority comes down from
Four links between the root of the DNS and the line somebody has to write. Knowing which one concerns you is knowing who to write to — and it stops you searching the wrong console.
Delegation of reverse zones: RFC 1035 § 3.5 (in-addr.arpa), RFC 3596 § 2.5 (ip6.arpa), RFC 2317 (delegating a block smaller than a /24).
What the recipient looks at
The name must come back to the address.
A PTR record is read in both directions. The server receiving your mail reads the hostname your address announces, then asks that hostname which address it carries. If the two do not meet, your address is claiming a name that does not acknowledge it.
Word for word
Not an estimate, not a percentage: both texts below are public, and they are what your server has to satisfy to get in.
Applies to all senders since 1 February 2024.
Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records. […] The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.Both sentences describe exactly the loop this tool checks: the PTR record first, the match second.
Rejection code returned to the sending server, readable in the headers of the bounced message.
550 5.7.364 Remote server returned invalid or missing PTR (reverse DNS) record for sending domainA hard rejection, not a move to the junk folder: the message does not get through. The code appears verbatim in the non-delivery report.
Sources: Google's email sender guidelines (support.google.com/a/answer/81126) and Microsoft Learn documentation for code 550 5.7.364.