Reverse DNS (PTR) check

What this tool checks

The reverse DNS check looks up the PTR record of an IP address: the name the address points back to. It then runs the forward-confirmed reverse DNS test (FCrDNS) that mail servers apply to every connection.

You can enter:

• an IP address (192.0.2.25 or 2001:db8::25, though these documentation ranges themselves are refused): the tool checks that one address;
• a host name (mail.example.com): the tool looks up its A and AAAA records and checks each address, up to eight.

For each address it:

1. builds the reverse name, under in-addr.arpa for IPv4 or ip6.arpa for IPv6, and looks up its PTR record with our own resolver, straight from the nameservers of the reverse zone;
2. looks up the A (IPv4) or AAAA (IPv6) records of each PTR name;
3. passes the address if one of those records leads back to the same IP. That round trip is FCrDNS;
4. flags PTR names that look automatically generated: names containing the IP address, words such as dynamic, dsl, pool or cust, and the default names cloud providers give their servers.

Private and other special-use addresses are refused, because their reverse DNS is not public.

Reading the results

• IP → name → IP (forward-confirmed reverse DNS) - a pass. The PTR name resolves back to the address.
• No PTR record - a warning. Nobody has set reverse DNS for the address. If the reverse zone itself answers NXDOMAIN or SERVFAIL, the finding says so.
• The PTR name does not resolve back - a warning. The PTR exists, but its name has no A/AAAA record pointing at this address. The finding suggests the record to add.
• The PTR is a placeholder - a warning when the PTR points at a reverse name (such as its own in-addr.arpa name) instead of a host name.
• Looks like a generic ISP name - a warning, with the reason (for example "contains the IP address").
• More than one PTR record - a warning. Most software uses only one of them, chosen at random.
• The reverse names are not the host name - for information, when you entered a host name. This is normal for websites.

The table under the findings shows, for each address, the reverse name queried, the PTR answer and the forward lookup of each PTR name.

Common problems and fixes

No PTR record on a mail server

Receiving mail servers look up the PTR of the connecting IP. Many reject the mail outright when there is none, and most spam filters count it against you. The PTR lives in the reverse zone of whoever holds the address block, usually your hosting provider, cloud provider or ISP, not in your own domain's DNS. Set it in their control panel (often under "reverse DNS" or "rDNS"), or open a support ticket.

The PTR does not resolve back

FCrDNS needs both directions. If the PTR of 192.0.2.25 is mail.example.com, your zone needs:

mail.example.com.  IN  A  192.0.2.25

For IPv6 the record is an AAAA. If your server sends mail over IPv6, it needs a PTR and AAAA for that address too: large mailbox providers such as Gmail require valid forward and reverse DNS for every sending address.

Generic or dynamic-looking names

A name like host-192-0-2-25.dynamic.example.net tells blocklists and spam filters "home connection" or "unconfigured server". Set the PTR to the name your mail server uses in its SMTP greeting (HELO/EHLO), for example mail.example.com, and make sure that name resolves back to the address.

HELO name does not match

The HELO/EHLO name should be the PTR name, and it should resolve to the sending IP. Check what your server announces in its configuration (myhostname in Postfix, for example). Then check SPF, DKIM and DMARC with the email security check and whether the address is listed with the blocklist check.

FAQ