PTR Records and Reverse DNS: Why Your Mail Server Needs a Matching Hostname

When your mail server sends an email, the receiving server doesn't just evaluate your domain name — it looks at the IP address making the connection. Specifically, it performs a reverse DNS lookup to find out what hostname that IP maps to. If no PTR record exists, or if the hostname doesn't match what your server is presenting in the SMTP handshake, spam filters notice.

Most email senders spend time on SPF, DKIM, and DMARC and assume those three cover everything. PTR records tend to get overlooked until deliverability problems appear and someone starts digging. This guide explains what PTR records are, how they affect email delivery, and exactly how to configure them correctly.

What a PTR Record Is

A PTR record — short for pointer record — is a DNS entry that maps an IP address to a hostname. It's the reverse of an A record. While an A record maps mail.example.com to 192.0.2.1, a PTR record maps 192.0.2.1 back to mail.example.com.

PTR records live in a special part of the DNS namespace called the reverse DNS zone. For IPv4, this is the in-addr.arpa domain. For the IP address 192.0.2.1, the PTR record is published at 1.2.0.192.in-addr.arpa. IPv6 uses a similar reversed notation under ip6.arpa.

You can check a PTR record from the command line:

$ dig -x 192.0.2.1

;; ANSWER SECTION:
1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.

Why Receiving Mail Servers Check PTR Records

Receiving servers perform a reverse DNS lookup on the connecting IP as part of standard spam filtering. Two things happen with the result:

• Existence check: Does the IP have any PTR record at all? IPs with no reverse DNS are strongly associated with spammers using throwaway infrastructure. Many enterprise mail gateways reject or penalize connections from IPs with no PTR record.
• Forward-confirmed reverse DNS (FCrDNS): The receiving server takes the hostname from the PTR record and looks up its A record. If the A record resolves back to the same IP address, the check passes. If it doesn't match, the check fails.

This two-step verification — PTR to hostname, hostname back to IP — is called forward-confirmed reverse DNS. Failing it is a meaningful negative signal that appears in spam scoring systems at Google, Microsoft, and most enterprise gateways.

Who Controls PTR Records

PTR records are managed by whoever owns the IP address block — not by the domain owner. If you're sending from a VPS or dedicated server, your hosting provider owns the IP block and controls the PTR record.

• VPS or dedicated server: Log into your hosting provider's control panel. Look for "Reverse DNS," "PTR record," or "RDNS" in the network settings.
• Shared hosting: The PTR record typically shows the host's generic server name. Contact support to request a custom PTR record.
• Business internet connection: Your ISP owns the IP. Contact them directly to request a PTR record change.
• Managed SMTP relay: If you're using a relay service, they handle PTR records for the sending IPs. This is one of the key advantages of using infrastructure like MailDog's SMTP relay rather than running your own server.

What Your PTR Record Should Say

The hostname in your PTR record should match the EHLO/HELO hostname your mail server announces during the SMTP connection. These don't have to be the same as your From address domain, but they should be consistent and resolvable.

Good: mail.yourcompany.com — resolves forward and back correctly
Bad: dynamic-192-0-2-1.isp.example.com — looks residential
Bad: No PTR record at all — immediate red flag

IPv6 PTR Records

If your mail server has an IPv6 address and sends from it, you need a PTR record for IPv6 too. Many operators configure PTR records for IPv4 but forget the IPv6 address. Modern mail servers — including Gmail's infrastructure — often prefer IPv6 connections. If your IPv6 address has no PTR record, those connections will fail the reverse DNS check.

Diagnosing PTR Record Problems

If you're seeing unexplained deliverability issues, PTR configuration is worth checking early. Common problems:

• No PTR record: The IP has nothing in the reverse DNS zone.
• PTR hostname doesn't match EHLO: Your server announces one hostname in the SMTP handshake but reverse DNS says something different.
• Forward confirmation fails: The PTR hostname's A record doesn't point back to the sending IP.
• Generic hosting hostname: The PTR shows server42.hostprovider.com instead of a domain-tied hostname.
• IPv6 missing: IPv4 PTR is set correctly but IPv6 has no PTR record.

Use dig -x YOUR.IP for the IP, then dig A for the returned hostname to verify both directions. The MailDog documentation covers how to test your full sending configuration as part of a complete infrastructure check.

PTR Records in the Bigger Picture

A clean PTR record is one component of healthy sending infrastructure. Receiving servers evaluate PTR alongside SPF, DKIM, DMARC, and historical sender reputation. Getting PTR right doesn't override problems elsewhere, but getting it wrong adds a consistent penalty to every message you send.

Once it's configured, it doesn't need ongoing attention. Set your PTR record, verify the forward-confirmed check passes, make sure your EHLO hostname is consistent, and move on. For more on building reliable email infrastructure, see the MailDog mail service overview or explore sending plans if you'd rather leave the infrastructure details to someone else.