Reverse DNS (rDNS) maps an IP address back to a hostname via PTR records — the opposite of a standard forward DNS lookup. For email delivery, rDNS is not optional: most mail servers reject connections from IPs without a valid PTR record. This guide covers the mechanics of rDNS, forward-confirmed reverse DNS (FCrDNS), setup procedures across major hosting providers, and how to verify your configuration.
What Is Reverse DNS?
📖 Definition — Reverse DNS (rDNS) is a DNS query that resolves an IP address to its associated hostname by looking up a PTR (Pointer) record in the special in-addr.arpa (IPv4) or ip6.arpa (IPv6) domain.
While forward DNS translates mail.example.com → 203.0.113.50, reverse DNS does the opposite: 203.0.113.50 → mail.example.com. This reverse mapping is stored in a PTR record and is managed by the owner of the IP address block — typically your hosting provider or ISP, not your domain registrar.
How rDNS Works Under the Hood
The DNS system uses a special namespace for reverse lookups. For IPv4, the in-addr.arpa zone holds PTR records with the IP octets reversed. For IPv6, ip6.arpa uses each nibble (hex digit) reversed.
IPv4 Example — IP 203.0.113.50 becomes the DNS query 50.113.0.203.in-addr.arpa
IPv6 Example — IP 2001:db8::1 (fully expanded: 2001:0db8:0000:0000:0000:0000:0000:0001) becomes 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
The delegation chain works through the Regional Internet Registries (RIRs). IANA delegates blocks of in-addr.arpa to RIRs (ARIN, RIPE, APNIC, etc.), who delegate to ISPs, who can further delegate to customers with their own IP allocations.
The Lookup Flow
# Querying rDNS for 203.0.113.50
dig -x 203.0.113.50
# Equivalent explicit PTR query
dig PTR 50.113.0.203.in-addr.arpa
# Using nslookup
nslookup 203.0.113.50PTR Record Format
A PTR record in a DNS zone file looks like this:
; IPv4 PTR record
50.113.0.203.in-addr.arpa. 3600 IN PTR mail.example.com.
; IPv6 PTR record
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR mail.example.com.ℹ️ The trailing dot after the hostname is critical — it indicates a fully qualified domain name (FQDN). Without it, the DNS server may append the zone's origin, producing an invalid record.
Key constraints of PTR records:
- An IP can have multiple PTR records, but best practice is exactly one
- The PTR must point to a valid, resolvable hostname — not an IP or a non-existent domain
- The hostname should resolve back to the same IP (forward-confirmed rDNS)
Forward-Confirmed Reverse DNS (FCrDNS)
📖 Definition — Forward-Confirmed Reverse DNS (FCrDNS) means that the PTR record for an IP resolves to a hostname, and an A/AAAA lookup on that hostname resolves back to the original IP. This circular verification proves the IP-hostname relationship is legitimate.
FCrDNS validation:
# Step 1: Reverse lookup
dig -x 203.0.113.50 +short
# → mail.example.com.
# Step 2: Forward lookup to confirm
dig A mail.example.com +short
# → 203.0.113.50 ✅ FCrDNS passes
# If forward returns a different IP → FCrDNS fails ❌Major providers like Gmail, Microsoft 365, and Yahoo all perform FCrDNS checks. Failure doesn't always result in rejection, but it contributes significantly to negative spam scoring.
Why Mail Servers Require rDNS
Reverse DNS serves as a basic identity check for mail servers. Legitimate organizations assign meaningful PTR records to their mail infrastructure; spammers using botnets, compromised machines, or disposable VPS instances rarely bother.
| Provider | rDNS Requirement | Behavior on Failure |
|---|---|---|
| Gmail | Strong recommendation | Increased spam score; may soft-reject (4xx) |
| Microsoft 365 | Required | Rejects with 550 5.7.1 if no PTR or generic PTR |
| Yahoo/AOL | Required | Rejects connections without valid rDNS |
| Postfix (default) | Configurable | reject_unknown_reverse_client_hostname |
⚠️ Generic PTR records like 50-113-0-203.static.provider.net are almost as bad as having no PTR at all. They signal that the IP is not dedicated mail infrastructure and will trigger spam filters.
HELO/EHLO Hostname Matching
When your mail server connects to a recipient's server, it announces itself with a HELO or EHLO command followed by a hostname. Best practice dictates a three-way match:
- The PTR record of your sending IP →
mail.example.com - The HELO/EHLO hostname your server announces →
mail.example.com - The A record of
mail.example.com→ your sending IP
💡 Configure your MTA's hostname to match your PTR record exactly. In Postfix, set myhostname = mail.example.com in main.cf. In Exchange, set the SMTP banner and send connector FQDN to match.
Setting Up PTR Records by Provider
PTR records are managed by the IP owner, not the domain owner. You typically need to configure them through your hosting provider's control panel or submit a support request.
| Provider | Method | Notes |
|---|---|---|
| AWS (EC2/EIP) | Submit a support request for rDNS | Requires Elastic IP; limits apply per region |
| DigitalOcean | Name your Droplet with the desired FQDN | PTR is auto-set to the Droplet name |
| OVH | Control Panel → IP → Reverse | Self-service, propagates within minutes |
| Hetzner | Cloud Console → Server → Networking → rDNS | Supports both IPv4 and IPv6 PTR |
| Vultr | Server Settings → IPv4 → Reverse DNS | Self-service for both IPv4 and IPv6 |
| GCP | Requires DNS zone for in-addr.arpa | Set up via Cloud DNS if you own the IP block |
IPv6 rDNS Challenges
IPv6 rDNS is conceptually identical to IPv4 but introduces practical challenges due to the massive address space.
The Nibble Format Problem
A single IPv6 address expands to a 64-character-long PTR name. Each hex digit becomes a separate label separated by dots. Managing PTR records for large IPv6 blocks is impractical using traditional zone files.
Delegation Gaps
Many ISPs do not delegate IPv6 reverse zones to customers, and some do not populate PTR records for assigned IPv6 ranges at all. This means IPv6-originated mail can fail rDNS checks even when the sender is legitimate.
💡 If your ISP doesn't offer IPv6 PTR management, consider sending email over IPv4 only, or use an email relay service that provides proper rDNS for its IPv6 infrastructure.
# Verify IPv6 PTR
dig -x 2001:db8::1
# Explicitly query ip6.arpa
dig PTR 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa +shortVerification Commands
Use our Reverse IP Lookup tool for instant PTR checks, or verify from the command line:
# dig — reverse lookup
dig -x 203.0.113.50 +short
# nslookup — Windows/Linux
nslookup 203.0.113.50
# host — Linux/macOS
host 203.0.113.50
# Verify FCrDNS (two-step)
PTR=$(dig -x 203.0.113.50 +short)
echo "PTR: $PTR"
dig A "$PTR" +short
# Should return 203.0.113.50
# Check with a specific DNS resolver
dig -x 203.0.113.50 @8.8.8.8 +shortThe DNS Lookup tool can query PTR records directly alongside A, MX, and other record types for a complete DNS audit.
Best Practices
💡 Treat your PTR record as part of your email identity stack: it should match your HELO hostname, your MX record, and your SPF-authorized sending IP. Consistency across all four builds maximum trust.
- Set a meaningful PTR hostname like
mail.yourdomain.com— avoid generic ISP names - Ensure FCrDNS passes: PTR → hostname → A record → same IP
- Match the PTR to your HELO/EHLO hostname exactly
- Use one PTR per IP — multiple PTR records cause unpredictable results
- Set up PTR for both IPv4 and IPv6 if you send over dual-stack
- Verify PTR propagation from multiple resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1)
- Re-check PTR records after any IP or hosting migration
Common Mistakes
| Mistake | Impact | Fix |
|---|---|---|
| Setting PTR in your DNS zone instead of hosting provider | PTR not effective — the IP owner's DNS is authoritative | Configure via hosting provider control panel |
| PTR points to a hostname that doesn't resolve | FCrDNS fails; mail rejected | Create matching A/AAAA record for the PTR hostname |
| Using a domain you don't control in PTR | FCrDNS fails; looks like spoofing | Use a subdomain of your own domain |
| Forgetting to update PTR after IP change | Old PTR still cached; new IP has no PTR | Update PTR immediately when migrating IPs |
| Ignoring IPv6 PTR | IPv6 email connections rejected | Set PTR for IPv6 or disable IPv6 sending |
| HELO hostname doesn't match PTR | Spam score increase, possible rejection | Align MTA myhostname with PTR value |
Tools
🔄 Reverse IP Lookup — Instantly resolve any IP to its PTR hostname and verify forward-confirmed rDNS.
🔍 DNS Lookup — Query A, AAAA, PTR, MX, TXT, and other record types for complete DNS diagnostics.
References
- 📄 RFC 1035 — Domain Names: Implementation and Specification
- 📄 RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)
- 📄 RFC 5321 §4.1.4 — EHLO Hostname Requirements
- 📄 Google — Email Sender Guidelines (rDNS requirements)
- 📄 Microsoft 365 — Anti-spam protection (reverse DNS checks)
🚀 Free ToolZilla tools used in this article
All client-side, no signup, no upload — open them in a new tab while you read:
- 🔧 Reverse IP Lookup — try it free in your browser.
- 🔧 DNS Lookup — try it free in your browser.
- 🧰 Browse all 60+ free tools →
🎯 Key Takeaway — A valid PTR record is table stakes for email delivery. Set a meaningful hostname that passes forward-confirmed rDNS (PTR → A → same IP), matches your HELO/EHLO, and is configured through your hosting provider — not your domain registrar. Verify from external resolvers after every infrastructure change.