Reverse DNS Lookup Explained (PTR Records, Email & Spam)

If you run a mail server, host an API that other people call, or manage infrastructure, you'll bump into reverse DNS sooner or later. Bad rDNS is the invisible reason legitimate email gets rejected and load-balancer health checks fail. This guide covers everything — what it is, how to check it, how to fix it.

Table of Contents

• What reverse DNS is
• How PTR records actually work
• Checking rDNS with nslookup and dig
• Checking rDNS online
• Why mail servers require rDNS
• Forward-Confirmed Reverse DNS (FCrDNS)
• How to set a PTR record
• IPv6 reverse DNS
• Common mistakes
• Troubleshooting missing rDNS
• Security best practices
• FAQ

What Reverse DNS Is

Forward DNS answers: 'What IP does this hostname resolve to?' Reverse DNS answers the opposite: 'What hostname does this IP belong to?' The answer is stored in a PTR record.

PTRs live in a special reverse zone. For IPv4, that's in-addr.arpa, with the IP octets reversed. IP 8.8.8.8 becomes 8.8.8.8.in-addr.arpa. For IPv6, it's ip6.arpa with each nibble reversed.

How PTR Records Actually Work

Only the entity that owns the IP block controls the reverse zone. Your hosting provider owns your VPS IP; your ISP owns your home IP. That's why you can't just add a PTR record to your own DNS — you have to ask the IP owner.

Checking rDNS with nslookup and dig

Windows / macOS / Linux: nslookup 8.8.8.8 returns dns.google. Linux / macOS with dig: dig -x 8.8.8.8 +short — same answer.

If the tool returns nothing or an NXDOMAIN, that IP has no PTR record.

Checking rDNS Online

Type the IP into an online Reverse DNS tool. Faster than opening a terminal, and shows the full query chain including TTL and authoritative server.

Why Mail Servers Require rDNS

When your mail server connects to Gmail's SMTP, Gmail immediately looks up the PTR of your IP. If it's missing, generic (like ec2-54-1-2-3.compute.amazonaws.com), or points to a name that doesn't forward back, Gmail is far more likely to reject or spam-fold your mail.

This is the #1 reason self-hosted mail servers fail. You spent hours on SPF, DKIM, DMARC — but nothing works because your PTR is wrong.

Forward-Confirmed Reverse DNS (FCrDNS)

The gold standard. Requires two things:

1. Your IP has a PTR pointing to a hostname (e.g. mail.yourdomain.com).
2. That hostname's A record points back to the exact same IP.

If both conditions are true, FCrDNS passes. Gmail, Outlook, and every serious mail server use FCrDNS as a strong 'legitimate sender' signal.

How to Set a PTR Record

DigitalOcean, Vultr, Linode, Hetzner

Set the droplet/server name to match your intended PTR (e.g. mail.yourdomain.com). rDNS is derived from the name in most providers' control panels.

AWS EC2

Elastic IPs → Actions → Update reverse DNS. Requires approval if your account is new (spam prevention).

Google Cloud

gcloud compute addresses update ADDRESS_NAME --update-labels reverse_dns=mail.yourdomain.com --region REGION (see current docs — syntax evolves).

Bare-metal or colocation

Contact your ISP or datacenter and request a PTR change for your IP block.

IPv6 Reverse DNS

Same concept, harder-looking format. IP 2606:4700:4700::1111 reverse zone: 1.1.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.6.0.6.2.ip6.arpa. Use dig -x 2606:4700:4700::1111 — dig builds the reverse name for you.

Common Mistakes

• Assuming you can add a PTR yourself in your registrar — you can't; only the IP owner can.
• Setting the PTR but forgetting the matching forward A — no FCrDNS, mail still rejected.
• Running mail from a residential ISP IP — impossible to get clean rDNS.
• Setting multiple PTRs on one IP — undefined behaviour, avoid.
• Not lowering TTL before a change — old PTR sticks around for days.

Troubleshooting Missing rDNS

1. Confirm the IP: dig +short mail.yourdomain.com.
2. Query PTR: dig -x <that-IP>.
3. If empty or wrong, log into your provider's panel and set it.
4. Wait TTL, then re-check.
5. Send a test message to a Gmail account and check the message source for 'compauth=pass' or the smtp.mailfrom line.

Security Best Practices

• Set unique PTRs per server so log correlation works across mail rejections.
• Avoid generic hostnames that leak provider info in PTRs.
• Combine rDNS with SPF, DKIM, DMARC — no single mechanism is enough on its own.
• Monitor for unauthorized PTR changes on your IP blocks.