Forward-confirmed reverse DNS

A sending host names itself in three places, and receivers check that the three agree. Disagreement is one of the oldest and cheapest spam signals there is, and it is still routinely wrong on hosts that have everything else right.

The three names

1. The connecting IP address           203.0.113.25
2. Its PTR record                      mail.example.com
3. The HELO/EHLO name it announces     mail.example.com

and, closing the loop:
4. mail.example.com resolves back to   203.0.113.25

Steps 2 and 4 together are forward-confirmed reverse DNS: the address names a host, and that host names the address. Either direction alone proves nothing, because anyone can publish an A record pointing at any address.

Checking it

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

Both must answer, and they must agree.
The HELO name should be the same hostname.

What goes wrong

• No PTR at all. Common on cloud instances, where the PTR is set by the provider and nobody asked. Many receivers reject outright.
• A generic provider PTR. ec2-203-0-113-25.compute-1.amazonaws.com resolves and confirms, and it says “this is an arbitrary rented machine”. Treated with suspicion by most filters.
• A PTR that does not resolve forward. Half the loop, which reads as carelessness or as an attempt to look legitimate.
• A HELO name that differs. A host announcing localhost, an internal name, or a bare IP literal. Free to fix and frequently missed.

Whose problem it is

If you send through a platform, theirs — and they will have it right, because it is the first thing that would break their business. If you run your own outbound MTA, or relay through a cloud instance, yours. The PTR usually has to be set in the hosting provider’s console rather than in your DNS, which is why it is the record people forget they can even change.