Reverse DNS (PTR) lookup

A mail server that sends from an address with no reverse DNS, or one that does not match forward, gets treated as suspicious before anyone reads the message. It is the cheapest configuration mistake to make and one of the easiest to fix.

Try:

Free, no signup, no daily limit. We do not store what you check here.

Forward-confirmed reverse DNS

Having a PTR record is not enough on its own: receiving servers check that the name it points to resolves back to the same address. Anyone can publish a PTR claiming to be mail.google.com, but only the holder of the forward record can make that name resolve to their own address, so the round trip is what proves the claim. Publishing a PTR that does not confirm is worse than publishing none, because it looks like an attempt to impersonate.

Why cloud addresses often have none

Providers hand out addresses without reverse DNS by default and let you set it, which is why a server you spun up yesterday has none. If that machine sends mail, setting it is one of the highest-value things you can do for deliverability, and most providers expose it in the console.

Questions

I do not run a mail server. Does this matter?

Much less. Reverse DNS matters most for the machine that actually connects to other mail servers. If you send through a provider, theirs is what gets checked.

Who sets the PTR record?

Whoever controls the address block, which is your hosting provider or ISP, not your domain registrar. It is the one DNS record you cannot set from your own zone.

Related tools

When you need more than a free tool

This page answers what can be determined offline and from public DNS. The API adds live carrier and mailbox verification, a calibrated confidence score, and the full evidence trail behind every verdict.

Credits never expire. Inconclusive verdicts are never billed. Cancel in one call. See pricing or read the docs.