Why Reverse DNS Matters for Email Deliverability

Learn what reverse DNS is, why PTR records matter for mail servers, how forward-confirmed reverse DNS works, and how to fix common rDNS problems.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 7 min read Beginner

Introduction

Reverse DNS, also called rDNS, maps an IP address back to a hostname. For email servers, this is important because receiving mail systems often check whether the sending IP has a valid PTR record and whether the hostname looks consistent with the mail server identity.

A missing, generic or mismatched reverse DNS record can reduce trust, especially for dedicated mail servers, VPS mail servers and hosting platforms that send email directly. Reverse DNS does not replace SPF, DKIM or DMARC, but it is one of the basic identity signals receivers use when evaluating mail.

Quick answer

Quick answer

Reverse DNS is the PTR record that maps a sending IP address back to a hostname. For email, the sending IP should usually have a valid PTR record, the PTR hostname should resolve back to the same IP, and the mail server’s HELO/EHLO name should be consistent. rDNS is normally set by the IP or hosting provider.

Reverse DNS

Reverse DNS is the opposite of normal DNS lookup.

Normal DNS

hostname → IP address

Reverse DNS

IP address → hostname

Example 
mail.example.com → 192.0.2.10

Reverse DNS:
192.0.2.10 → mail.example.com

Reverse DNS is published as a PTR record. For most servers, PTR records are managed by the IP address provider, hosting provider or data center, not inside the domain’s normal DNS zone.

PTR records

A PTR record is the DNS record used for reverse DNS. It tells which hostname an IP address points back to.

Example 
IP:
192.0.2.10

PTR:
mail.example.com

A good mail-server PTR should usually be:

  • Present
  • Not generic
  • Related to the sending domain or server identity
  • Forward-confirmed
  • Consistent with HELO/EHLO where possible

A generic PTR like server123.hosting-provider.example is not always fatal, but a clean mail-specific hostname is usually better for dedicated sending infrastructure.

Forward-confirmed rDNS

Forward-confirmed reverse DNS, often called FCrDNS, means the PTR hostname also resolves forward back to the same IP address.

Example 
Reverse lookup:
192.0.2.10 → mail.example.com

Forward lookup:
mail.example.com → 192.0.2.10

This creates a consistent identity loop.

Many mail administrators expect sending mail servers to have forward-confirmed reverse DNS.

HELO and mail identity

When a mail server connects to another mail server, it announces itself using a HELO or EHLO hostname. Receivers may compare this hostname with reverse DNS and other signals.

A clean setup often looks like this:

Consistent mail identity 
Sending IP:
192.0.2.10

PTR:
mail.example.com

Forward DNS:
mail.example.com A 192.0.2.10

HELO/EHLO:
mail.example.com

These values do not always have to be identical in every setup, but obvious mismatches, generic names or missing PTR records can reduce trust.

Why this matters

Why this matters

Reverse DNS matters because it helps receiving mail servers identify the system connecting to them. If the sending IP has no PTR record, a generic PTR record, or a PTR hostname that does not resolve back to the IP, the server may look poorly configured.

rDNS alone does not guarantee inbox placement. It works together with SPF, DKIM, DMARC, IP reputation, domain reputation, content quality and recipient engagement.

How to check rDNS

Use Reverse DNS Checker to inspect the PTR record for the sending mail server IP.

When checking rDNS, review

These six checks help confirm mail server identity.

Sending IP

Identify the IP address that sends outbound mail.

PTR record

Check whether the IP resolves back to a hostname.

PTR hostname quality

Avoid missing, generic or unrelated hostnames where possible.

Forward confirmation

Check whether the PTR hostname resolves back to the same IP.

HELO/EHLO name

Confirm the mail server announces a consistent hostname.

SPF, DKIM and DMARC

Check authentication records after confirming server identity.

Check reverse DNS now

Use Reverse DNS Checker to verify the PTR record for your sending mail server IP.

Run Reverse DNS Check →

Common problems

No PTR record

High

The sending IP does not resolve back to any hostname.

Next step: Ask the IP, VPS, hosting or data center provider to set a PTR record.

Generic provider PTR

Medium

The IP resolves to a generic hostname instead of a mail-specific hostname.

Next step: Request a custom PTR such as mail.example.com if the IP is dedicated to your mail server.

PTR hostname does not resolve forward

High

The PTR hostname exists, but it does not point back to the sending IP.

Next step: Add or fix the A/AAAA record for the PTR hostname.

PTR points to wrong hostname

Medium

The IP points to an old domain, old server name or unrelated hostname.

Next step: Update PTR through the IP provider and align it with the active mail server identity.

HELO/EHLO mismatch

Medium

The mail server announces a hostname that differs from its expected mail identity.

Next step: Set the mail server hostname to a valid FQDN that resolves correctly.

Shared hosting IP has poor identity

Medium

Many domains share one sending IP, so rDNS may belong to the hosting provider.

Next step: Use the provider’s mail service correctly or consider dedicated sending infrastructure if needed.

PTR changed but mail still fails

Low

rDNS is only one signal. SPF, DKIM, DMARC or reputation may still be problematic.

Next step: Check full email authentication and reputation signals.

How to fix rDNS

  1. Step 1: Find the sending IP

    Identify the IP address your mail server uses for outbound email. This may be different from the website IP.

  2. Step 2: Choose a mail hostname

    Use a hostname such as mail.example.com or smtp.example.com.

  3. Step 3: Create forward DNS

    Add an A or AAAA record so the hostname resolves to the sending IP.

  4. Step 4: Request PTR update

    Ask the IP provider, VPS provider, hosting company or data center to set the PTR record for the IP.

  5. Step 5: Align server hostname

    Configure the mail server HELO/EHLO hostname to use a valid FQDN where possible.

  6. Step 6: Verify FCrDNS

    Check that IP → hostname and hostname → IP both work.

  7. Step 7: Review SPF, DKIM and DMARC

    After rDNS is correct, verify full email authentication.

rDNS examples

Good mail identity 
Sending IP:
192.0.2.10

PTR:
192.0.2.10 → mail.example.com

Forward DNS:
mail.example.com → 192.0.2.10

HELO/EHLO:
mail.example.com
Problem example 
Sending IP:
192.0.2.10

PTR:
No PTR record found

Possible fix:
Ask the IP provider to set PTR to mail.example.com, then make sure mail.example.com points back to 192.0.2.10.
Command examples 
dig -x 192.0.2.10
host 192.0.2.10
dig mail.example.com A
dig mail.example.com AAAA

These examples are illustrative. Replace hostnames and IP addresses with your real mail server values.

Who controls rDNS?

Reverse DNS is usually controlled by the organization that owns or delegates the IP address block.

This may be:

  • VPS provider
  • Dedicated server provider
  • Hosting company
  • Data center
  • ISP
  • Cloud provider

You usually cannot fix PTR records only by editing your normal DNS zone. You must set or request PTR at the IP provider.

Shared hosting

On shared hosting, many users may send email from the same server IP. In that case, the PTR record often belongs to the hosting provider, not each hosted domain.

This is normal for shared mail infrastructure, but it means:

  • You may not control PTR directly
  • IP reputation is shared
  • Provider mail policies matter
  • SPF/DKIM/DMARC still need correct setup
  • High-volume sending may need dedicated email infrastructure

If email deliverability is critical, use a properly configured mail provider or dedicated sending platform.

Frequently asked questions

What is reverse DNS?

Reverse DNS maps an IP address back to a hostname using a PTR record.

Why does reverse DNS matter for email?

Receiving mail servers often check whether the sending IP has a valid PTR record and consistent mail server identity.

Who can change reverse DNS?

Usually the IP address provider, VPS provider, hosting company, data center or ISP controls PTR records.

Should PTR match my domain?

For dedicated mail servers, the PTR should usually be a valid mail hostname related to your sending identity and should resolve back to the IP.

Does rDNS replace SPF, DKIM or DMARC?

No. rDNS is a server identity signal. SPF, DKIM and DMARC are email authentication mechanisms.

Can bad rDNS cause email delivery problems?

Yes, missing or inconsistent rDNS can reduce trust or trigger stricter filtering, especially for direct mail servers.

Can I set rDNS in cPanel or normal DNS?

Usually no. You normally need to set PTR with the IP provider, although some hosting panels may expose a request or configuration option.

Use these free tools to verify your configuration after applying changes.

Reverse DNS Checker SPF Checker DKIM Checker DMARC Checker MX Lookup Domain Health Checker
Why Reverse DNS is Important for VPS Mail Servers 7 min read SPF Basics: Defining Authorized Senders 7 min read DKIM Signatures: How They Work and Why They Matter 8 min read DMARC for Beginners: Policies, Alignment and Enforcement 8 min read Best Practices for MX Records and Mail Routing 8 min read
Browse all Email Authentication guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.