Reverse DNS (PTR) Setup: Why It Matters for Email and Diagnostics

What Reverse DNS Actually Does

Forward DNS answers "what IP address does this hostname have?" Reverse DNS answers the opposite: "what hostname belongs to this IP address?" It uses PTR (pointer) records stored in a special DNS zone called the in-addr.arpa domain for IPv4 and ip6.arpa for IPv6.

When a mail server receives an incoming connection from 192.0.2.25, it performs a reverse DNS lookup — it queries the PTR record at 25.2.0.192.in-addr.arpa. If that PTR record returns mail.example.com, and a forward lookup of mail.example.com returns 192.0.2.25, the connection passes the forward-confirmed reverse DNS (FCrDNS) check. Most spam filters require this match before accepting mail.

Why Your Email Ends Up in Spam Without PTR

Every major email provider — Gmail, Microsoft 365, Yahoo, and virtually every corporate mail gateway — performs a reverse DNS check on incoming SMTP connections. The logic is straightforward: legitimate mail servers have properly configured PTR records. Spam-sending botnets, compromised home routers, and cheap VPS instances often don't.

If your mail server connects from an IP address with no PTR record, or a PTR that doesn't resolve back to a real hostname, your messages get a higher spam score. In many cases, the receiving server rejects the connection outright with an error like "550 No PTR record" or "554 Connection refused — reverse DNS lookup failed."

Use the OpsCheck Reverse DNS Checker to test any IP address and see whether its PTR record is properly configured and forward-confirmed.

How PTR Records Are Structured

Unlike standard DNS records that live in your domain's zone file, PTR records are controlled by whoever owns the IP address block. For most organizations, this means your hosting provider, ISP, or cloud platform — not your DNS provider.

IPv4 PTR Format

An IP address like 203.0.113.45 is reversed and appended to .in-addr.arpa:

45.113.0.203.in-addr.arpa.  3600  IN  PTR  mail.example.com.

Notice the trailing dot on the hostname — this makes it a fully qualified domain name. Without the trailing dot, some DNS software appends the zone name, creating a malformed record.

IPv6 PTR Format

IPv6 addresses are expanded to their full 32-character hex form (no :: abbreviation), each hex digit separated by a dot, and reversed:

# For 2001:db8::1 (expanded: 2001:0db8:0000:0000:0000:0000:0000:0001)
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.  IN  PTR  mail.example.com.

How to Set Up a PTR Record

Step 1: Identify Who Controls Your IP Block

# Find the owner of your IP range
whois 203.0.113.45 | grep -i 'netname\|OrgName\|inetnum\|descr'
dig +short -x 203.0.113.45  # Quick reverse lookup to see if anything exists

The WHOIS output tells you which organization controls the IP block. If you're on AWS, DigitalOcean, Linode, or similar, the cloud provider owns the IP space. If you're on a dedicated server or colocation, your hosting provider or data center controls it.

Step 2: Configure PTR Through Your Provider

Most hosting and cloud providers let you set PTR records through their control panel or API. Common locations:

• AWS EC2: Console → EC2 → Elastic IPs → Select IP → Actions → Update reverse DNS
• DigitalOcean: Control panel → Networking → Domains → Create PTR record under the droplet's IP
• Linode: Cloud Manager → Network → IP Addresses → Edit RDNS
• Hetzner: Robot admin panel → Servers → IPs → Request reverse DNS change
• OVH: Control panel → IP → Reverse DNS management

For dedicated server providers and colocation, you typically open a support ticket requesting a PTR record for a specific IP. Most providers require the PTR hostname to have a forward A/AAAA record that points back to the same IP (FCrDNS), so set up that forward record at your DNS provider first.

Step 3: Create the Matching Forward Record

# In your DNS zone for example.com:
mail.example.com.  3600  IN  A  203.0.113.45

Without this forward record, FCrDNS checks will fail even though the PTR exists. Both directions must match.

Step 4: Verify Both Directions

# Forward lookup
dig +short A mail.example.com
# Expected output: 203.0.113.45

# Reverse lookup
dig +short -x 203.0.113.45
# Expected output: mail.example.com.

# Full verification in one command
host 203.0.113.45
# Expected output: 45.113.0.203.in-addr.arpa domain name pointer mail.example.com.

Run the OpsCheck Reverse DNS tool for a combined forward and reverse check with a clear pass/fail result.

Common PTR Mistakes and How to Fix Them

Mistake 1: PTR Points to a Hostname Without a Forward Record

The reverse lookup returns mail.example.com, but a forward lookup of mail.example.com returns nothing (NXDOMAIN). Fix: create the matching A/AAAA record that points back to the same IP.

Mistake 2: Multiple PTR Records for One IP

Each IP address should have exactly one PTR record. Some providers allow multiple PTRs, but this breaks FCrDNS and confuses spam filters. Pick one hostname and stick with it.

Mistake 3: Generic PTR Hostnames

Default PTR records like 203-0-113-45.static.hostprovider.net technically exist but fail the "does this look like a real mail server?" test. Mail servers expect a meaningful hostname — ideally the same hostname your mail server identifies itself with in the SMTP HELO/EHLO banner.

Mistake 4: Wrong IP or Wrong PTR Due to NAT

Common in VPS environments: your server thinks its IP is 10.0.0.5 (private NAT address), but the public-facing IP is 203.0.113.45. The PTR must match the public IP that external servers see when your mail server connects. Run a DNS lookup on your domain to confirm which IP your MX and A records actually resolve to from the public internet.

Mistake 5: Forgetting IPv6 PTR If You Have Dual-Stack

If your mail server listens on both IPv4 and IPv6, both addresses need PTR records. Many administrators configure IPv4 PTR correctly but forget IPv6 entirely. Gmail and other providers increasingly prefer IPv6 when available, so a missing IPv6 PTR can still tank your deliverability.

Beyond Email: PTR in Diagnostics and Security

Traceroute and Network Diagnostics

Tools like mtr and traceroute display reverse DNS names for each hop, making it easier to identify routers, ISP handoff points, and problem locations. Without PTR records, you get bare IP addresses and have to cross-reference them manually.

Log Analysis

Web server access logs, firewall logs, and intrusion detection systems are far more readable when IP addresses resolve to hostnames. Seeing "connection from vps123.hostname.com" instead of "connection from 203.0.113.45" speeds up debugging.

SSH and Access Control

Some SSH configurations use reverse DNS to verify connecting hosts. While not a security control on its own (PTR records can be spoofed), it helps with audit trails and log legibility.

Real-World Scenario: PTR Fix Saves a Marketing Launch

A SaaS company launched a new product and sent 50,000 announcement emails through their own Postfix server. Within hours, the marketing team reported that Gmail addresses were bouncing with "421 Service not available" errors. Investigation showed the server's IP had no PTR record — the hosting provider had recycled the IP from a previous customer and the default PTR was blank. After submitting a PTR change request to the host (which took about 15 minutes to propagate), deliverability returned to normal. The fix was simple, but only if you know to look for it.

Quick PTR Setup Checklist

1. Identify which organization controls your IP block (hosting provider, ISP, or cloud platform)
2. Create an A/AAAA forward record for your mail server hostname pointing to the IP
3. Request or configure a PTR record through your provider, pointing the IP to that same hostname
4. Verify both forward and reverse lookups match using dig or the OpsCheck Reverse DNS tool
5. If using dual-stack, repeat for IPv6 addresses
6. Send a test email to a Gmail address and inspect the headers for SPF/DKIM/DMARC and reverse DNS results
7. Monitor mail logs for any "no PTR record" or FCrDNS mismatches in SMTP rejection messages