Reverse DNS does not match SMTP banner: what the warning means and how to fix it
Your mail server greets with a hostname that does not match the PTR record of its IP. What is compared, who fixes each side, and the dig commands to check.
On this page
The warning means the host name your mail server announces in its SMTP greeting is not the host name that the PTR record of your sending IP address resolves to. MxToolbox's SMTP banner check (opens in a new tab) raises it when the name the server presents is not in the same domain as the host name a PTR lookup on the IP returns. MxToolbox recommends asking your ISP for a PTR record that matches your mail server's host name; then check that this host name's A record resolves back to the same IP, as Google's sender guidelines (opens in a new tab) require for a valid reverse and forward lookup.
What is being compared
A mail server answers a connection on port 25 with a greeting. RFC 5321 (opens in a new tab) calls it the connection greeting, a 220 reply whose first word after the code is the official, fully qualified primary domain name of the server host, for example 220 mail.example.com SuperSMTP v 6.1.2 Service ready. MxToolbox (opens in a new tab) calls that string the SMTP banner and describes its purpose as announcing the server and anything the administrator wants to convey. The server also names itself in the reply to the client's EHLO, as RFC 5321 section 4.1.1.1 (opens in a new tab) notes, and under section 2.3.5 (opens in a new tab) only resolvable fully qualified domain names are allowed in SMTP; a name that is not an FQDN is a local alias and must not appear.
The other side of the comparison is reverse DNS. RFC 1912 (opens in a new tab) asks that every IP address have a matching PTR record in in-addr.arpa, that PTR and A records match, and that a PTR point to a real A record rather than a CNAME, warning that a mismatch can cost Internet services in the same way as not being in DNS at all. Google's sender guidelines (opens in a new tab) spell out the pair of lookups: the sending IP must have a PTR record resolving to a host name (the reverse lookup), and that host name must have an A or AAAA record resolving to the same IP (the forward lookup). MxToolbox's companion test, Reverse DNS does not contain the hostname (opens in a new tab), fires when the A record of the host name does not match the PTR of the IP.
Check your domain now
See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.
Why it matters for delivery
Google's sender guidelines (opens in a new tab) require sending domains or IPs to have valid forward and reverse DNS records, with the sending IP matching the IP of the host name in the PTR record, so a server without a correct PTR fails a requirement Gmail publishes. The banner itself is softer. MxToolbox (opens in a new tab) notes that some receivers treat a mismatched or masked banner as one signal in a spam-scoring system, but that most do not reject mail solely on that basis. RFC 5321 section 4.1.4 (opens in a new tab) lets a server verify that the EHLO name corresponds to the client's IP but forbids it from refusing a message on that basis alone; the information is for logging and tracing. The same document's section 7.9 (opens in a new tab) also records the long-standing principle that a server may refuse mail for any operational or technical reason that makes sense to its site.
Check the three names yourself
This example uses the address 192.0.2.25 and mail.example.com as the server name. Run the reverse lookup, then the forward lookup of the name it returns:
dig -x 192.0.2.25 +short
dig A mail.example.com +short
The first command should return mail.example.com. and the second 192.0.2.25. Then read the banner, the text your server sends when another host connects on port 25, and compare its host name with the PTR answer; MxToolbox (opens in a new tab) warns when the two are not in the same domain. Google's sender guidelines (opens in a new tab) point to the Google Admin Toolbox Dig tool for the PTR check, and RFC 1912 (opens in a new tab) is the rule the PTR and A records must satisfy: they match.
Fix the PTR record
Reverse DNS is usually not in your own zone. cPanel's reverse DNS documentation (opens in a new tab) says most cPanel and WHM users do not have the authority to edit their PTR record directly, that some hosting providers offer reverse DNS management in a client interface, and otherwise to contact the hosting provider; it also notes that for mail purposes only the IP addresses that send mail need PTR records. MxToolbox (opens in a new tab) gives the same advice: ask your ISP to set up a reverse record that matches your mail server's host name. Set the PTR to the server's FQDN, mail.example.com, and make sure an A record for that name points back to the IP, as RFC 1912 (opens in a new tab) requires.
Fix the banner hostname
On Postfix, the banner comes from smtpd_banner, which starts with myhostname. Postfix's postconf documentation (opens in a new tab) defines myhostname as the Internet host name of the mail system, defaulting to the FQDN from gethostname(), with the example myhostname = host.example.com; and smtpd_banner, default $myhostname ESMTP $mail_name, as the text that follows the 220 code in the greeting, which must start with $myhostname because the SMTP protocol requires it. Postfix's basic configuration guide (opens in a new tab) adds that you have to set myhostname explicitly when the machine name is not in FQDN form or Postfix runs on a virtual interface, and that changes to main.cf take effect after postfix reload.
myhostname = mail.example.com
smtpd_banner = $myhostname ESMTP $mail_name
On a cPanel server, set the server host name. cPanel's Change Hostname documentation (opens in a new tab) requires a fully qualified domain name that uniquely identifies the server, such as hostname.example.com, says the host name should also resolve to the server's main IP address, and walks through WHM's Change Hostname interface, the Add An A Entry button for the new name, and the set_hostname utility for the command line.
Not an SPF, DKIM or DMARC issue
SPF, DKIM and DMARC work at the level of the domain in the mail. SPF (opens in a new tab) publishes which hosts may use a domain's name, and receivers test the sending server against that record for the HELO or MAIL FROM identity; DMARC (opens in a new tab) builds on SPF and DKIM to give domain owners feedback and policy enforcement over unauthenticated mail. If the same report flagged your SPF record ending, see SPF record with a hard fail; if messages fail DMARC, see DMARC fail. The free SPF, DKIM and DMARC check reads the public DNS records of the domain you enter, not the PTR record of an IP address, and shows how the domain's SPF, DKIM and DMARC are set up without an account.
Sources
- MxToolbox: SMTP Banner Check (opens in a new tab)
- MxToolbox: SMTP Reverse DNS Mismatch (opens in a new tab)
- RFC 5321 section 4.3.1: the connection greeting (opens in a new tab)
- RFC 5321 section 4.1.1.1: EHLO and HELO (opens in a new tab)
- RFC 5321 section 2.3.5: domain names (opens in a new tab)
- RFC 5321 section 4.1.4: order of commands and EHLO verification (opens in a new tab)
- RFC 5321 section 7.9: scope of operation (opens in a new tab)
- RFC 1912 section 2.1: inconsistent, missing or bad data (opens in a new tab)
- Google Workspace Admin Help: Email sender guidelines (opens in a new tab)
- Postfix: postconf(5) (opens in a new tab)
- Postfix: basic configuration (opens in a new tab)
- cPanel: Change Hostname (opens in a new tab)
- cPanel: How to configure reverse DNS in WHM (opens in a new tab)
- RFC 7208 section 1: SPF (opens in a new tab)
- RFC 7489 section 1: DMARC (opens in a new tab)
Tools for this
-
SPF, DKIM and DMARC check
Check the email records a domain publishes today and see what to fix first.
Frequently asked questions
Will mail bounce because of this warning?
Usually not on its own. MxToolbox notes that some receivers use a mismatched banner in a spam-scoring system but most do not reject mail solely on this basis, and RFC 5321 forbids a server from refusing a message only because EHLO verification failed. Google's sender guidelines do ask sending servers to have a PTR record whose host name resolves back to the sending IP.
I cannot edit the PTR record. Who can?
The owner of the IP address, which is normally your hosting provider or ISP. cPanel's documentation says most users cannot edit their PTR record directly and should ask the provider; some providers offer reverse DNS management in their client panel.
Does the banner have to equal my email domain?
No. The banner carries the fully qualified name of the server host, such as mail.example.com, and MxToolbox warns when that name is not in the same domain as the host name the PTR record of the sending IP returns.
Check your domain now
See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.