Seeing a delivery error that mentions your "reverse DNS doesn't match the SMTP banner" can be confusing if you're not familiar with how mail servers introduce themselves to each other. This article explains the two pieces involved, why a mismatch matters, and how to get it corrected.
Two things a mail server checks: reverse DNS and the SMTP banner
When your mail server connects to another server to deliver a message, two separate pieces of information come into play:
- Reverse DNS (PTR record): the hostname associated with your server's sending IP address, discovered through a reverse DNS lookup.
- SMTP banner: the greeting your mail server sends as soon as the connection opens, which typically includes a hostname it claims to be.
Receiving mail servers compare these two values. If the hostname in your SMTP banner doesn't match — or isn't clearly related to — the hostname your reverse DNS lookup returns, that inconsistency looks suspicious. It's a pattern often seen in spoofed or poorly configured mail servers, so legitimate providers and spam filters both treat it as a warning sign.
Why this mismatch causes deliverability problems
A mismatch between reverse DNS and the SMTP banner doesn't automatically get your email rejected, but it removes one of the trust signals a receiving server relies on. Combined with other weak signals (missing SPF/DKIM, poor sender reputation, a new sending IP), it can tip a message into the spam folder or trigger an outright rejection.
Common causes
- Misconfigured DNS records — the PTR record was never updated after a server or hosting change.
- Incorrect mail server hostname settings — the SMTP banner was configured with the wrong or outdated hostname, often after a migration.
- Multiple domains sharing one IP address — on shared mail infrastructure, it's possible for the banner presented to not line up cleanly with the PTR record if hostnames weren't set up carefully for each domain.
A useful habit when migrating mail service to a new provider: get the PTR record pointed at the new IP address before cutting over MX records, not after. Doing it in the wrong order is a common reason administrators end up chasing a mismatch for days following a migration.
How to check for a mismatch
- Look up your sending IP's reverse DNS result using a public DNS lookup tool or the
dig -x/nslookupcommands. - Compare that hostname to the one your mail server presents in its SMTP banner (this is often visible in the headers of a test email, or by connecting to your own mail port and reading the greeting).
- If possible, run the check from an external network rather than your own — some firewalls present a different banner to internal versus external connections, which can hide a mismatch that outside servers still see.
Fixing the mismatch
Both values need to agree, and getting there usually means correcting one of two things: the PTR record, or the hostname configured on the mail server itself. On Avalon Hosting's mail infrastructure, PTR records are managed by our network team rather than through your domain's own DNS zone. If you notice a mismatch on mail sent through Avalon's servers, contact Avalon Hosting support with the sending IP and the hostname you'd expect it to resolve to, and we'll verify and correct it.
Common issues
Does this affect authentication protocols like SPF or DKIM? Not directly — SPF and DKIM are separate checks. But because a reverse DNS/banner mismatch damages overall trust in the connection, it's worth resolving alongside a healthy SPF, DKIM, and DMARC setup rather than in isolation.
I fixed my PTR record, when will it take effect? DNS changes take time to propagate across the internet, and receiving servers may cache the old result for a period. Give it up to 24–48 hours before re-testing.
