Reverse DNS (PTR Records) and Email Deliverability

Why a mismatched or missing PTR record can quietly sink an otherwise well-configured mail server's reputation.

Core Concept

A PTR record maps an IP address back to a hostname, the reverse of a standard DNS lookup, and is used by receiving mail servers as part of sender legitimacy checks.

Many mail servers check whether a sending IP's PTR record resolves to a hostname that, in turn, resolves back to the same IP — a pattern called forward-confirmed reverse DNS.

Insight: Reverse DNS checks are a foundational, decades-old spam filtering heuristic that remains widely used precisely because legitimate mail infrastructure reliably has it configured correctly.

Why Receiving Servers Check PTR Records

A consistent, properly configured PTR record is a strong signal of legitimate, professionally managed mail infrastructure.

Spam and botnet-originated mail frequently lacks proper reverse DNS
Legitimate mail providers reliably configure PTR records correctly
It's a lightweight, low-cost check performed before deeper content analysis

Cheap Early Filter

Because a PTR lookup is fast and simple, many receiving servers use it as an early, low-cost filter before investing in more expensive content analysis.

What a Missing or Mismatched PTR Causes

Sending mail from an IP without a proper PTR record is a significant deliverability risk.

Increased spam scoring even for otherwise legitimate content
Outright rejection by some strict receiving mail servers
Damaged sender reputation compounding over repeated failures

Limitation: Some mail servers reject connections outright from IPs with no PTR record at all, regardless of any other authentication the message might pass.

Setting Up Proper Reverse DNS

Configuring PTR records correctly typically requires coordination with the IP address's actual owner.

Unlike forward DNS, which the domain owner controls directly, PTR records are managed by whoever controls the IP address block — often a hosting provider or ISP.

IP Owner Controls PTR

Setting up a PTR record usually requires a request to the hosting provider or ISP that owns the IP, not the domain's own DNS management.

Best Practices for Mail Server Reverse DNS

A properly configured mail server should meet a few specific criteria.

PTR record resolving to a hostname matching the mail server's purpose
That hostname's forward A record resolving back to the same IP
Consistency maintained across any IP or infrastructure changes

Insight: Verifying forward-confirmed reverse DNS — that the PTR hostname resolves back to the original IP — is worth checking explicitly, not just confirming a PTR record exists at all.

Real-World Implementation

Reverse DNS configuration is a standard, often overlooked, step in mail server setup.

Hosting providers offering PTR record configuration for dedicated IPs
Deliverability audits routinely checking reverse DNS as an early step
Email service providers pre-configuring PTR records for their shared sending IPs

Given how foundational this check is to spam filtering, verifying proper reverse DNS configuration belongs near the top of any mail server deliverability checklist.

Common Mistakes to Avoid

A few common mistakes affect reverse DNS configuration for mail servers.

Sending mail from an IP with no PTR record configured at all.
Assuming domain-controlled forward DNS also controls the reverse PTR record.
Overlooking forward-confirmed reverse DNS verification, checking only that a PTR exists.
Failing to update PTR records after migrating mail server infrastructure.
Not requesting PTR configuration promptly from the hosting provider or ISP.
Overlooking that some hosting providers require a support ticket to set up PTR records.
Assuming a generic, unrelated PTR hostname is as effective as a properly matched one.
Failing to update the PTR record when migrating to a new mail server IP.
Overlooking that some mail servers check PTR hostname content, not just its existence.
Assuming PTR configuration is a one-time setup with no need for revisiting.
Failing to verify PTR records specifically after switching hosting or cloud providers.
Overlooking that some cloud platforms require verifying domain ownership before enabling custom PTR records.

Best Practices Checklist

These practices help ensure reverse DNS supports reliable mail deliverability.

Request proper PTR record configuration from the IP owner before sending production mail.
Verify forward-confirmed reverse DNS, not just that a PTR record exists.
Update PTR records promptly after any mail server infrastructure migration.
Include reverse DNS verification early in any mail server deliverability checklist.
Coordinate with hosting providers proactively, since they control PTR configuration, not the domain owner.
Confirm your hosting provider's specific process for requesting PTR record configuration.
Set a PTR hostname that clearly matches the mail server's actual purpose.
Update the PTR record promptly whenever migrating to a new mail server IP.
Choose PTR hostname content deliberately, since some receiving servers evaluate it beyond mere presence.
Revisit PTR configuration periodically as part of ongoing mail infrastructure maintenance.
Verify PTR records explicitly after any hosting or cloud provider migration.
Complete any required domain ownership verification before requesting a custom PTR record from a cloud platform.

Frequently Asked Questions

Frequently asked questions about reverse DNS and email deliverability.

What is a PTR record?

It maps an IP address back to a hostname, the reverse of a standard DNS lookup, used by receiving mail servers as part of sender legitimacy checks.

Who controls a mail server's PTR record?

Whoever controls the IP address block — typically a hosting provider or ISP — not the domain owner directly, unlike forward DNS.

What is forward-confirmed reverse DNS?

It's when a PTR hostname resolves back to the same IP as its own forward A record, a pattern many mail servers check for legitimacy.

What happens if a mail server has no PTR record?

Some receiving mail servers reject connections outright from IPs with no PTR record, regardless of any other authentication the message passes.

Why do receiving servers bother checking PTR records?

It's a fast, low-cost early filter, since legitimate mail providers reliably configure PTR records correctly while spam sources often don't.

Do all hosting providers let customers self-configure PTR records?

Not always — some require a support request, since PTR records are managed by the IP block's owner rather than the domain owner directly.

Does the actual PTR hostname content matter, or just its presence?

Content matters — a hostname that clearly relates to the mail server's purpose is viewed more favorably than a generic or unrelated one.

What happens if a PTR record isn't updated after a mail server IP migration?

The old PTR configuration becomes irrelevant to the new IP, effectively leaving the new server without proper reverse DNS until it's updated.

Do receiving mail servers evaluate PTR hostname content, not just presence?

Some do — a generic or suspicious-looking hostname can be treated differently than one clearly reflecting the mail server's actual purpose.

Should PTR configuration be revisited after a cloud migration?

Yes — IP changes during migration require corresponding PTR updates, which can easily be overlooked amid other migration tasks.

Do cloud platforms require verification before setting a custom PTR record?

Many do require proof of domain ownership first, which is a prerequisite step worth completing before requesting PTR configuration.

Check Reverse DNS Configuration

Run an email security scan to check reverse DNS alignment for a mail server.

Launch Tool →