Diagnostic Mail Routing
Missing reverse DNS for outbound mail IP
Your mail server sends a message, the connection looks fine, and then the receiving side rejects it or drops it straight into spam. No typo in the address, no bad password, nothing obviously wrong. The real problem is one level below your domain: the IP address your mail server sends from has no reverse DNS record pointing back to a real hostname, or that record does not match. Here is why that alone is enough to get you rejected, and the exact steps to fix it.
The IP your mail server sends from has no PTR (reverse DNS) record, or its PTR record points to a hostname whose forward A lookup does not resolve back to that same IP (failing Forward-Confirmed reverse DNS, or FCrDNS). Receiving mail servers like Gmail, Yahoo, and Microsoft treat a missing or non-matching PTR as a strong spam signal, and since February 2024 Gmail and Yahoo require valid reverse DNS for bulk senders, so this now causes outright rejections. The fix has two parts: add a forward A record for your mail hostname in your own DNS zone, then ask the owner of the IP address, almost always your hosting or cloud provider, to set the PTR record on that IP to match.
The problem in plain words
Every mail server has two DNS lookups working against it at once. A forward lookup turns a hostname into an IP address, which is what most DNS records do. A reverse lookup does the opposite: it turns an IP address back into a hostname, using a special record called a PTR record. Legitimate mail servers are expected to have a stable hostname that a reverse lookup can find, and that hostname's own forward lookup should point right back to the same IP. That round trip is called Forward-Confirmed reverse DNS, or FCrDNS.
When the IP your mail comes from has no PTR record at all, or the PTR record exists but points to a hostname that does not resolve back to that IP, the round trip breaks. Spammers routinely send from IPs with no reverse DNS, because setting it up takes an extra step and most disposable sending infrastructure never bothers. So the absence of a matching PTR looks, to a receiving server, exactly like the kind of IP a spammer would use, even if you are running a completely legitimate mail server.
Why it happens
RFC 7601 documents reverse DNS (called iprev) as one of the signals a receiving server checks when it decides whether to trust an incoming connection, and mailbox providers have built hard rules around it. A few common ways a mail server ends up sending from an IP with no matching PTR:
- A new server was spun up on a cloud provider and mail was configured right away, but nobody requested a PTR record for the new IP, so reverse DNS was simply never set.
- The PTR record points to the cloud provider's own default hostname (something like
ec2-203-0-113-10.compute-1.amazonaws.com) instead of your mail hostname, so it exists but does not match your sending domain's identity. - A PTR record was set once, but the forward A record for that hostname was later changed, deleted, or moved to a different IP, so the forward lookup no longer returns the original address and FCrDNS now fails.
- The mail server's HELO or EHLO greeting uses a different hostname than the one in the PTR record, so even a correct PTR does not line up with what the server announces itself as.
Whatever the cause, the practical effect changed in February 2024: Gmail and Yahoo now require valid reverse DNS for bulk senders, so this went from a mild spam-folder penalty to an outright SMTP rejection.
The PTR record is not something you set in your own domain's DNS zone. It lives in the reverse DNS zone, in-addr.arpa for IPv4, and that zone is controlled by whoever owns the IP address block, almost always your hosting or cloud provider. You can add every forward record you want in your own zone, but the matching PTR has to be requested from the party that owns the IP.
The fix, as a flow
Confirm the reverse lookup is missing or does not forward-confirm, add the forward A record for your chosen mail hostname in your own zone, then ask the IP's owner to set the PTR record on that IP to point at the same hostname.
How to fix it
Confirm the reverse lookup is missing
Run a reverse lookup on the IP your mail server actually sends from. An empty result, or an error saying no PTR record was found, confirms there is no reverse DNS set at all for this IP.
dig -x 203.0.113.10 +shortIf a PTR name comes back, forward-confirm it
A PTR record can exist and still be wrong. Take the hostname the reverse lookup returned and run a forward A lookup on it. If that forward lookup returns no address, or an address that is not the original sending IP, FCrDNS fails even though a PTR technically exists.
dig A mail.example.com +shortPick the hostname you want the IP to resolve to
Choose a single, stable hostname for this sending IP, such as mail.example.com. This should be a real hostname you control, and it should match, or at least be consistent with, your mail server's HELO or EHLO greeting and your SPF and DKIM aligned sending domain.
Add the forward A record in your own DNS zone
In your domain's DNS zone, such as Cloudflare, add an A record for the mail hostname pointing at the sending IP. This is the forward half of the pair, and it is the one record you control directly.
mail.example.com. 3600 IN A 203.0.113.10Ask the IP's owner to set the matching PTR record
The PTR record lives in the reverse zone controlled by whoever owns the IP address block, not your domain's DNS host. On AWS this means opening an Elastic IP reverse DNS request through Support Center, which requires using an Elastic IP and having port 25 sending limits already lifted. On DigitalOcean, Hetzner, and Linode this is a field in the cloud console, usually under Networking, the IP address, and a PTR or rDNS setting. On Cloudflare, this only applies if you have your own IP space delegated to Cloudflare through BYOIP with the reverse zones feature, where you add the PTR record under Reverse Zones.
Make sure HELO and EHLO match
Set your mail server's HELO or EHLO greeting to the same hostname you just used for the PTR and forward A record. A mismatch between what the server announces and what reverse DNS says is its own smaller red flag, worth closing at the same time.
How to check it worked
Re-run the reverse lookup and confirm it now returns your chosen hostname, then run the forward lookup on that hostname and confirm it returns the exact same IP you started with.
# 1. Confirm the PTR record now returns a hostname
dig -x 203.0.113.10 +short
# 2. Confirm the forward A lookup of that hostname matches the original IP
dig A mail.example.com +short
# 3. Confirm the SMTP banner and HELO both match the same hostname
telnet mail.example.com 25
# 4. Send a real test message and read the report
# https://www.mail-tester.com/A good result looks like this: the reverse lookup returns mail.example.com., and the forward lookup of that same name returns exactly 203.0.113.10, the two now match and FCrDNS passes. A test message sent to mail-tester.com no longer flags "host has no reverse DNS (PTR)" or "the reverse DNS of your server does not match the domain," and real test emails land in the inbox instead of bouncing with a 550 5.7.25 class error.
Case studies
The mail server nobody asked for reverse DNS on
A small team spun up a new transactional mail server on a cloud provider, set SPF, DKIM, and DMARC correctly, and started sending. Delivery to most providers was fine at first, but Gmail started rejecting the connection outright with a 550 error mentioning reverse DNS within days of the Gmail bulk sender requirements taking effect.
A reverse lookup on the sending IP came back completely empty, no PTR record had ever been requested for the new IP. Adding the forward A record and filing the provider's reverse DNS request cleared the rejections within a few hours once the change propagated.
The PTR that pointed at a hostname that moved
A company migrated their mail hostname's A record to a new IP during a server upgrade, but never touched the PTR record, which still pointed reverse lookups at the same hostname as before. The reverse lookup on the new IP returned nothing, since the PTR for the new IP had never been created in the first place, and the old hostname's forward record now pointed somewhere else entirely.
Mail-tester flagged the mismatch immediately. Once the provider set a PTR record for the new IP to the mail hostname, and the forward A record was confirmed to point back at that same new IP, the FCrDNS check passed and deliverability recovered.
A healthy sending IP always has a PTR record that returns a real hostname, and that hostname's own forward A lookup returns the exact same IP. When that round trip matches, and it lines up with your HELO greeting and your SPF and DKIM aligned domain, reverse DNS stops being a reason for rejection at all. Check this any time you provision a new sending IP or move mail to a new server, since either change can quietly leave the PTR behind.
FAQ
Why does Gmail reject my mail with a message about reverse DNS?
The IP address your mail server sends from has no PTR record, or the PTR record points to a hostname whose forward lookup does not return that same IP. Since February 2024 Gmail and Yahoo require valid matching reverse DNS for bulk senders, so mail from an IP that fails this check is rejected outright instead of just being marked as spam.
Who controls the PTR record for my mail server's IP?
The owner of the IP address block controls the PTR record, which is almost always your hosting or cloud provider, not your domain's DNS host. You set the forward A record for your mail hostname in your own DNS zone, but you ask your provider (AWS, DigitalOcean, Hetzner, and similar) to set the matching PTR record on the IP itself.
What is Forward-Confirmed reverse DNS (FCrDNS) and why does it matter here?
FCrDNS means the PTR lookup of an IP returns a hostname, and the forward A lookup of that same hostname returns the original IP. Receiving mail servers use this match as a sign that the sending server is stable and properly configured. A PTR that exists but does not forward-confirm is treated the same as having no PTR at all.
Related field notes
Citations
On the problem:
- RFC 7601: Message Header Field for Indicating Message Authentication Status (iprev). rfc-editor.org/rfc/rfc7601
- How To Fix 550 5.7.25: Reverse DNS/PTR Record Failure. emailwarmup.com
- Cloudflare Learning: What is a DNS PTR record? cloudflare.com/learning/dns/dns-records/dns-ptr-record
On the solution:
- Cloudflare DNS docs: Reverse zones and PTR records. developers.cloudflare.com/dns/additional-options/reverse-zones
- AWS re:Post: Request for Reverse DNS (PTR) record for SES Dedicated IP. repost.aws
- Baeldung on Linux: Checking PTR Records Using the Command Line. baeldung.com/linux/check-ptr-records
Stuck on a tricky one?
If you have a DNS, mail routing, or deliverability problem you would rather hand off, this is the kind of work I do. Message me and we can work through it together.
Did this fix your mail rejections?
If this helped clear a reverse DNS problem you were chasing, you can buy me a coffee. It is the best way to keep these field notes free and growing.
Buy me a coffee on Ko-fi