Reverse DNS does not match SMTP banner: what to fix

Pick one hostname for your sending server — mail.yourdomain.com — and use exactly that string in four places: the SMTP EHLO banner, a forward A record, the PTR record for the sending IP, and the TLS certificate. A mismatch between the banner and the PTR is one of the oldest and most reliable spam heuristics there is, and some receivers reject on it outright:

550 5.7.1 Client host rejected: cannot find your reverse DNS
554 5.7.1 Service unavailable; reverse DNS does not match SMTP banner
450 4.7.25 Client host rejected: cannot find your hostname

The two lookups involved

Forward DNS maps a hostname to an IP with an A record (AAAA for IPv6). You publish it in your own zone.

Reverse DNS maps an IP back to a hostname with a PTR record in the in-addr.arpa zone. That zone is delegated to whoever owns the IP address — your hosting provider, cloud vendor or ISP. You cannot publish it yourself. You request it, usually through a control panel field labelled "reverse DNS" or "PTR", or via a support ticket.

What receivers want is forward-confirmed reverse DNS: the IP resolves to a hostname, and that hostname resolves back to the same IP. Then they compare the result with the banner your server announced.

Check all of it in three commands

dig -x 203.0.113.9 +short              # PTR: what the IP claims to be
dig +short A mail.yourdomain.com       # forward: does that name point back?
openssl s_client -starttls smtp -crlf -connect mail.yourdomain.com:25

The third command's first line is the banner, and the EHLO response repeats the server's own name:

220 mail.yourdomain.com ESMTP Postfix
EHLO test.example.net
250-mail.yourdomain.com
250-STARTTLS
250 SIZE 52428800

All three strings must be the same hostname. If dig -x returns nothing, no PTR exists at all, which is worse than a mismatch — plenty of receivers reject unknown reverse DNS before looking at anything else.

The three causes

Misconfigured DNS. The PTR says mail.yourdomain.com but no A record exists for that name, or it points at a different IP after a migration. Forward confirmation fails. Fix the A record; it is in your own zone and takes a minute.

The MTA announcing the wrong name. Default installations announce the machine's local hostname — ubuntu-server-01, web02.internal, or an unqualified name with no dots at all. The PTR is fine and the banner is nonsense. In Postfix:

myhostname = mail.yourdomain.com
smtp_helo_name = $myhostname

In Exim, primary_hostname = mail.yourdomain.com. Reload and re-test. An unqualified banner also violates the SMTP specification, which requires a fully qualified domain name or an address literal.

Many domains on one IP. A PTR is per-IP, and a sensible configuration has one PTR per IP. If you host yourdomain.com, otherdomain.com and third.com on one address, you cannot make the PTR match three banners. Pick one canonical name for the *server* — mail.yourdomain.com — and have every domain's mail announce that one name. Receivers compare the banner with the PTR; they do not require the banner to match the From domain. Those are independent checks, and conflating them is the usual source of panic here.

The alternative, when the mail genuinely must be separable, is one IP per sending domain, each with its own PTR and its own forward record.

What a mismatch actually costs you

• Hard rejections from receivers that require FCrDNS, which includes a number of large corporate filters.
• Scoring penalties rather than rejection elsewhere. Content filters add weight for missing or generic reverse DNS; it pushes borderline mail into spam.
• Generic PTR penalties. A PTR like ec2-203-0-113-9.compute-1.amazonaws.com, or anything containing dynamic, dsl, pool or client, marks the IP as consumer or unassigned space. Some filters treat that as near-disqualifying regardless of your authentication.
• TLS trouble on top. If the certificate does not cover the banner hostname, senders enforcing MTA-STS or strict TLS will refuse the connection for a second, independent reason.

Note what a correct PTR does not do: it is not authentication. SPF, DKIM and DMARC still have to be right. Reverse DNS is the hygiene check that happens before anyone looks at your records.

Fix it in order

1. Choose the canonical hostname. One per sending IP.
2. Publish an A record for it pointing at the sending IP. Verify with dig +short A.
3. Request the PTR for that IP from the IP's owner, set to the same name. Verify with dig -x.
4. Set the MTA's hostname and HELO name to the same string and reload.
5. Reissue the TLS certificate so its subject alternative names include that hostname.
6. Re-run all three checks and send a real test message, then read the Received chain in the headers to confirm the receiving side saw what you expect.

What not to do

• Do not try to set a PTR in your own DNS zone. Records you create at 9.113.0.203.in-addr.arpa in your zone are not authoritative and nobody will see them.
• Do not use a hostname that is also a CNAME. PTR targets should resolve directly via an A record.
• Do not accept a provider that will not set a custom PTR. For a sending server, that is a disqualifying limitation, not an inconvenience.
• Do not change the banner without changing the certificate. You will trade one error for another.
• Do not assume shared or hosted sending is affected by this. If you send through a hosted platform, the PTR belongs to its IPs and is its problem; this only applies to servers you operate.

MailPilot warms mailboxes over OAuth or SMTP/IMAP and measures per-provider inbox placement with a seed-inbox network, which is how a transport-level problem like this one becomes visible: placement drops at specific receivers while your authentication records stay green.