PTR Records and Reverse DNS: Why Your Sending IP Needs a Name

When an email lands in a receiving server's queue, one of the first checks it runs is a reverse DNS lookup. The server takes your sending IP address, queries the DNS system, and asks: does this IP resolve to a hostname? And does that hostname point back to the same IP? If the answer is no — or if there's no PTR record at all — your message may be silently rejected, rate-limited, or routed directly to spam before a single content filter even looks at it.

PTR records are one of those infrastructure details that experienced email operators take for granted. But for anyone building out a sending setup for the first time, they're easy to overlook, and the consequences usually show up as mysterious delivery failures that don't generate useful bounce messages.

What Is a PTR Record?

A PTR record — short for "pointer record" — is a DNS record that maps an IP address to a hostname. It's the reverse of an A record, which maps a hostname to an IP. PTR records live in a special part of DNS called the in-addr.arpa zone (for IPv4) or the ip6.arpa zone (for IPv6).

For example, if your sending IP is 198.51.100.42, the corresponding PTR record would be stored at 42.100.51.198.in-addr.arpa and would point to a hostname like mail.yourdomain.com.

Unlike most DNS records, you can't set PTR records yourself unless you control the IP block. PTR records are configured by whoever owns the IP address — typically your hosting provider, your ISP, or your email infrastructure provider.

Why Receiving Servers Care About Reverse DNS

Receiving mail servers perform a check called a forward-confirmed reverse DNS (FCrDNS) lookup. The logic is straightforward:

1. Look up the PTR record for the sending IP. Get a hostname.
2. Look up the A record for that hostname. Get an IP.
3. Check that the IP matches the original sending IP.

If the chain breaks anywhere — no PTR exists, the PTR points to something generic, or the A record doesn't resolve back — the receiving server flags the connection as suspicious. Many servers won't reject outright, but they'll assign a higher spam score or throttle delivery significantly.

Some providers are stricter than others. Microsoft's mail infrastructure, which handles Outlook and Hotmail accounts, is known to reject connections from IPs with missing or generic PTR records. If you're troubleshooting deliverability problems with Microsoft, checking your PTR record is one of the first things to do.

What Makes a Good PTR Record?

A good PTR record has a few qualities:

• It resolves to a meaningful hostname. Something like mail.yourdomain.com or smtp.yourcompany.io is ideal. Generic hostnames like static.198.51.100.42.example-host.com raise flags because they suggest a default VPS configuration rather than a dedicated mail server.
• It matches the HELO/EHLO hostname. When your mail server connects to a receiving server, it announces itself with a HELO or EHLO command. That hostname should match or be consistent with what the PTR record returns.
• The forward lookup confirms the IP. The hostname your PTR points to must have an A record pointing back to the sending IP. Mismatches break the FCrDNS check.

How to Check Your PTR Record

You can verify your reverse DNS from the command line:

dig -x 198.51.100.42

Or with nslookup:

nslookup 198.51.100.42

Online tools also work well — search for "reverse DNS lookup" and enter your sending IP. If you see a meaningful hostname and the forward lookup matches your IP, you're in good shape. If you see NXDOMAIN or a generic hostname, it's time to contact your provider.

How to Set Up a PTR Record

Because PTR records are controlled by the IP owner, the process depends on your infrastructure:

• Using a managed SMTP relay: Your relay provider handles PTR records automatically. When you use a service like MailDog's SMTP relay, the infrastructure is already configured with proper reverse DNS for sending IPs. You don't need to do anything manually.
• Using a VPS or dedicated server: Log into your hosting control panel and look for a "Reverse DNS" or "PTR Record" setting. Most major cloud providers allow you to set a custom PTR record per IP. Set it to the fully qualified domain name of your mail server.
• Using a dedicated IP from your provider: Contact your provider's support team and request a PTR record be set for your IP. Give them the hostname you want it to resolve to. The change may take a few hours to propagate.

PTR Records and Spam Filtering

Most modern spam filtering systems use PTR records as one signal among many. A missing PTR record alone won't necessarily cause all your email to be rejected — but it lowers your overall trust score. When combined with other issues like weak SPF, high complaint rates, or sending from a new IP, the absence of a proper PTR record can push messages over the threshold into spam.

Think of it this way: receiving filters are looking for reasons to trust you. PTR records are one of the cheapest trust signals to get right. There's no good reason to leave them misconfigured.

PTR Records and Outbound Campaigns

If you're running outbound campaigns from dedicated infrastructure, PTR records are especially important. Prospect mailboxes at large companies often run strict inbound filtering, and a missing or generic PTR record is an immediate strike against your reputation before your content is ever evaluated.

Getting this right before you send your first message is far easier than trying to recover a damaged sending reputation later. Pair a proper PTR record with correct SPF, DKIM, and DMARC records and you'll have the authentication foundation that protects your deliverability long-term. If you're not sure where to start, the MailDog documentation covers the full DNS configuration process step by step.

Common PTR Record Mistakes

• Forgetting to set one at all. This is the most common mistake, especially when spinning up a new server for the first time.
• Setting the PTR to a hostname that doesn't exist in DNS. The forward lookup will fail the FCrDNS check.
• Using a hostname from a different domain than your From address. Technically valid but looks inconsistent to spam filters.
• Setting the PTR and then changing the A record without updating the PTR. If you rename your server or update your IP, check that the PTR record and forward lookup still match.

PTR records are easy to configure correctly once and then forget about. But forgetting to set them up in the first place is a recurring cause of deliverability headaches that can take time to diagnose. If your email infrastructure is properly configured, you should be able to verify your PTR record in under a minute. If you can't, that's the first thing to fix before any other deliverability work.

For a complete view of how DNS configuration affects your email setup, visit the MailDog blog or explore the frequently asked questions on the MailDog website.