Glossary
Reverse DNS
Reverse DNS is the lookup that turns an IP address back into a hostname, answered by a PTR record published in a special zone derived from the address. Control of it belongs to whoever holds the address block — your hosting provider — not to whoever owns the domain. It matters most for outbound email, where receiving servers routinely check that a sending address resolves to a name that resolves back to the same address; for web serving it is essentially decorative.
How the lookup is addressed
An IPv4 address is reversed and placed under `in-addr.arpa`: the address 203.0.113.10 is queried as `10.113.0.203.in-addr.arpa`.
IPv6 uses `ip6.arpa` with each hexadecimal digit reversed and separated, which produces a long and unmemorable name that tooling constructs for you.
The record type returned is PTR, and it holds a hostname.
Because the zone is derived from the address, only the holder of the address block can publish in it. Hosting providers expose this as a setting; some do not expose it at all.
Forward-confirmed reverse DNS
The check receiving mail servers actually perform is round-trip: take the connecting address, find its PTR record, resolve that hostname, and confirm one of its addresses is the one that connected.
A PTR that points at a name which does not resolve back fails the check as surely as no PTR at all.
Generic provider-assigned names — the kind containing the address itself and the provider's domain — pass the round trip but are treated as a weak signal by some receivers.
This is a reputation input rather than a rule. It is combined with SPF, DKIM, DMARC and sending history, and no single one of them decides delivery.
What it is used for beyond mail
Verifying a claimed crawler. Google documents reverse DNS as the way to confirm that a request claiming to be Googlebot really comes from Google, because the user agent string can be forged and the PTR record cannot.
Readable logs and traceroutes, where a name is more informative than an address.
Some access control lists match on resolved names, a practice that is slow and fragile compared with matching on addresses.
For serving a website, nothing depends on it. A web server with no PTR record works identically to one with a perfect record.
How to check it
`dig -x 203.0.113.10 +short` performs the reverse lookup and prints the hostname.
Then resolve that hostname forward with `dig <name> A +short` and confirm the original address is in the answer. That is the full round trip.
For mail, run the check against the address your mail actually leaves from, which on a hosted mail service is the provider's outbound server and not your web server.
If the record is wrong, the change is requested from whoever holds the address block. You cannot publish it in your own zone.
Frequently asked questions
- Does a website need a PTR record?
- No. Web serving does not depend on reverse DNS. It matters for outbound mail and for verifying that a crawler is who it claims to be.
- Who sets the PTR record?
- The holder of the IP address block, normally the hosting or network provider. It cannot be published in the domain's own zone.
- What is forward-confirmed reverse DNS?
- The round trip: the address resolves to a hostname, and that hostname resolves back to the same address. Mail servers commonly require it.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website