Why Your Sending IP Needs a Reverse DNS Record (And How to Set One Up)

What a PTR Record Actually Does

Every IP address on the internet can be assigned a reverse DNS record—called a PTR record—that maps the IP back to a hostname. Forward DNS resolves mail.yourdomain.com → 203.0.113.42. Reverse DNS resolves 203.0.113.42 → mail.yourdomain.com.

For general web traffic this doesn't matter much. For email, it matters enormously. Receiving mail servers perform a reverse DNS lookup on the IP that connected to them, and if that lookup fails—or worse, returns a generic hostname like ec2-203-0-113-42.compute-1.amazonaws.com—many providers will defer, filter, or outright reject the message.

Why Mailbox Providers Check PTR Records

PTR records are a basic identity signal. Legitimate mail infrastructure typically has properly configured reverse DNS that matches the sending hostname. Spammers running on compromised machines or generic cloud VMs often don't bother—or can't—set PTR records because they don't control the IP's reverse DNS zone.

Microsoft's servers (outlook.com, hotmail.com, Exchange Online) are particularly strict about this. Their rejection message is unambiguous:

550 5.7.25 The IP address sending this message does not have a PTR record

Getting this error means your messages to Outlook and Hotmail users will fail delivery entirely until the PTR record is configured. It's one of the most concrete, fixable causes of delivery failures that people miss.

The Forward-Confirmed Reverse DNS Check

A PTR record alone isn't enough—it needs to forward-confirm. This means:

1. The IP reverse-resolves to a hostname: 203.0.113.42 → mail.yourdomain.com
2. That hostname forward-resolves back to the same IP: mail.yourdomain.com → 203.0.113.42

This is called FCrDNS (Forward-Confirmed Reverse DNS). If the two don't match—because your PTR points to a hostname that doesn't have a matching A record, or points to a different IP—some providers treat it as worse than having no PTR at all. Always verify both directions after configuring a PTR record.

Who Controls Reverse DNS

Here's where many people get stuck: the owner of the IP address controls its reverse DNS, not the owner of the domain.

If you're on a VPS or dedicated server, your hosting provider (DigitalOcean, Linode, Vultr, Hetzner, etc.) manages the reverse DNS zone for their IP blocks. You configure the PTR record through your hosting provider's control panel or API—not through your domain registrar's DNS settings. Look for a setting called "Reverse DNS," "PTR record," or "RDNS" in your server or IP management panel.

If you're using a managed SMTP relay, the relay provider controls the sending IPs and their PTR records. Reputable relays configure PTR records on their IPs by default. If you have a dedicated IP through a relay, confirm with the provider that the PTR is set—or request that it be configured to match your sending hostname.

What the PTR Record Should Point To

The PTR record hostname should match what appears in your SMTP EHLO/HELO banner—the hostname your mail server announces when it connects to a receiving server. Mismatches between the PTR and the EHLO hostname are another signal that filtering algorithms notice.

A clean setup looks like this:

• Sending IP: 203.0.113.42
• PTR record: 203.0.113.42 → mail.yourdomain.com
• A record: mail.yourdomain.com → 203.0.113.42
• SMTP EHLO banner: EHLO mail.yourdomain.com

Everything points to the same hostname. Any inconsistency here is worth investigating.

How to Verify Your PTR Record

Check PTR resolution from the command line:

# Replace with your actual sending IP
dig -x 203.0.113.42 +short

Then verify forward confirmation:

dig mail.yourdomain.com A +short

Both queries should return consistent results. If dig -x returns nothing, the PTR record is missing. If it returns a hostname that dig A doesn't resolve back to the original IP, the forward confirmation is broken.

You can also test using online tools that check all email-relevant DNS records at once—the MailDog DNS checker covers PTR validation alongside SPF, DKIM, and DMARC.

IPv6 and Reverse DNS

If your mail server sends over IPv6, it needs a PTR record on the IPv6 address as well. IPv6 reverse DNS zones use the .ip6.arpa format, and the lookup syntax is reversed just like IPv4 (but 128 bits instead of 32). Many deployments configure IPv4 PTR correctly and forget IPv6—then wonder why some providers defer their mail. If you use IPv6 for sending, verify the PTR exists for the IPv6 address independently.

PTR in Context: One Piece of the Authentication Picture

A valid PTR record is a prerequisite, not a guarantee. It's checked alongside SPF, DKIM, DMARC, and sender reputation. Think of it as the baseline credential that gets your connection taken seriously—without it, the other authentication signals don't get a fair hearing.

For the full authentication setup that PTR record belongs in, see the guide to why emails land in spam. If you're warming a new dedicated IP, the IP warming guide covers the pre-send checklist that includes PTR verification. Questions about how MailDog handles reverse DNS on dedicated IPs can be directed to the support team.