Blog

created on: 2026-10-03 00:13:10

How to Set Up PTR (Reverse DNS) for Postfix Email Servers

If your server's emails are bouncing at Yahoo, AOL, or BT with an error like:

550 5.7.25 Forward-confirmed reverse DNS failed

...you're missing (or have mismatched) reverse DNS. This is a different, separate check from SPF, DKIM, and DMARC β€” all of which can be perfectly configured while this one thing still silently blocks delivery to a subset of providers. Here's what it actually is, where each piece lives, and how to diagnose and fix it properly rather than guessing.

What Forward-Confirmed Reverse DNS (FCrDNS) actually checks

When your server connects to a recipient's mail server, it introduces itself with a hostname (the SMTP EHLO/HELO command). Some receiving mail systems then perform two lookups to confirm that hostname is legitimate:

  1. Reverse lookup (PTR): given your server's IP address, what hostname does it resolve to?
  2. Forward lookup (A record): does that hostname resolve back to the same IP?

If both match, the server is considered legitimate. If either is missing or they don't match, strict providers (Yahoo, AOL, and BT among them) reject the message outright β€” often with no warning beforehand, since this isn't something you can test from your own inbox.

Three settings, three different jobs β€” don't confuse them

This is the single most common source of confusion when fixing this, and it was ours too. Postfix has multiple hostname-related settings that sound similar but do genuinely different jobs:

postconf myhostname       # The server's own identity β€” also affects what mail is treated as "local"
postconf smtp_helo_name   # What's actually announced during outbound SMTP β€” overrides myhostname if set
postconf myorigin         # Used to build the sender address on locally-generated mail (e.g. bounce notices)

The one that actually matters for FCrDNS is smtp_helo_name. If it's explicitly set, it overrides myhostname for every outbound connection β€” so checking myhostname alone can give you a false picture of what your server is actually announcing to the world.

myorigin is a different, unrelated setting β€” it only affects the sender address Postfix uses for mail it generates itself (like bounce/non-delivery notifications), often pointing at /etc/mailname:

cat /etc/mailname

A mismatch here won't cause FCrDNS failures, but it's worth getting right anyway β€” otherwise your own bounce notifications can display a different (possibly wrong, or non-existent) domain than your actual mail server identity, which gets confusing fast when you're trying to diagnose a real problem later.

Where each DNS record actually lives β€” this trips people up

This was the crux of the whole fix for us, and the part most guides gloss over:

  • The forward A record (hostname β†’ IP) belongs in your domain's own DNS zone β€” wherever you manage DNS for that domain (Cloudflare, CrazyDomains, etc.).
  • The PTR record (IP β†’ hostname) belongs to whoever owns the IP address block β€” almost always your hosting provider, not your domain registrar. You cannot set this yourself through your domain's DNS panel, no matter how hard you look for it there.

If your smtp_helo_name uses a subdomain specifically for mail (e.g. relay.yourserver.example.com), you need both pieces set correctly, pointing at each other, for FCrDNS to pass.

Diagnosing it properly β€” don't trust checker tools as ground truth

Third-party tools like dnschecker.org and ispropagated.com are useful for a rough read on global propagation, but we found them genuinely misleading during an active DNS change β€” different public resolvers around the world cache independently and update on their own schedules, so these tools can show "not resolving" for hours or days after a change is actually, correctly live.

The only way to know for certain is to bypass every cache and ask the actual source of truth directly. First, find out who's authoritative:

dig -x 188.65.32.95

Look at the AUTHORITY SECTION of the response β€” it names the real nameserver responsible for that IP's reverse zone:

32.65.188.in-addr.arpa. 6863 IN SOA ns1.hyve.com. hostmaster.hyve.com. ...

Then query that specific server directly, skipping every intermediate cache:

dig -x 188.65.32.95 @ns1.hyve.com

If this returns the correct PTR value, your hosting provider has done their job correctly β€” any remaining delay is genuinely just propagation to the wider internet's resolvers, and the fix is time, not further changes. If the authoritative server itself doesn't return the right answer, that's real evidence to take back to your host, rather than a vague "is it done yet" support ticket.

The same technique works for the forward A record β€” query your domain's own authoritative nameserver directly rather than relying on a public resolver that might be showing you stale cached data:

dig A relay.yourserver.example.com +short

Setting the forward A record

In your domain's DNS panel:

Host:  relay.yourserver        (or however your panel expects a subdomain entered β€” some auto-append the root domain, some don't; check what's actually saved, not just what you typed)
Type:  A
Value: <your server's IP>

Requesting the PTR record from your host

This has to go to your hosting provider, with specifics β€” a vague request tends to sit in a queue. Be precise:

Please could you set up a PTR (reverse DNS) record for <your IP> resolving to <your hostname>. This is our server's configured SMTP HELO identity, and we're seeing mail rejected by providers requiring forward-confirmed reverse DNS. [Attach an actual bounce message as evidence if you have one β€” it gets tickets actioned faster than a description alone.]

Testing once both pieces are confirmed live

Don't just check your own inbox β€” SPF/DKIM were already passing for us before this fix, so test deliveries that specifically exercise FCrDNS-strict providers (Yahoo and AOL share infrastructure, so one address covers both):

echo "Test email" | mail -s "Test" -r you@yourdomain.com someone@yahoo.co.uk

Ask the recipient to confirm receipt (check spam too) β€” and if it bounces, get the full bounce text, not just "it didn't arrive." The exact rejection reason tells you immediately whether you're dealing with the same issue still propagating, or a genuinely different problem (e.g. IP reputation, which can lag behind a DNS fix even once the DNS itself is correct).

Quick summary checklist

Check Command
What hostname does outbound mail actually announce? postconf smtp_helo_name
Does that hostname have a forward A record? dig A <hostname> +short
Does the IP have a matching PTR record? dig -x <ip> +short
Who's actually authoritative, bypassing caches? dig -x <ip> β†’ check AUTHORITY SECTION
Query the authority directly for certainty dig -x <ip> @<authoritative nameserver>
Real-world test against a strict provider mail -s "Test" -r you@domain.com someone@yahoo.co.uk

Written up from a real diagnosis on a client project β€” including the propagation-checker false alarms, the article that nearly sent us down the wrong path by conflating myhostname with smtp_helo_name, and the fix that actually worked.

Poetic Notes:
Ethical Notes:
This caption is purely reflective β€” an imaginative note about perception."