Smart. Focused. Email.
Fast, cross-platform email designed to filter out the noise - so you can focus on what's important.
Definition
💡 Reverse DNS lookup: The process of resolving an IP address back to a domain name, the opposite of how DNS normally works. For email, it's how receiving servers check whether a sending IP address actually belongs to the domain it claims to represent. Normal DNS goes domain to IP. Reverse DNS goes IP back to domain. Both directions need to match.
Does this affect you?
Probably not directly, but it's worth knowing why.
If you send email through Gmail, Google Workspace, Outlook, or Microsoft 365, reverse DNS is handled automatically by Google and Microsoft on their own sending IPs. You don't touch it. Same goes for shared IPs on platforms like Mailchimp or Klaviyo. Those ESPs manage PTR records for the IP addresses their servers send from.
Where reverse DNS becomes your problem is if you're sending from a dedicated IP address (through a service like SendGrid or Mailgun) or running your own mail server on a VPS or cloud instance. In those situations, the PTR record for your IP isn't set automatically. You need to configure it. And if it's missing or misconfigured, your email deliverability suffers.
The practical test: if your emails are landing in spam and your DKIM, SPF, and DMARC record are all passing, a missing or broken PTR record is a logical next thing to check.
How reverse DNS lookup works
The process is called Forward-Confirmed reverse DNS (FCrDNS). Here's what happens when your email arrives at a receiving server.
The receiving server takes your sending IP address and queries the DNS for the PTR (Pointer) record associated with it. This lookup goes into a special DNS zone called in-addr.arpa. If a PTR record is configured, the lookup returns a hostname, something like mail.yourbusiness.com.
The receiving server then does a regular forward DNS lookup on that hostname to confirm it resolves back to the original IP. If the IP matches, the check passes. If the hostname resolves to a different IP, or there's no PTR record at all, the sender looks untrustworthy.
That bidirectional verification is the point. Anyone can claim to send from yourbusiness.com. Far fewer people can manipulate both the PTR record and the forward DNS to make them match. Since Google and Yahoo tightened bulk sender requirements in 2024, Gmail now returns a specific error (421 4.7.23) for IPs without a valid PTR record. It's not optional anymore for anyone sending meaningful volume.
Missing or mismatched reverse DNS is one of the sneakiest deliverability problems. It doesn't always produce a clear bounce. Your emails might just quietly go to spam with no explanation.
How to check your PTR record
Before trying to fix anything, check whether a PTR record exists and whether it's correct.
MXToolbox: Go to mxtoolbox.com/ReverseLookup.aspx and enter your mail server's IP address. It'll return the PTR record or flag if none exists.
Command line (Mac/Linux/Windows):
nslookup [your IP address]
Or on Mac/Linux:
dig -x [your IP address]
The output should show a PTR record pointing to your mail server's hostname. If it shows nothing, or points to something generic like a cloud provider's default hostname (ec2-203-0-113-25.compute-1.amazonaws.com), that's a problem worth fixing.
How to set up or fix a PTR record
Here's the critical detail most people get wrong: PTR records are controlled by whoever owns the IP address (your hosting or VPS provider, not your domain registrar).
You can't set a PTR record at Cloudflare or GoDaddy. You set it through DigitalOcean, Vultr, Hetzner, AWS, Linode, or wherever your mail server IP lives.
General process (self-hosted mail server):
- Log into your hosting provider's dashboard
- Find the networking or IP management section (look for "Reverse DNS" or "PTR records"; location varies by provider)
- Enter your mail server's hostname (e.g., mail.yourdomain.com) as the PTR value for your server's IP
- Save and allow time for DNS propagation (usually an hour, sometimes up to 48 hours)
- Verify using MXToolbox's reverse lookup tool
For your setup to pass FCrDNS, you also need to confirm your mail server's hostname has an A record that resolves back to the same IP. Both directions must work.
If you're on a dedicated IP through an ESP: SendGrid, Mailgun, and similar services have their own reverse DNS setup flows inside their dashboards. For SendGrid, it's under Settings > Sender Authentication > Reverse DNS. See SendGrid's reverse DNS guide for the full walkthrough. They generate the records and walk you through publishing them.
If you're on a shared IP through an ESP: The provider handles PTR records for shared IPs. You don't need to configure anything.
Keeping reverse DNS clean
Avoid generic cloud hostnames. A default PTR from a cloud provider signals "generic VPS instance" rather than "managed mail server." Receiving servers treat that as a yellow flag. Replace it with a custom hostname that matches your domain.
PTR is one layer, not the whole stack. A clean PTR helps establish basic sending legitimacy, but it works alongside DKIM, SPF, and DMARC, not instead of them. A perfect PTR with no DKIM still struggles. Get all three authentication layers in place first; then verify your PTR.
Re-check after any infrastructure changes. If you migrate to a new server, get a new IP, or switch hosting providers, your PTR record doesn't follow automatically. It needs to be reconfigured for the new IP. Easy to forget. Worth checking.
One PTR record per IP, pointing to your sending hostname. Your PTR record should resolve to the same hostname your SMTP server announces in SMTP conversations (the HELO/EHLO command). Mismatches look inconsistent to spam filters.
Related content
Related terms