Reverse DNS: why your mail server needs a PTR record that matches

Your SPF record is clean, DKIM signs every message, DMARC is published. Then a bounce comes back reading something like 550 5.7.1 Client host rejected: cannot find your reverse hostname. Or nothing bounces at all and the mail quietly lands in spam at Gmail and Outlook.

That failure has nothing to do with the three records you spent an afternoon getting right. It lives in the opposite direction of DNS, on the IP you send from, and it is almost never set by the company that hosts your domain.

Forward DNS answers a different question

Normal DNS lookups go name to address. You ask for mail.example.com, you get back 203.0.113.25. That is an A record (or AAAA for IPv6).

Reverse DNS goes address to name. You ask about 203.0.113.25 and get back a hostname. The record type that carries the answer is a PTR record, short for pointer.

The reverse lookup is still an ordinary DNS query, just against a special naming tree. IPv4 addresses live under in-addr.arpa with the octets reversed, so 203.0.113.25 becomes a query for 25.113.0.203.in-addr.arpa. IPv6 uses ip6.arpa with each nibble reversed and dot-separated, which nobody types by hand. Those reverse zones are delegated like any other zone, from the regional internet registry down to whoever holds the address block.

That last detail is the one that trips people up, and it explains why your registrar cannot help you.

Why receiving mail servers care

When your server opens an SMTP connection, the receiver knows exactly one thing for certain: the IP address the packets came from. Everything else is a claim your server makes, starting with the hostname in the HELO/EHLO greeting.

A PTR record is the only piece of that exchange published by the party who controls the IP rather than by the sender. Receivers have treated it as a cheap signal of basic operational competence for twenty-plus years. RFC 1912 listed missing and mismatched PTR records as a common operational error in 1996.

Google's Email Sender Guidelines state the requirement plainly: the sending IP address must have a PTR record, and that record has to point to a hostname that resolves back to the sending IP. Microsoft applies the same expectation to inbound mail at Outlook and Hotmail. Plenty of smaller receivers running Postfix with reject_unknown_reverse_client_hostname enabled do not accept the connection at all.

Forward-confirmed reverse DNS, the part that fails silently

Having a PTR record is not enough. The receiver does a round trip, usually described as forward-confirmed reverse DNS, or FCrDNS:

1. Look up the PTR record for the connecting IP. Suppose it returns mail.example.com.
2. Look up the A or AAAA record for mail.example.com.
3. Confirm step 2 returns the original connecting IP.

If step 3 does not match, the check fails exactly as if no PTR existed. A PTR pointing at a hostname you retired last year, or at a name whose A record now points to your web host instead of your mail server, is worse than useless because it looks configured.

Two more alignment details matter on top of the round trip:

• The HELO name should match. Many receivers compare the hostname your server announces with the hostname in the PTR. When your PTR says srv-4412.hostingprovider.net and your server greets with mail.example.com, the two claims disagree, and that disagreement is a spam signal even when both names resolve.
• The hostname should look like a mail server. Default PTR records assigned by hosts follow patterns like 203-0-113-25.static.example-isp.net or ip25.dc3.compute.example.net. Those resolve fine and pass FCrDNS, and plenty of receivers still score them down, because that naming pattern is overwhelmingly associated with compromised hosts rather than intentional mail servers.
• IPv6 needs its own PTR. If your server has an AAAA record and the receiver also has IPv6, the connection goes over IPv6 and the IPv4 PTR is irrelevant. A mail server with perfect IPv4 reverse DNS and no ip6.arpa entry is a common and confusing failure: the same message reaches some receivers and gets rejected by others. Set both, or disable IPv6 outbound until you can.

Who sets a PTR record

Not your registrar. Not your authoritative DNS provider, unless they also happen to own the address block.

PTR records are published by whoever controls the IP address. In practice:

• Cloud and VPS providers expose a reverse DNS or PTR field in the console, per IP address. Most require that the forward A record already exist and point back at the IP before they accept the PTR value, which catches anyone configuring the reverse direction first.
• Dedicated server and colocation hosts often handle it through a support ticket. Ask for the PTR on a specific IP to be set to a specific hostname.
• Your ISP, for an on-premises gateway on a static business connection. Dynamic and residential ranges are a separate problem: many receivers reject them on principle, reverse DNS or not.

One PTR per IP address is the right answer. Multiple PTRs on one address are legal and return inconsistent round-trip results depending on which answer a resolver hands back first. Hosting mail for fifteen domains does not change that: the server needs one hostname, and every domain's MX can point at it.

The shared hosting and ESP case

If you send through Google Workspace, Microsoft 365, or a transactional provider, the sending IPs belong to them. Their reverse DNS is already configured correctly, and there is nothing for you to set or fix. A PTR for your own domain on someone else's shared IP is not a request that goes anywhere. Your levers in that setup are SPF, DKIM, and DMARC alignment, not reverse DNS.

Shared cPanel-style hosting sits in between. The server has a PTR pointing at the host's own hostname, which is fine as long as your mail server greets with the same name. The problem appears when the control panel sets HELO to your domain while the PTR still reads the host's generic name. Align the greeting to the existing PTR, or move to a dedicated IP where you can request a PTR you control.

Verify it in three checks

From a shell, two commands cover the round trip:

dig -x 203.0.113.25 +short
dig +short mail.example.com

The first should return a hostname. The second should return the IP you started with. Run the same pair for your IPv6 address if your server has one.

The third check is what receivers actually see. Send a message to an account you control somewhere else and read the Received header added by their server. A healthy one looks like Received: from mail.example.com (mail.example.com [203.0.113.25]). A broken one reads (unknown [203.0.113.25]) or shows a bare address in place of the first hostname, which tells you reverse DNS failed at the only moment it mattered.

One caveat on dig from your own machine: you are asking one resolver, and reverse delegations are frequently stale in ways forward records are not. The DNS lookup tool queries 20 global DNS resolvers and flags where answers disagree, which is the difference between a record that propagated and a record that propagated to you. To decode the authentication and Received chain of a real message without parsing headers by eye, paste them into the email header analyzer. The email check tool covers the records on the other side of the equation: SPF syntax, DKIM across 16 common DKIM selectors, DMARC policy, MX configuration, and your sending IPs against 77 verified active email blacklists.

Reverse DNS rarely breaks alone. A full scan at acuityscan.com runs 350+ checks across 8 modules, and the DNS and email modules together surface the mismatches that make a well-authenticated domain look untrustworthy anyway.

TL;DR

• A PTR record maps an IP address back to a hostname. It is published by whoever owns the IP block, which is your host, cloud provider, or ISP, never your registrar.
• Receivers run forward-confirmed reverse DNS: PTR gives a hostname, the hostname's A or AAAA record has to resolve back to the same IP. A stale PTR fails this while looking configured.
• Your HELO/EHLO name should match the PTR hostname, and that hostname should not look like a default ISP assignment.
• If your server sends over IPv6, it needs an ip6.arpa PTR too. IPv4-only reverse DNS explains a lot of inconsistent delivery.
• Sending through Google Workspace, Microsoft 365, or an ESP means reverse DNS is their job and is already handled. Spend the time on DMARC alignment instead.
• Verify with dig -x, confirm the round trip, then read the Received header on a message you sent yourself. (unknown [your.ip]) means it is still broken.