Your SPF passes. Your DKIM signature verifies. Your DMARC policy is published and aligned. And your mail still lands in Junk at one large provider, consistently, for months.
One of the most common reasons is a setting that is not in your DNS zone at all, that most people never configure, and that your hosting provider controls: the reverse DNS record for the address you send from.
Reverse DNS runs in the opposite direction
Ordinary DNS turns a name into an address. Reverse DNS turns an address back into a name, using a special zone. The address 203.0.113.10 becomes the name 10.113.0.203.in-addr.arpa, and a PTR record at that name gives the host name:
dig -x 203.0.113.10 +short mail.example.com.
The crucial detail is ownership. Your registrar delegates example.com to you, so you control everything under it. The in-addr.arpa tree is delegated by the regional internet registry to whoever holds the address block — your hosting provider, your cloud vendor, or your ISP. You cannot publish a PTR record for an address you do not own, no matter what you put in your own zone.
This is why reverse DNS is so often missing. It is the one piece of mail configuration that requires someone else to act.
Forward-confirmed reverse DNS
Receivers do not simply read the PTR and believe it. They perform a round trip, usually called FCrDNS — forward-confirmed reverse DNS:
- Take the connecting address,
203.0.113.10. - Look up its PTR record:
mail.example.com. - Look up the A record of that name:
203.0.113.10. - Check that it matches the address they started with.
If all three steps agree, the connection is forward-confirmed. If the PTR points to a name that resolves somewhere else — or nowhere — the check fails, and the fact that a PTR technically exists does not help you.
What a bad PTR looks like
A PTR can also exist and still count against you, because the shape of the name is itself a signal. Default names assigned automatically by hosting providers tend to look like this:
10-113-0-203.static.example-hosting.net vps-371394b8.vps.provider.com host203-113-0-10.dynamic.isp.example
Filters treat names of this form as generic address space: machines that are not intended to send mail directly. A mail server on such an address is either misconfigured or compromised, most of the time, and receivers price that accordingly. A name that clearly identifies a mail host on your own domain — mail.example.com, smtp.example.com — sends the opposite signal.
The HELO name should match too
When your server opens an SMTP session it introduces itself:
EHLO mail.example.com
Receivers compare that name with the reverse DNS of the connecting address. Three-way agreement — HELO name, PTR record, and forward A record all matching — is the configuration that receiving systems trust most. A server that introduces itself as localhost, or as a name that resolves elsewhere, is treated with suspicion even when its authentication is perfect.
What breaks without it
Missing or mismatched reverse DNS degrades delivery in ways that never produce a clear error.
Some receivers reject outright at connection time, with a message that is at least explicit:
550 5.7.25 [203.0.113.10] The IP address sending this message does not
have a PTR record set up
Others accept the message but apply a penalty that pushes it into the junk folder — no bounce, no log entry on your side, nothing to investigate. Greylisting systems delay you longer. Volume limits are applied more tightly. And because the penalty is statistical rather than absolute, mail to one recipient arrives normally while mail to another disappears, which sends most people looking in entirely the wrong place.
The cruellest part is that authentication cannot compensate for it. You can have a perfect SPF, DKIM and DMARC setup and still be filtered, because reverse DNS is evaluated before your message is even offered.
How to check it in 30 seconds
You need the address your mail actually leaves on, which is not necessarily your MX. Take a message you sent to an external address, open its source, and read the last Received: header added by your own infrastructure — that is your outbound address.
Then run a reverse DNS lookup on it. The result shows the PTR record, resolves that name forward again, and tells you whether the round trip is confirmed. For a fuller picture, SMTP Diagnostics connects to a mail server and reports the banner and HELO name alongside the reverse DNS, so you can see all three values together.
Fix it
The change itself is small; getting it made is the work. Most providers expose a "reverse DNS" or "PTR" field in their control panel for each address. If yours does not, open a ticket.
- Pick a name on a domain you control that describes the host:
mail.example.com, not a generic provider name. - Create the forward record first: an A record for that name pointing at the address.
- Ask your provider to set the PTR for the address to exactly that name, including the trailing dot in their form if required.
- Set your mail server's HELO/EHLO name to the same value.
- Verify the round trip:
dig -x 203.0.113.10 +short, then resolve the name you get back and confirm it returns the same address. - Repeat for every outbound address, including IPv6 — receivers check IPv6 reverse DNS just as strictly, and a missing PTR there is a frequent cause of "it only fails sometimes".
- If you send through a provider such as Google Workspace or Microsoft 365, you do not need to do any of this: their addresses already have correct reverse DNS.
Then keep it that way
Reverse DNS breaks silently when servers are renamed, addresses are reassigned, or a provider rebuilds a host and restores its default name.
StatusDNS checks reverse DNS as part of every monitored domain's scheduled run. The mail server check resolves each MX host, looks up the PTR for its addresses and confirms the forward record matches, and raises a warning when a PTR is missing or no longer forward-confirmed. Those findings are recorded in your domain's history and, when the state changes, sent as an alert by email — and on plans that include them, by Slack or webhook — alongside blocklist listings for the same addresses, which tend to be the other half of the same story.