What this checks
A reverse IP lookup asks DNS the opposite of the usual question. Instead of "what address does this name point to," it asks "what name does this address claim," and the answer comes from a PTR record in reverse DNS. We take the IPv4 or IPv6 address you enter, query its reverse zone, and return whatever hostname (or hostnames) the address is configured to announce.
The key thing to understand is who provides that answer. A PTR record lives in the reverse zone controlled by whoever owns the IP block — typically the hosting provider or network operator — not the person who owns the website. So the name you get back describes the address's place on the network, which may or may not match any domain running on it.
How to read the results
A result is the list of hostnames the address's PTR record returns — usually one, occasionally several.
For a well-run mail or infrastructure host it's a clean, meaningful name like mail.example.com.
For a lot of cloud and consumer addresses it's an auto-generated name from the provider that encodes
the IP itself, which tells you the network operator but nothing about the service.
"No PTR record for this address" is a completely normal answer. Reverse DNS is optional for most uses, so plenty of perfectly healthy addresses simply have none configured. It's only a problem in the specific contexts — mainly email — where a missing or mismatched PTR is actively penalised.
Why PTR matters for email
Reverse DNS is quiet infrastructure right up until you send mail from your own server, where it becomes one of the first things receiving systems check. A missing or generic PTR is a classic reason legitimate mail lands in spam or is rejected outright.
- Deliverability gate. Many mail servers refuse or downgrade connections from an IP with no PTR, or with a default provider PTR that doesn't match the sending domain.
- Forward-confirmed reverse DNS. The strong signal is FCrDNS: the PTR points to a hostname, and that hostname's forward record points back to the same IP. Both directions agreeing is what mail systems actually want to see.
- Set it at the network level. Because the record lives with the IP's owner, you set a PTR through your hosting or cloud provider's control panel, not in your domain's normal DNS zone.
FAQ
Why doesn't my server have a PTR?
Because reverse DNS isn't set up by default on most addresses — it's an optional record the IP's owner has to create. Shared hosting, many cloud instances, and residential connections often ship without a custom PTR, or with a generic provider one. If you need a specific PTR (usually for mail), you request it from whoever controls the IP block.
How do I set one?
Through your hosting or cloud provider, not your registrar or normal DNS host. Because the reverse zone belongs to the IP block's owner, providers expose PTR configuration in their console (often labelled "reverse DNS" on the IP or instance). Set it to a hostname you control, then make sure that hostname's forward record points back to the same IP.
Why does the PTR not match my domain?
Because the PTR describes the IP address, which the network operator controls, while your domain is yours. On shared or cloud infrastructure one address serves many sites, so its single PTR can only name one thing — usually the provider's default. That mismatch is expected and harmless outside email; for mail you'd set a dedicated PTR that matches your sending hostname.
Do PTRs matter outside email?
Rarely in a way you'll notice. Some logging, monitoring, and diagnostic tools display the PTR to make addresses human-readable, and a few network services perform reverse checks, but web and API traffic doesn't depend on it. For the vast majority of hosts, email deliverability is the only place a PTR genuinely changes an outcome.