Your email server is configured correctly. SPF passes. DKIM signatures verify. DMARC alignment checks out. But Gmail is still rejecting your messages with a cryptic error: 550-5.7.1 The IP address sending this message does not have a PTR record setup.
The missing piece is reverse DNS. Specifically, a PTR record that maps your mail server's IP address back to a hostname. It's one of the oldest checks in email delivery, predating SPF and DKIM by decades, and major email providers still enforce it as a baseline trust signal.
Reverse DNS is also one of the most commonly overlooked DNS configurations because it lives in a different part of the DNS hierarchy than your regular records. You can't set it up in your normal DNS provider's dashboard. It requires coordination with whoever owns the IP address block, which is usually your hosting provider or ISP.
This guide explains what reverse DNS is, why email providers require it, how to set it up, and how to verify it's working.
What Is Reverse DNS?
Standard (forward) DNS maps a domain name to an IP address:
mail.yourcompany.com. → 203.0.113.50Reverse DNS does the opposite. It maps an IP address back to a domain name:
203.0.113.50 → mail.yourcompany.com.This mapping is stored in a PTR (Pointer) record. PTR records live in a special DNS zone called the reverse lookup zone, under the in-addr.arpa namespace for IPv4 and ip6.arpa for IPv6.
For the IP address 203.0.113.50, the PTR record would be:
50.113.0.203.in-addr.arpa. 3600 IN PTR mail.yourcompany.com.Notice that the IP octets are reversed in the PTR record name. This is because the DNS hierarchy reads right-to-left, so the most specific part (the individual host) needs to be on the left.
Who Controls PTR Records?
This is the key difference from forward DNS. Your domain's A, MX, and TXT records are controlled by you through your DNS provider. PTR records are controlled by whoever owns the IP address block, which is typically your hosting provider, cloud provider, or ISP.
If your mail server runs on AWS EC2, Amazon controls the reverse DNS zone for that IP. If it's on DigitalOcean, DigitalOcean controls it. If it's on a dedicated server with your ISP, the ISP controls it.
You'll need to configure the PTR record through your IP owner's control panel or by contacting their support.
Why Email Providers Require Reverse DNS
When your mail server connects to Gmail, Outlook, or Yahoo to deliver an email, the receiving server performs a reverse DNS lookup on the connecting IP address. It's checking a fundamental question: does this IP address identify itself, and does the identity match?
The Three-Way Handshake of Email Trust
Receiving mail servers verify a chain of consistency:
- Forward DNS: Does
mail.yourcompany.comresolve to203.0.113.50? (A record check) - Reverse DNS: Does
203.0.113.50resolve back tomail.yourcompany.com? (PTR record check) - HELO/EHLO match: Does the SMTP greeting hostname match the PTR record?
When all three match, the receiving server has high confidence that the connecting server is who it claims to be. When any link breaks (no PTR record, PTR doesn't match the forward DNS, or HELO hostname doesn't match), the trust level drops and the message is more likely to be rejected or sent to spam.
What Google Says
Google's Email Sender Guidelines are explicit: "The sending IP address must have a PTR record. The hostname in the PTR record must have a forward DNS entry (A or AAAA record) that resolves to the sending IP." This is listed as a basic requirement, not a recommendation. Messages from IPs without valid PTR records are significantly more likely to be rejected.
Why This Check Exists
Reverse DNS is one of the oldest anti-spam signals because legitimate mail servers have PTR records and most spam sources don't. Residential ISP connections, compromised IoT devices, and botnet nodes typically have generic or absent PTR records (like pool-203-0-113-50.res.isp.net or nothing at all). By requiring a valid, matching PTR record, receivers filter out a significant portion of illegitimate mail at the connection level, before even looking at the message content.
Common Reverse DNS Problems
No PTR Record at All
The IP address has no reverse DNS entry. The receiving server performs a PTR lookup and gets NXDOMAIN or an empty response. This is the most common issue, especially on cloud instances and VPS servers where PTR records aren't configured by default.
Impact: Gmail and many other providers will reject messages outright or route them to spam. The bounce message typically includes a reference to missing PTR records.
Fix: Configure a PTR record through your hosting provider's control panel. Most major providers support this: AWS (via Elastic IP settings), Google Cloud (via DNS zone for the IP block), DigitalOcean (via Networking settings), Azure (via Public IP resource configuration), and dedicated server providers (via support request or control panel).
Generic PTR Record
The IP has a PTR record, but it's a generic hostname assigned by the provider:
ec2-203-0-113-50.compute-1.amazonaws.comThis is better than no PTR record, but it doesn't match your mail server's hostname. Some receiving servers accept generic PTRs; others treat them as only marginally better than missing PTRs.
Fix: Replace the generic PTR with your actual mail server hostname (e.g., mail.yourcompany.com).
Forward/Reverse Mismatch
The PTR record resolves to mail.yourcompany.com, but the A record for mail.yourcompany.com resolves to a different IP. This forward-confirmed reverse DNS (FCrDNS) check fails.
Impact: Reduced deliverability. The receiving server sees that the PTR and A record don't agree, which indicates misconfiguration or a potentially spoofed identity.
Fix: Ensure the PTR record's hostname resolves back to the same IP address via its A record. The chain must be bidirectional: IP → hostname → same IP.
Multiple IPs, Incomplete PTR Coverage
Your mail infrastructure uses multiple outbound IPs (for high-volume sending or redundancy), but only some have PTR records configured. Messages sent from the uncovered IPs get rejected.
Fix: Every IP address that sends email must have its own PTR record. Audit all outbound IPs and verify PTR coverage for each one.
IPv6 Without PTR
Your server sends email over IPv6 but only has a PTR record for the IPv4 address. Some receiving servers will try to connect via IPv6 first, perform the PTR lookup on the IPv6 address, and reject the connection.
Fix: If your server has an AAAA record and accepts IPv6 connections, configure PTR records for the IPv6 address as well. IPv6 PTR records use the ip6.arpa zone and require each nibble (4-bit segment) of the address to be reversed.
How to Set Up Reverse DNS
The process varies by provider, but the general steps are:
Step 1: Identify Your Mail Server's IP
Use the DNS lookup tool at dnsassistant.com/tools to query your domain's MX records. This shows which hostname handles your email. Then query the A record for that hostname to get the IP address.
Step 2: Configure the PTR Record with Your IP Owner
Log into your hosting provider's control panel and look for reverse DNS or PTR settings. Set the PTR record to match your mail server's hostname exactly.
AWS: Associate an Elastic IP with your EC2 instance, then use the ec2:CreateReverseDnsRecord API or submit a request through the EC2 console under "Elastic IPs → Reverse DNS."
Google Cloud: Set the PTR record in the Cloud DNS zone for your IP range, or configure it on the VM instance's network interface settings.
DigitalOcean: Go to Networking → PTR Records. Enter your Droplet's IP and the desired hostname.
Dedicated servers / ISPs: Contact support or use the provider's DNS management panel to set a custom PTR record.
Step 3: Ensure Forward DNS Matches
The hostname in your PTR record must have an A record (forward DNS) that resolves back to the same IP. If your PTR is mail.yourcompany.com, then mail.yourcompany.com must have an A record pointing to the same IP. Verify this with the DNS lookup tool.
Step 4: Match Your SMTP HELO/EHLO Hostname
Configure your mail server's HELO/EHLO hostname to match the PTR record. In Postfix, this is myhostname in main.cf. In Exchange, it's the SMTP banner. In cloud email services (SendGrid, Postmark, etc.), this is typically handled automatically.
Step 5: Verify the Full Chain
After configuration, verify:
- PTR lookup: IP → hostname (check with your provider's tools or a reverse DNS lookup tool)
- A record: hostname → same IP (check with the DNS lookup tool)
- Send a test email: Send to a Gmail address and check the headers for SPF, DKIM, and DMARC pass results. Look for any PTR-related warnings.
Reverse DNS Beyond Email
While email deliverability is the primary reason to configure PTR records, reverse DNS serves other purposes:
Security Logging and Forensics
Firewalls, intrusion detection systems, and security logs often perform reverse DNS lookups on connecting IP addresses. Without PTR records, logs show raw IP addresses that analysts have to manually look up. With PTR records, logs show hostnames that are immediately identifiable.
Access Control
Some services restrict access based on reverse DNS. SSH servers can be configured to require valid PTR records. Web applications may use reverse DNS as an additional validation layer for API clients.
Network Diagnostics
Tools like traceroute use reverse DNS to display hostname labels for each hop. Without PTR records, the output shows only IP addresses, making network path analysis harder.
How DNS Assistant Helps
While PTR records themselves are managed by your IP provider (not your DNS provider), DNS Assistant monitors the forward DNS records that must stay in sync with your reverse DNS:
- MX record monitoring: Alerts when your MX records change, which could indicate a mail routing change that requires PTR record updates
- A record monitoring: Alerts when your mail server's IP changes. Any IP change requires a corresponding PTR record update at the new IP's owner
- SPF record monitoring: Tracks changes to your SPF record, which defines authorized sending IPs, each of which needs a PTR record
- Email authentication tracking: Monitors SPF, DKIM, and DMARC together, giving you full visibility into the DNS records that affect email deliverability
The Free Domain Risk Report checks your MX records, SPF configuration, DKIM status, and DMARC policy in a single scan, helping you identify email authentication gaps. Use the DNS lookup tool to query your MX and A records to verify the forward DNS side of your PTR configuration.
For continuous monitoring of all email-related DNS records with real-time alerting, sign up at dnsassistant.com.
Start Monitoring Your DNS Today
Get real-time alerts, track record changes, and keep your domains secure with DNS Assistant.
Sign Up Free