PTR Record: Reverse DNS Explained
Understand and configure reverse DNS to improve your email deliverability.
PTR (Pointer) records enable reverse DNS resolution: finding a domain name from an IP address. If A records map names → IPs, PTR records do the opposite: IP → name. This bidirectional verification capability is fundamental for email deliverability and network security.
When an email server receives a connection, it often performs a reverse DNS check. If the sender's IP has no PTR, or if the PTR doesn't match the announced hostname, the email risks being marked as spam or rejected. Major providers (Gmail, Microsoft, Yahoo) are particularly strict on this.
Unlike most DNS records you manage directly, PTRs are typically configured by the IP range owner - usually your host or ISP. Understanding how they work and how to configure them is essential for any mail server administrator.
What is a PTR Record?
PTR records work in a special DNS zone called in-addr.arpa:
- Reverse zone: PTRs live in special zones: X.Y.Z.W.in-addr.arpa for IPv4, where IP octets are reversed. IP 192.0.2.1 becomes 1.2.0.192.in-addr.arpa.
- Managed by IP owner: Only the IP range owner (typically your host or ISP) can create PTRs for these addresses. You must ask them to configure it.
- FCrDNS matching: Forward-Confirmed reverse DNS: the PTR points to a name, and that name has an A record pointing back to the original IP. This double verification is crucial.
- One PTR per IP: Unlike A records where a name can have multiple IPs, each IP has only one PTR. Choose the associated name wisely.
Why PTR Is Critical for Email
Missing or misconfigured reverse DNS directly impacts your emails:
- Anti-spam verification: Email servers verify that the sending IP has a valid PTR. Without PTR, many servers reject the email or mark it as spam immediately.
- FCrDNS matching: The PTR must point to a name that resolves back to the same IP (forward-confirmed). An "orphan" PTR without matching A is as suspicious as no PTR.
- IP reputation: A generic PTR (like 123-45-67-89.static.provider.net) often indicates residential or non-dedicated IP. Use a relevant name like mail.yourdomain.com.
- Server identification: Beyond email, reverse DNS helps identify servers in logs and diagnostic tools. A clear PTR makes troubleshooting easier.
Configure a PTR Record
PTR configuration requires coordination with your IP provider:
- Identify the IP owner: Use whois to identify who controls your IP range. It's typically your host, your ISP, or yourself if you have your own range.
- Request PTR creation: Contact your host's support and ask them to configure the PTR for your IP pointing to the desired name (e.g., mail.yourdomain.com).
- Create the matching A record: In your DNS zone, create an A record for the chosen name pointing to this IP. PTR and A must match.
- Verify configuration: Test with dig -x YOUR_IP or online tools. Verify the PTR resolves to the correct name, and that name resolves to the IP.
PTR Examples and Verification
Here's how to verify and understand PTR records:
# Check an IP's PTR (reverse lookup)
$ dig -x 203.0.113.25 +short
mail.example.com.
# Verify the A matches (forward lookup)
$ dig A mail.example.com +short
203.0.113.25
# Successful configuration: FCrDNS verified
# IP → PTR → name → A → same IP
# Full verification with MXToolbox or similar
# or via nslookup
$ nslookup 203.0.113.25
25.113.0.203.in-addr.arpa name = mail.example.com.
# In the reverse zone file (managed by IP owner)
; Zone 113.0.203.in-addr.arpa
25 IN PTR mail.example.com.
# Email deliverability test
$ telnet alt1.gmail-smtp-in.l.google.com 25
220 mx.google.com ESMTP
HELO mail.example.com
250 mx.google.com at your service
FCrDNS (Forward-Confirmed reverse DNS) verification is key: the PTR must point to a name, and that name must have an A pointing back to the original IP. This bidirectional consistency is what email servers verify.
PTR Best Practices
Optimize your reverse DNS configuration:
- Meaningful name: Use a relevant domain name (mail.yourdomain.com) rather than a generic one. This improves reputation and trust.
- One PTR per function: If you have multiple servers (mail, web, api), use different IPs with distinct PTRs rather than one generic PTR.
- HELO/PTR consistency: Your mail server's HELO/EHLO name must match the PTR. Inconsistencies are spam signals.
- Regular verification: Hosting changes can break your PTR. Monitor it regularly and after any migration.
PTR Checklist for Mail Server
- PTR configured for mail server IP
- Matching A record created in your zone
- FCrDNS verified (IP → name → IP)
- HELO/EHLO configured with same name
- SPF, DKIM, DMARC configured as complement
- Deliverability test performed
FAQ - PTR Records
Why can't I create my own PTR?
PTRs are managed in the reverse zone (in-addr.arpa), which belongs to the IP range owner. Only your host or ISP can create PTRs for their IPs.
How long to propagate a PTR?
PTRs typically have short TTLs (1-24h). Once configured by your host, propagation takes a few hours at most.
My host refuses to create a PTR, what to do?
Some shared hosts don't allow custom PTRs. Options: switch to VPS/dedicated, use an email sending service (SendGrid, Mailgun), or change hosts.
Do I need a PTR for IPv6 too?
Yes, if your mail server uses IPv6, also configure the IPv6 PTR (ip6.arpa zone). Many servers check both.
Does PTR affect SEO or web?
No, PTR doesn't affect SEO or standard web functionality. Its main impact is on email deliverability and log identification.
Can MoniTao monitor my PTR?
Yes, MoniTao can monitor your DNS records including reverse DNS. You're alerted if your PTR changes or disappears.
Ensure Your Email Deliverability
Reverse DNS via PTR records is an often-neglected pillar of email deliverability. A properly configured PTR with verified FCrDNS significantly improves your chances of reaching the inbox.
Contact your host to configure an appropriate PTR, create the matching A record, and monitor this configuration. MoniTao can alert you if your reverse DNS changes unexpectedly.
Ready to Sleep Soundly?
Start free, no credit card required.