550 5.7.1 Client host rejected: cannot find your reverse hostname
A receiving mail server can refuse your connection on the strength of that check alone, before you have offered a single header or a byte of message content. The reason is simple economics: legitimate mail servers have proper reverse DNS, and a large share of spam comes from hosts that do not. Checking the PTR record is nearly free and filters out a lot of junk, so nearly every serious receiver does it. If your mail server's reverse DNS is missing or wrong, you look like the junk.
Forward DNS and Reverse DNS Are Separate Records
Forward DNS answers "what is the IP for this name." Reverse DNS answers "what is the name for this IP," and it lives in a completely different part of the tree, under in-addr.arpa for IPv4 and ip6.arpa for IPv6. Crucially, the reverse record is controlled by whoever owns the IP address: your hosting provider or ISP, a different party from whoever owns the domain. That split is why so many mail servers ship with no PTR: the admin set up the forward record and never realized the reverse one is a separate request to a separate party.
# forward: name -> IP
dig +short mail.example.com
203.0.113.25
# reverse: IP -> name
dig +short -x 203.0.113.25
mail.example.com.
Forward-Confirmed Reverse DNS
Receivers also check that the PTR record is consistent, a test called forward-confirmed reverse DNS, or FCrDNS. The receiver takes your connecting IP, looks up its PTR to get a hostname, then looks that hostname back up in forward DNS and confirms it resolves to the same IP. The loop has to close.
203.0.113.25 --PTR--> mail.example.com --A--> 203.0.113.25 ✓ FCrDNS passes
203.0.113.25 --PTR--> mail.example.com --A--> 198.51.100.9 ✗ mismatch, fails
A mismatch is common and quietly damaging. It happens when the forward record moves to a new IP but the PTR is left pointing at the old name, or when a generic provider PTR like host-203-0-113-25.isp.example was never customized to match the mail hostname you actually announce in HELO.
The HELO Name Should Match Too
The name your server announces in the SMTP HELO/EHLO command should be the same fully qualified hostname that your forward and reverse records agree on. Some receivers score inconsistency between the HELO name and the PTR. All three should line up:
| Element | Value | Set by |
|---|---|---|
| Connecting IP | 203.0.113.25 |
your host |
| PTR record | mail.example.com |
your IP owner (ISP/host) |
| Forward A record | 203.0.113.25 |
your DNS |
| HELO/EHLO name | mail.example.com |
your MTA config |
When those four agree, you pass FCrDNS and present a coherent identity. When they disagree, you hand the receiver a reason to distrust you before authentication even begins.
Generic PTR Records Are a Yellow Flag
Even a technically-passing PTR can hurt you if it looks like a dynamic residential or cloud-default assignment. Names containing patterns like dynamic, dhcp, pool, or a raw dotted-quad embedded in the hostname signal "this is probably an end-user machine," and some receivers weight that against you. Ask your provider to set a clean, purpose-named PTR:
# weak: looks auto-assigned
25.113.0.203.in-addr.arpa. IN PTR ec2-203-0-113-25.compute.example.com.
# strong: names the mail role
25.113.0.203.in-addr.arpa. IN PTR mail.example.com.
IPv6 Makes This Mandatory
If your server has an AAAA record and connects over IPv6, receivers are stricter. Google in particular requires a matching PTR for IPv6 senders, and mail from an IPv6 address with no reverse record is rejected outright. The reverse zone for IPv6 is verbose and easy to get wrong, so verify it yourself.
Verify, Then Keep an Eye on Reputation
Confirm the whole loop from outside your own network, since your local resolver may cache a stale answer. A DNS lookup that queries PTR directly shows you exactly what a receiver sees, and a blacklist check tells you whether the IP has picked up a reputation problem on top of any rDNS issue. Reverse DNS gets you past the front door; reputation is what keeps you in the room after that. Generator Labs blacklist monitoring tracks your sending IPs and domains across hundreds of data sources so a listing does not sit undetected while your rDNS looks perfectly fine. Start monitoring your sending IPs.