Reverse DNS (PTR)

Reverse DNS lookup: what a PTR record check tells you

A reverse DNS (rDNS) lookup asks which hostname belongs to an IP address. The answer lives in a PTR record. Enter an IPv4 address, or a hostname: the tool then resolves it to its IPv4 address first and checks that IP. That makes it easy to check the PTR record for a mail server — type mail.example.com and you see what the reverse zone returns for its IP.

The report has three parts:

• Hostname (PTR) — the name returned by the reverse query, or "Not found" if no PTR exists.
• Forward DNS match — the tool resolves that hostname back to IPv4 and compares it with the original address.
• PTR records table — the in-addr.arpa name, the target and the TTL.

A PTR with a forward mismatch usually means the hostname has no A record or points somewhere else. If the hostname has several A records, the first one is compared, so double-check load-balanced setups by hand.

Common rDNS results and fixes

If you entered a hostname and got "Invalid IP address", the name has no A record, so there is nothing to look up yet.

How reverse DNS works

PTR records sit in the special in-addr.arpa zone, with the IP's octets reversed. The PTR for 192.0.2.55 is stored at 55.2.0.192.in-addr.arpa. That reverse zone is delegated to whoever holds the IP block — your hosting provider, cloud platform or ISP — not to your domain's DNS host. This is why you can't add a PTR next to your A and MX records at the registrar, even though the hostname is yours.

If you hold your own address space and the reverse zone is delegated to you, a BIND zone entry looks like this:

$ORIGIN 2.0.192.in-addr.arpa.
55    IN  PTR  mail.example.com.

Keep the trailing dot, or the server appends the zone origin to the name. IPv6 uses ip6.arpa with the address expanded nibble by nibble; this tool checks IPv4.

Check PTR from the command line

dig -x 192.0.2.55 +short
dig -x 192.0.2.55 @1.1.1.1
host 192.0.2.55
nslookup 192.0.2.55

dig -x builds the in-addr.arpa name for you; adding @1.1.1.1 asks a public resolver and skips a stale local cache. Confirm the forward direction with dig +short A mail.example.com. On Windows, nslookup prints the PTR result on the Name line.

Why mail servers need reverse DNS

For a website, PTR barely matters: browsers and search engines don't look at it. For email it is one of the first checks. A receiving server sees only the connecting IP and immediately runs a reverse lookup on it.

• No PTR. Google's sender guidelines require a PTR record for every sending IP; messages from IPs without one get rejected or filtered to spam. Many Postfix servers refuse such connections with reject_unknown_reverse_client_hostname.
• PTR without forward match. Postfix's reject_unknown_client_hostname requires full forward confirmation, and Gmail requires matching forward and reverse DNS from bulk senders.
• Generic PTR such as 192-0-2-55.dynamic.isp.example. Spam filters read these as residential or dynamic addresses and score them down.

Also make your server's HELO/EHLO name match its PTR. In Postfix that's myhostname = mail.example.com in main.cf; in Exim it's primary_hostname.

Typical bounces look like this: Gmail returns 550-5.7.25 stating that the sending IP has no PTR record, and a strict Postfix receiver answers 450 4.7.1 Client host rejected: cannot find your reverse hostname. A 450 is temporary, so your server keeps retrying while mail piles up in the queue.

FCrDNS explained

Forward-confirmed reverse DNS closes the loop:

1. 192.0.2.55 → PTR → mail.example.com
2. mail.example.com → A → 192.0.2.55
3. Same IP — the mapping is confirmed.

Whoever controls an IP can put any name into its PTR, including someone else's domain. They cannot create an A record inside a domain they don't control. Only the matching pair proves that the IP and the domain belong together, and that is what the forward DNS badge in the report reflects.

How to set up a PTR record with your host

The order matters: create the A record mail.example.com → IP in your own zone first, then set the PTR with the provider, then verify both directions. Several control panels refuse to save a PTR until the forward record points at that IP. Changes propagate as caches expire, so watch the TTL shown in the report.

If your mail goes out through Google Workspace, Microsoft 365 or an email service provider, they manage PTR for their own servers; your job is SPF, DKIM and DMARC. You need your own PTR when your server sends directly: a VPS running Postfix, a web app on a dedicated box, a CRM or ERP that delivers mail itself.

Next checks for deliverability

With PTR and forward DNS in place, confirm that the IP is authorized in your domain's SPF record and isn't listed on DNS blacklists. Use DNS lookup for the domain's A, MX and TXT records, and What is my IP to see which public address your server or office actually uses.