PTR Records and Reverse DNS: Why Outbound Mail Servers Need Them

A and AAAA records answer a question: given a hostname, what's the IP address? A PTR record answers the reverse: given an IP address, what's the hostname? That reversal isn't just a technical curiosity, it changes who controls the record, and it's the reason a perfectly good mail server can still get flagged as suspicious.

What a PTR record is

PTR stands for Pointer. It maps an IP address back to a hostname, the opposite direction of a normal DNS lookup:

42.113.0.203.in-addr.arpa.  PTR  mail.example.com.

That reversed, dotted structure (42.113.0.203.in-addr.arpa) is how reverse lookups are addressed for IPv4: the IP address is reversed octet by octet and appended to the special in-addr.arpa zone. IPv6 uses an analogous structure under ip6.arpa, reversing each nibble of the address instead.

Doing a reverse lookup from the command line hides that structure behind a friendlier interface:

dig -x 203.0.113.42

dig -x handles the reversal and zone suffix for you and returns whatever hostname is published for that IP.

The part that surprises people: you don't control it

Forward DNS records (A, MX, TXT, everything else this blog usually covers) live in your domain's zone, managed through your DNS provider. PTR records don't work that way. The reverse DNS zone for an IP address belongs to whoever owns that IP block, which is almost always your hosting provider or ISP, not you.

This means setting up a PTR record isn't a matter of adding it in your usual DNS dashboard. It has to be configured by whoever controls the IP address:

• Cloud providers (AWS, Google Cloud, DigitalOcean, and similar) typically offer a way to set the PTR record for an IP you're leasing from them, through their own console or support process, precisely because they're the ones who control that reverse zone.
• Traditional hosting and colocation usually requires a support request to the provider, since you don't have self-service access to their reverse zone.
• Residential and most shared IP ranges often can't have a custom PTR set at all, which is one of several reasons residential IPs and cheap shared hosting are poor choices for running your own outbound mail server.

If you switch cloud providers or change which server sends your mail, the PTR record for the new IP needs to be requested again, separately, from the new provider. Migrating your A and MX records doesn't touch it at all.

Why mail servers check this so aggressively

Reverse DNS became closely associated with email specifically because it's a cheap, effective signal against spam infrastructure. Legitimate mail senders almost always have a PTR record configured for the IP they send from, because it's a known best practice and most reputable mail platforms require it. Spam operations running from freshly spun-up cloud instances or compromised machines frequently don't, either because it's extra setup effort or because the IP is disposable and not worth configuring properly.

Many receiving mail servers check for two things specifically:

Does a PTR record exist at all for the sending IP? No reverse DNS is treated as a negative signal on its own, independent of anything else about the message.

Does the PTR hostname resolve back to the same IP, and does the hostname look plausible for a mail server? This is called forward-confirmed reverse DNS (FCrDNS): the sending IP's PTR record names a hostname, and that hostname's own A record needs to resolve back to the same IP. A PTR pointing to a hostname that doesn't loop back correctly, or one that looks generic and unrelated to the sending organization (a raw cloud-provider default like ec2-203-0-113-42.compute-1.amazonaws.com, rather than something like mail.example.com), is a weaker signal than a properly configured, matching pair.

Neither check is a hard requirement in a formal sense, in the way SPF and DMARC policies produce an explicit pass/fail. But a missing or mismatched PTR record is exactly the kind of ambient signal that pushes a borderline message toward the spam folder, alongside a missing SPF record or an unauthenticated DKIM signature. For the records that do have an explicit, checkable policy, see Why Your Email Goes to Spam.

Setting it up correctly

1. Identify the IP your mail server actually sends from. This is the IP the receiving server sees during the SMTP connection, which for many setups is the mail provider's IP, not necessarily your web server's.
2. Request a PTR record from whoever controls that IP (your cloud provider or ISP), pointing it at a hostname you control, typically something like mail.example.com.
3. Make sure that hostname has a matching forward A record, pointing back to the same IP, so the forward-confirmed check succeeds.
4. Verify both directions once it's set:

dig -x 203.0.113.42          # should return mail.example.com
dig A mail.example.com        # should return 203.0.113.42

If the two don't line up, either the PTR wasn't set correctly, the forward A record is missing, or the two point at different addresses entirely.

What this doesn't cover

PTR and FCrDNS checks are about the reputation of the IP a message was sent from. They say nothing about whether the message content is legitimate, whether the domain in the From: header is authorized to use that server (that's SPF), or whether the message was altered in transit (that's DKIM). A server can have a flawless PTR record and still send spam, and a message can have a missing PTR record and still be entirely legitimate mail from a small, self-hosted server that just hasn't set it up yet. It's one signal among several, not a standalone authentication mechanism.

How DNS monitoring fits in

Because PTR records live in infrastructure you don't directly control, they're easy to lose track of during a server migration: you move your mail sending to a new IP and remember to update your A, MX, and SPF records, but the new IP's PTR record is a separate request to a separate provider, and it's the kind of step that's easy to forget precisely because it isn't in your normal DNS dashboard.

OneDollarDNS focuses on monitoring the records you directly control in your own zone. If you're troubleshooting deliverability after a mail server migration, checking that reverse DNS was actually configured for the new sending IP is worth adding to that checklist alongside confirming your SPF, DKIM, and MX records reflect the move.