A PTR record maps an IP address back to a domain name — the reverse of what A records do.
When a mail server receives an incoming connection, it performs a reverse DNS lookup on the connecting IP address to determine the domain that owns it.
If you don’t have a valid PTR record, your connection appears suspicious, and your emails suffer.
PTR records help you:
- Verify sender identity through reverse DNS lookup
- Support network diagnostics with readable hostnames
- Signal legitimate infrastructure to receiving mail servers
- Satisfy Gmail, Yahoo, and Microsoft authentication requirements
Mail servers perform this check on every incoming connection. The lookup takes milliseconds, happens silently, and influences whether your emails reach inboxes or spam folders. Most senders never think about PTR records until deliverability problems force the issue.
The mechanism works like a caller ID for email. When someone calls you, the caller ID shows who’s on the line (or at least who claims to be).
PTR records enable mail servers to perform the same verification — checking whether the IP address connecting to them actually belongs to the domain it claims to represent.
How do PTR records differ from A records?
Forward DNS and reverse DNS perform opposite functions. A records translate domain names to IP addresses (so browsers can find servers). PTR records translate IP addresses back to domain names (so servers can verify who’s connecting).
| Direction | Record type | Input | Output |
| Forward DNS | A record | Domain name | IP address |
| Reverse DNS | PTR record | IP address | Domain name |
The distinction matters because email authentication relies on both directions matching. A domain can list any IP address in its SPF record, but the IP itself requires a PTR record to confirm the relationship.
Also, mail servers don’t just check that a PTR record exists — they verify the relationship works in both directions. This process is called Forward-Confirmed reverse DNS (FCrDNS), and it works like this:
- Reverse lookup: IP address → domain name (via PTR)
- Forward lookup: domain name → IP address (via A record)
- Verification: both IPs must match
If your PTR record points to “mail.example.com” but the A record for mail.example.com resolves to a different IP, the verification fails. Gmail and Yahoo now require FCrDNS for bulk senders as part of their 2024 authentication requirements.
Why do mail servers check PTR records?
The check serves as an early filter against illegitimate senders. Before examining SPF, DKIM, or DMARC, mail servers can quickly verify whether the connecting IP has proper reverse DNS configured.
Spam prevention
Most spam originates from IPs without valid PTR records — compromised home computers, botnets, throwaway servers spun up for a single campaign.
Checking PTR catches obvious problems before deeper analysis begins. The check is fast (a single DNS query) and filters significant junk traffic.
Reputation signals
A properly configured PTR signals legitimate email infrastructure. Missing or misconfigured PTR suggests something’s off:
- Amateur or rushed setup
- Temporary/disposable server
- Potentially compromised machine
- Residential IP (not meant for mail sending)
These signals feed into sender reputation calculations. Even if emails technically deliver, missing PTR hurts your standing with mailbox providers over time.
What does a PTR record look like technically?
PTR records don’t live in your regular DNS zone alongside A records and MX records. They exist in a special namespace managed by whoever controls the IP address block — typically your ISP or hosting provider.
The .arpa namespace
All PTR records live within the .arpa top-level domain (a legacy namespace reserved for network infrastructure). IPv4 records use .in-addr.arpa, while IPv6 uses .ip6.arpa.
The IP address gets reversed to fit the DNS hierarchy. For the IP 192.168.1.25:
- Original IP: 192.168.1.25
- Reversed: 25.1.168.192
- Full PTR zone: 25.1.168.192.in-addr.arpa
- Points to: mail.example.com.
That trailing dot is essential. Without it, some DNS systems append the zone name to your hostname, creating invalid records.
Record components
| Field | Description | Example |
| Host/Name | Last octet (or relevant portion) | 25 |
| Points to | FQDN with trailing dot | mail.example.com. |
| TTL | Cache duration in seconds | 3600 |
| Zone | Reverse DNS zone | 1.168.192.in-addr.arpa |
IPv6 differences
IPv6 PTR records use .ip6.arpa and break the address into 4-bit nibbles rather than 8-bit octets. The resulting format is significantly longer — a single IPv6 address expands to 32 characters when reversed. Most users dealing with IPv6 let their hosting provider handle the formatting.
Who controls your PTR record?
Here’s where PTR records get administratively awkward — you probably don’t control yours directly. PTR records are tied to IP ownership, not domain ownership. The entity that owns the IP block controls the reverse DNS zone.
| Hosting type | PTR management | Your action |
| Shared hosting | Provider handles automatically | Usually none required |
| VPS/Dedicated | Provider controls the zone | Request via ticket or control panel |
| Cloud (AWS, GCP, Azure) | User configures after verification | Set up in the cloud console |
| Enterprise IP block | Your organization manages | Configure in your DNS server |
For shared hosting, PTR records are typically pre-configured (often pointing to the provider’s generic hostname). VPS and dedicated server users usually need to submit a support ticket or access a specific control panel section to request custom PTR records.
Cloud platforms offer more flexibility. AWS, Google Cloud, and Azure let users configure reverse DNS through their consoles — but only after verifying domain ownership. The verification prevents anyone from claiming your domain on their IP addresses.
If your provider doesn’t support custom PTR records (some don’t), you’re stuck with their default hostname. Generic PTRs like “server123.hostingprovider.com” satisfy the basic requirement but don’t help your brand reputation.
How do you verify your PTR record?
Checking your PTR configuration takes seconds with the right tools. Verification confirms three things: the record exists, it points to your domain (not a provider default), and the FCrDNS relationship is intact.
Command-line tools
Two options work across operating systems:
- dig -x 192.168.1.25 — handles the reversed IP formatting automatically
- nslookup 192.168.1.25 — works on Windows, Mac, and Linux
The output shows what domain name (if any) the IP resolves to. If you see your own domain, good. If you see a generic provider hostname or “NXDOMAIN” (no record), there’s work to do.
Online tools
Here are some online tools that can let you check your PTR record:
| Tool | What it checks |
| MXToolbox | PTR record + FCrDNS verification |
| EasyDMARC | Reverse DNS with provider comparison |
| whatsmydns.net | Global PTR propagation |
| Google Postmaster Tools | PTR issues for your sending domain |
Verification checklist
Run through these checks for every sending IP:
- PTR record exists (not NXDOMAIN)
- PTR resolves to your domain (not provider default)
- A record for that hostname returns the same IP
- No multiple PTR records for a single IP
If any check fails, your emails are at risk. Taking an email deliverability test can help identify PTR issues alongside other authentication problems.
What happens without a valid PTR record?
Missing or misconfigured PTR records create immediate and long-term problems. Some issues show up right away; others accumulate silently until deliverability collapses.
Delivery failures
Many mail servers outright reject connections from IP addresses without PTR records — no negotiation, or second chances. Others accept the connection but apply heavy spam scoring penalties. Either way, your emails suffer.
The rejection often occurs before your SPF, DKIM, and DMARC records are even checked. You might have perfect authentication everywhere else, but missing PTR undermines the entire effort.
Reputation damage
Even when emails are technically delivered, missing PTR hurts your email reputation over time. Mailbox providers track authentication signals across millions of messages. Senders with proper PTR records statistically behave better than those without, and the algorithms learn this pattern.
Diagnostic confusion
PTR records also support network troubleshooting — tools like traceroute and MTR display hostnames via reverse DNS lookups. Without PTR records, you see raw IP addresses only, making it harder to identify which hop in a network path is causing problems.
PTR records are just one piece of the puzzle
PTR records are foundational but not sufficient on their own.
They work alongside SPF, DKIM, and DMARC to establish sender legitimacy. Missing any piece weakens the whole structure.
If you’re unsure about your reverse DNS configuration, run a deliverability test to check authentication status across all protocols.
For persistent PTR issues (especially when your hosting provider isn’t cooperative), an email deliverability consultant can help identify workarounds and alternative sending infrastructure.
Frequently asked questions
Here are some commonly asked questions about PTR records:
Yes. Every IP that sends email should have its own PTR record pointing to a valid hostname with a matching A record. Multiple sending IPs each need individual PTR configuration — you can’t share one PTR across several IPs.
Technically possible, but not recommended. Multiple PTR records cause unpredictable results during lookups (different queries may return different hostnames). Stick to one PTR per IP for reliable verification.
Depends on the default. Generic hostnames like “server123.provider.com” satisfy basic verification — mail servers see that a PTR record exists. But generic hostnames don’t build your brand reputation. Request a custom PTR matching your sending domain when possible.
PTR changes typically propagate within a few hours, but TTL settings and provider caching affect timing. Allow 24-48 hours before assuming changes failed. Some providers cache aggressively, especially for previously-queried records.
