PTR Records and Reverse DNS: Why They Matter for Email Deliverability
When people talk about email authentication, the conversation almost always lands on SPF, DKIM, and DMARC. Those three do a lot of heavy lifting — but there's a fourth check that happens before any of them: reverse DNS. Specifically, receiving mail servers look up the PTR record for your sending IP, and what they find (or don't find) influences whether your email gets delivered, deferred, or quietly dropped.
If you're running your own SMTP infrastructure or managing a dedicated sending IP, getting your PTR record right isn't optional. It's foundational.
What Is a PTR Record?
A PTR record — short for pointer record — maps an IP address back to a hostname. It's the reverse of what an A record does. Where an A record says "this hostname points to this IP," a PTR record says "this IP belongs to this hostname."
PTR records live in a special part of DNS called the in-addr.arpa zone. For an IP like 198.51.100.42, the PTR lookup happens at 42.100.51.198.in-addr.arpa. The result is a fully qualified domain name — something like mail.yourdomain.com.
This lookup is called reverse DNS or rDNS, and mail servers perform it automatically when they receive an incoming connection from your IP.
Why Receiving Servers Care About PTR Records
Most spam originates from IP addresses with no PTR record, or with a PTR record that looks auto-generated — something like 198-51-100-42.dynamic.isp.net. Spammers use hacked machines, residential connections, and throwaway cloud instances. Those sources almost never have a clean, properly configured reverse DNS entry.
Legitimate mail servers, on the other hand, are typically hosted on business infrastructure where the owner has deliberately configured rDNS to match their sending domain. This correlation isn't perfect, but it's consistent enough that receiving MTAs and spam filters treat it as a meaningful signal.
When a mail server connects to deliver email, the receiving server grabs the connecting IP and performs a PTR lookup. Then it usually does a forward-confirmed reverse DNS check: it takes the hostname returned by the PTR lookup and runs an A record lookup on it. If the A record points back to the original IP, that's called FCrDNS — Forward Confirmed Reverse DNS. This two-way match is what most filters are actually checking for.
What Happens Without a PTR Record
The consequences vary by receiving server, but they're rarely good:
- Soft rejections and deferrals — many servers will temporarily reject connections from IPs with no PTR record, forcing your mail queue to retry.
- Higher spam scores — filters like SpamAssassin add points for missing or mismatched PTR records, which can push otherwise clean email over the threshold.
- Outright rejection — some conservative configurations (common in enterprise environments) reject connections with no valid rDNS entirely.
- Microsoft and Outlook issues — Microsoft in particular is well known for blocking email from IPs without proper PTR records. If your Outlook deliverability is suffering, rDNS is one of the first things to check.
How to Set Up a PTR Record
Here's where PTR records differ from every other DNS record you've worked with: you don't set them in your domain's DNS zone. PTR records are controlled by whoever owns the IP address, which is your hosting provider or ISP — not you.
The process depends on where your sending IP comes from:
Dedicated IPs from a Mail Provider
If you're sending through a platform like MailDog's SMTP relay on a dedicated IP, ask your provider to configure the PTR record. Most reputable providers handle this, but you often need to request it explicitly and tell them what hostname to point to.
VPS or Cloud Hosting
On providers like DigitalOcean, Linode, or Vultr, you can typically set a reverse DNS entry through the control panel — it's usually in the "networking" section for your droplet or instance. The hostname you set there becomes the PTR record. Some providers call it "rDNS," others call it "RDNS hostname" or "reverse hostname."
Dedicated Servers
With bare-metal servers, contact your data center or provider's support team. You'll give them the IP and the hostname you want the PTR record to point to, and they'll configure it on their end.
What Hostname Should Your PTR Record Point To?
This is where people make mistakes. The PTR record should point to a hostname that:
- Resolves back to your sending IP via an A record (the FCrDNS requirement)
- Looks like a legitimate mail server hostname, not a generic or auto-generated one
- Is part of your sending domain or a related domain — not a random hostname
A common convention is something like mail.yourdomain.com or smtp.yourdomain.com. If you're sending from yourcompany.com, then mail.yourcompany.com pointing to your sending IP — and your sending IP having a PTR record pointing back to mail.yourcompany.com — is the clean setup most filters expect.
Avoid using hostnames that include the IP address in a pattern that looks auto-generated. Something like 198-51-100-42.mail.yourhost.com technically works but raises the same flags as a dynamic IP.
Verifying Your PTR Record
Once you've configured rDNS, verify it before sending. The simplest check from a Linux or macOS terminal:
dig -x 198.51.100.42Replace the IP with your actual sending IP. The ANSWER SECTION should return your configured hostname. Then confirm the forward lookup:
dig mail.yourdomain.com AThe result should include your sending IP. If both checks pass, your FCrDNS is correctly configured.
You can also use online tools like MXToolbox's reverse DNS lookup, or check rDNS as part of a broader deliverability review via MailDog's DNS security tools.
PTR Records and Your HELO/EHLO Hostname
There's one more piece worth knowing. When your mail server connects to a receiving server, it announces itself with a HELO or EHLO command followed by a hostname. Best practice is for this hostname to match your PTR record. If your PTR points to mail.yourcompany.com and your server announces itself as something else entirely, that inconsistency can trigger additional suspicion from filters.
Keep these three things aligned: your PTR record, the hostname in your EHLO, and the A record for that hostname. Consistent configuration signals a legitimate, professionally managed mail server.
A Note on Shared IPs
If you're sending from a shared SMTP relay, the PTR record for the shared IP is managed by the provider and you have no control over it. This is one reason dedicated IPs — where you control the rDNS — are preferred for high-volume or reputation-sensitive sending. For more on that tradeoff, see our guide on choosing between dedicated and shared IP infrastructure.
The Bottom Line
PTR records don't get the attention that SPF and DKIM do, but missing or misconfigured rDNS is one of the most common and most easily fixed deliverability problems. If your email is being deferred or rejected — especially by Microsoft or enterprise mail systems — check your PTR record first. It takes ten minutes to configure and can have an immediate impact on your inbox placement.
For a complete picture of your sending setup and DNS configuration, MailDog's documentation covers the full authentication stack, or you can reach out if you need help diagnosing a specific deliverability issue.
