Blacklist & Reputation Guides

The Role of Reverse DNS in Mail Server Trust

Learn how reverse DNS and PTR records affect mail server trust, why rDNS matters for email delivery, and how to fix missing or mismatched PTR records.

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

Introduction

Reverse DNS, also called rDNS or PTR lookup, maps an IP address back to a hostname. For mail servers, this is an important identity signal because receiving systems often check whether the sending IP has a valid reverse DNS record.

A missing, generic or mismatched PTR record can make a mail server look poorly configured. It may not block every email by itself, but it can contribute to spam filtering, rejection, delayed delivery or reputation problems when combined with weak SPF, DKIM, DMARC or poor sending behavior.

Quick answer

Quick answer

For mail server trust, the sending IP should have a PTR record that points to a proper mail hostname, such as mail.example.com. That hostname should also resolve forward to the same IP. This is often called forward-confirmed reverse DNS.

Reverse DNS

Reverse DNS is the opposite of normal DNS.

Normal DNS vs reverse DNS 
Normal DNS:
mail.example.com → 192.0.2.10

Reverse DNS:
192.0.2.10 → mail.example.com

The reverse DNS value is stored in a PTR record. For email, the PTR record helps receiving servers identify the hostname associated with the sending IP.

Reverse DNS is usually controlled by the IP owner or hosting/VPS provider, not by the normal domain DNS zone.

Why rDNS matters

Receiving mail servers use many signals to decide whether a message looks trustworthy. Reverse DNS is one of those signals.

  • The sending IP has a real hostname
  • The mail server is not an anonymous IP
  • The hostname looks intentional
  • The server identity matches mail configuration
  • The IP is not using a generic provider name
  • The mail server is configured professionally

rDNS alone does not guarantee inbox placement, but missing or bad rDNS can hurt deliverability.

Forward-confirmed rDNS

Forward-confirmed reverse DNS means the PTR hostname points back to the same sending IP.

Forward-confirmed rDNS example 
PTR:
192.0.2.10 → mail.example.com

A record:
mail.example.com → 192.0.2.10

This creates a consistent identity loop.

Many mail operators prefer this because it shows that the IP and hostname are intentionally connected.

PTR and HELO

A mail server introduces itself using a HELO or EHLO hostname during SMTP communication. This name should be consistent with the mail server identity.

Good setup

  • PTR record: mail.example.com
  • HELO/EHLO: mail.example.com
  • A record: mail.example.com points to sending IP
  • SPF includes the sending IP or provider
  • DKIM signs outgoing mail
  • DMARC aligns policy and reporting

Bad setup

  • PTR record missing
  • HELO says localhost
  • PTR points to generic provider hostname
  • Mail hostname does not resolve
  • SPF, DKIM and DMARC are missing

The values do not always need to be identical in every environment, but they should be consistent and explainable.

Who controls rDNS

Reverse DNS is controlled by whoever manages the IP address allocation.

  • Hosting provider
  • VPS provider
  • Dedicated server provider
  • Datacenter
  • ISP
  • Cloud provider
  • Email sending provider

Adding a PTR record in your normal DNS panel usually does not change reverse DNS. You normally need to request rDNS from the provider that owns the IP range.

Why this matters

Why this matters

Reverse DNS matters because mail servers are expected to identify themselves clearly. A server sending mail directly from an IP with no PTR record, generic rDNS or mismatched hostname can look like temporary, compromised or low-quality infrastructure.

This is especially important for VPS, dedicated servers, hosting providers and anyone running their own outbound SMTP server.

How to check rDNS

Use Reverse DNS Checker to check the PTR record for the actual sending IP address.

  1. Sending IP — find the IP that really sends the email.
  2. PTR record — confirm the IP has a reverse DNS hostname.
  3. Forward DNS — confirm the PTR hostname resolves back to the same IP.
  4. HELO/EHLO name — check whether the mail server identifies itself with a proper hostname.
  5. SPF — confirm the sending IP or provider is authorized.
  6. DKIM and DMARC — confirm messages are authenticated and aligned.
  7. Blacklist status — check whether the IP is listed on reputation databases.

Check reverse DNS for mail

Use Reverse DNS Checker to check the PTR record for the actual sending IP address.

Run Reverse DNS Check →

Common problems

Missing PTR record

High

The sending IP has no reverse DNS hostname.

Next step: Ask the IP owner or hosting provider to set a PTR record.

Generic provider rDNS

Medium

The PTR points to a generic provider hostname instead of your mail identity.

Next step: Set rDNS to a proper hostname such as mail.example.com.

PTR hostname does not resolve forward

High

The PTR hostname does not have an A record pointing back to the sending IP.

Next step: Add or fix the A record for the mail hostname.

HELO/EHLO mismatch

Medium

The mail server announces a hostname that does not match the expected mail identity.

Next step: Update mail server hostname or HELO configuration.

Multiple domains on one mail IP

Low

One IP may send for many domains, but it can only have one primary PTR hostname.

Next step: Use a neutral mail hostname and authenticate each domain with SPF, DKIM and DMARC.

Website IP checked instead of mail IP

Medium

The checked IP is not the actual outbound SMTP IP.

Next step: Find the real sending IP from headers, logs or bounce messages.

Provider refuses custom rDNS

Medium

Some shared or managed mail services do not allow custom PTR records.

Next step: Use the provider’s documented mail hostname and authentication setup.

Bad rDNS plus blacklist listing

High

Poor mail identity combined with a listing can strongly hurt delivery.

Next step: Fix rDNS and investigate the listing cause.

How to fix rDNS

  1. Step 1: Find the sending IP

    Use email headers, bounce logs, mail server logs or SMTP provider dashboard.

  2. Step 2: Choose a mail hostname

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

  3. Step 3: Create the forward DNS record

    Add an A record so the hostname points to the sending IP.

  4. Step 4: Request PTR/rDNS from the provider

    Ask the IP owner, VPS provider, datacenter or ISP to set the PTR record.

  5. Step 5: Align HELO/EHLO

    Configure the mail server to announce the same or a consistent hostname.

  6. Step 6: Verify forward-confirmed rDNS

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

  7. Step 7: Check SPF/DKIM/DMARC

    Make sure mail authentication supports the same sending infrastructure.

  8. Step 8: Re-test delivery

    Send test emails and review headers, bounces and reputation results.

Shared hosting

On shared hosting, many domains may send mail from the same IP address. That IP usually has one PTR record controlled by the hosting provider.

  • Your domain may not have custom PTR
  • The PTR may use the provider’s hostname
  • Reputation is shared with other users
  • SPF, DKIM and DMARC still need to be correct
  • High-volume sending should use dedicated mail infrastructure

For important business or transactional email, using a reputable dedicated email provider is often better than shared hosting SMTP.

VPS mail servers

If you run your own mail server on a VPS or dedicated server, reverse DNS is your responsibility together with the provider.

  • Hostname is not localhost
  • Hostname uses a real domain
  • A record points to the server IP
  • PTR points back to the hostname
  • HELO/EHLO matches the hostname
  • SPF includes the server IP
  • DKIM signing is enabled
  • DMARC policy exists
  • IP is not blacklisted

Without proper rDNS, self-hosted SMTP often struggles with delivery.

Examples

Reverse DNS examples 
Good setup:

Sending IP:
192.0.2.10

PTR:
192.0.2.10 → mail.example.com

A record:
mail.example.com → 192.0.2.10

HELO/EHLO:
mail.example.com

SPF:
v=spf1 ip4:192.0.2.10 -all

Check PTR:
dig -x 192.0.2.10

Check A record:
dig mail.example.com A

Bad setup:

PTR:
missing

or:

PTR:
192.0.2.10 → server123.provider.example

HELO:
localhost

Examples are illustrative. Replace IPs and hostnames with your real mail server values.

Frequently asked questions

Is reverse DNS required for email?

Many receiving servers expect it. Missing rDNS can hurt delivery or contribute to rejection.

Who sets the PTR record?

The IP owner or provider usually sets PTR/rDNS, not the normal domain DNS panel.

Should PTR match my domain?

It should point to a valid mail hostname that resolves back to the sending IP.

Can one IP have PTR for many domains?

Usually one IP has one primary PTR hostname. Multiple sending domains can still authenticate with SPF, DKIM and DMARC.

Is rDNS enough to fix deliverability?

No. It is only one signal. You also need SPF, DKIM, DMARC, clean sending and good reputation.

Why does my website IP rDNS not match email?

Your email may be sent from a different IP or provider than your website.

What should my mail server hostname be?

Use a real hostname such as mail.example.com or smtp.example.com, with forward DNS and PTR configured consistently.

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

Reverse DNS Checker Blacklist Checker MX Lookup SPF Checker DKIM Checker DMARC Checker Domain Health Checker
What Is a DNSBL and How Does It Work 8 min read Checking If Your IP or Domain Is on a Blacklist 8 min read Why Email Goes to Spam and How to Improve Deliverability 10 min read Understanding Domain Reputation and Sender Score 9 min read Google Workspace Email Authentication: SPF, DKIM and DMARC 8 min read
Browse all Blacklist & Reputation 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.