How do you fix 'Reverse DNS does not match SMTP banner'?

Fix Reverse DNS does not match SMTP banner by testing the public SMTP endpoint named by the warning, checking that IP's PTR and forward DNS, then making the server greeting and intended hostname consistent. An SMTP banner is the server's opening 220 greeting, not the client EHLO command. This warning identifies an infrastructure mismatch to investigate. It does not prove that SPF, DKIM, or DMARC failed, and changing a DMARC policy will not correct it.

At a glance

Quick takeaways

• Capture the exact public IP, SMTP port, and opening 220 greeting from the failing check.
• Query the PTR for that IP and confirm its hostname resolves forward to the same address.
• Determine which SMTP service or virtual interface emitted the greeting before changing DNS.
• Make one intended public hostname consistent across PTR, forward DNS, and the SMTP banner.
• Retest the same endpoint and port after the change.

What does the failure mean?

The warning means a health check connected to an SMTP service and found that the public IP's reverse DNS name differs from the hostname shown in the service's opening banner. cPanel's explanation of the warning says third-party SMTP checks report it when the server hostname and PTR are configured differently. Treat the result as evidence about that endpoint and port, then verify which service actually answered.

An SMTP server starts a session with a 220 greeting under RFC 5321. The client later sends HELO or EHLO, which is a different identity field. The warning is about the server banner, so changing an outbound client's EHLO value is not a repair unless the same system and configuration also control the server greeting. DMARC is separate message authentication and does not need a policy change for this infrastructure warning.

Observed health-check warning: Reverse DNS does not match SMTP banner
Evidence to collect: public IP, SMTP port, PTR answer, A or AAAA answer, opening 220 greeting

What usually causes it?

The PTR points to a different hostname than the SMTP service announces

This is the most direct cause. cPanel documents that its Exim service normally returns the server hostname in its SMTP banner and that a differently configured PTR can trigger the warning. Confirm both names for the exact public endpoint before deciding which one should be the intended hostname.

The PTR hostname does not resolve back to the public IP

The reverse answer can exist but still point to a hostname whose A or AAAA response does not include the tested address. This is a separate DNS defect. Gmail's sender guidance requires a sending IP's PTR hostname to resolve forward to the same IP for mail sent to personal Gmail accounts.

A virtual SMTP interface uses a different greeting

One server can listen on several addresses or use a per-interface banner. The host's default name may look correct while the IP and port tested by the checker return another name. That conclusion is an inference from the endpoint evidence, not a universal SMTP requirement.

The IP provider still has an old PTR value

PTR records live in a separate ARPA reverse-DNS hierarchy, not in the ordinary forward zone. Microsoft's reverse-DNS overview explains that the organization assigned an IP block manages the corresponding reverse zone, or its provider may manage it on its behalf. That separation can leave an old PTR in place after a forward-DNS change.

How do I diagnose the failure?

1. Capture the tested endpoint and the opening banner

Record the public IP and port from the health-check result. Connect to that same endpoint or review its SMTP log and save the opening 220 greeting. Do not substitute an outbound delivery trace, an EHLO value from another route, or a dashboard label.

2. Query PTR for that exact public IP

Run a reverse lookup for the tested address. Compare the returned hostname with the PTR concept in the PTR record guide. If there is no PTR, keep that result as the diagnosed cause before changing the banner.

3. Confirm the forward answer

Resolve the PTR hostname with A for IPv4 or AAAA for IPv6. The response should include the original public IP for that address family. This forward-confirmed reverse DNS check is separate from the banner comparison, but it catches a DNS inconsistency that can affect outbound mail handling.

4. Identify the service that owns the greeting

Find the SMTP service or per-interface configuration that generated the saved 220 line. A load balancer, secondary SMTP daemon, or virtual interface can answer differently from the server's default configuration. Change only the service that owns the tested endpoint.

5. Identify the owner of the failed layer

The IP owner changes PTR, the DNS operator changes A or AAAA, and the SMTP-service owner changes the banner. Assign the narrow repair to the team that controls the failed layer. Do not edit SPF, DKIM, or DMARC unless their independent evidence also shows a problem.

How do I fix it?

Repair a missing or stale PTR through the IP owner

Ask the ISP, cloud provider, hosting provider, or email service that manages the public IP's reverse zone to set the chosen hostname as its PTR. Microsoft's reverse-DNS overview describes that separate reverse-zone authority, while cPanel advises updating the PTR to match the hostname for this warning. Do not publish a guessed PTR in the normal forward zone because it cannot change the reverse zone.

Publish the matching forward DNS record

Publish an A or AAAA record for the chosen hostname that includes the original public IP. Check the authoritative answer before declaring the repair complete. This forward record supports FCrDNS, but it does not by itself change the banner.

Set the affected SMTP banner to the chosen public hostname

Configure the SMTP service that answered the test to present the chosen public hostname in its opening greeting. If the platform maps banners by IP or interface, apply the change only to the affected mapping. Do not copy a vendor-specific configuration example into a different mail server.

Keep policy changes separate from the infrastructure repair

Changing a DMARC p= value changes enforcement, not the PTR, forward DNS, or SMTP banner. Do not weaken DMARC policy or remove authentication controls to silence this warning. Repair the confirmed infrastructure layer first.

How do I validate the repair?

After DNS changes are visible, repeat the original SMTP health check against the same public IP and port. Record the new opening 220 greeting, PTR result, and forward A or AAAA result. The intended hostname should be consistent across the banner and PTR, and the forward answer should include the tested IP.

For a system that also sends mail to Gmail, separately compare the sender IP with Google's current PTR and forward-DNS guidance. Then review a new delivered message and later DMARC aggregate data independently. A repaired banner does not prove that SPF, DKIM, or DMARC passed, nor can it predict a receiver's private reputation decision.

Continue monitoring the sending paths behind the warning

Use Palisade's Email Security Score to review public email-security controls after the route is repaired. If several sending services or client domains make it difficult to keep authentication and alignment evidence organized, Palisade's DMARC Agent analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates remediation tickets, as described in Palisade's Domain Overview documentation. It does not change PTR records, SMTP-service settings, DMARC policy, or a receiver's private reputation decision.

Start with Palisade