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

> Fix a reverse DNS and SMTP banner mismatch by confirming the public source IP, PTR, forward DNS, and EHLO identity.

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.

## 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.

![Reverse DNS and SMTP banner diagnostic flow showing an endpoint, PTR hostname, forward DNS, and server greeting comparison.](/images/editorial/reverse-dns-does-not-match-smtp-banner/reverse-dns-does-not-match-smtp-banner-visual-guide.svg "1600x900")

*Source: Original deterministic diagnostic flow based on [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html) and [cPanel's SMTP banner guidance](https://support.cpanel.net/hc/en-us/articles/1500000922762-Reverse-DNS-does-not-match-SMTP-Banner). [Open the full-size diagnostic flow](/images/editorial/reverse-dns-does-not-match-smtp-banner/reverse-dns-does-not-match-smtp-banner-visual-guide.svg).*

## 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](https://support.cpanel.net/hc/en-us/articles/1500000922762-Reverse-DNS-does-not-match-SMTP-Banner) 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](https://www.rfc-editor.org/rfc/rfc5321.html). 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](/learning/what-is-dmarc) is separate message authentication and does not need a policy change for this infrastructure warning.

```text
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](https://support.google.com/mail/answer/81126?hl=en) 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](https://learn.microsoft.com/en-us/azure/dns/dns-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](/learning/what-is-a-ptr-record). 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](https://learn.microsoft.com/en-us/azure/dns/dns-reverse-dns-overview) describes that separate reverse-zone authority, while [cPanel advises updating the PTR to match the hostname for this warning](https://support.cpanel.net/hc/en-us/articles/1500000922762-Reverse-DNS-does-not-match-SMTP-Banner). 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](https://support.google.com/mail/answer/81126?hl=en). 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](/tools/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](/solutions) 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](https://docs.palisade.email/page-breakdowns/domain-overview/). It does not change PTR records, SMTP-service settings, DMARC policy, or a receiver's private reputation decision.

[Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=smtp_diagnostics&utm_content=reverse-dns-does-not-match-smtp-banner)

## Sources and further reading

- [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html)
- [Gmail email sender guidelines](https://support.google.com/mail/answer/81126?hl=en)
- [cPanel: Reverse DNS does not match SMTP banner](https://support.cpanel.net/hc/en-us/articles/1500000922762-Reverse-DNS-does-not-match-SMTP-Banner)
- [Microsoft: Overview of reverse DNS in Azure](https://learn.microsoft.com/en-us/azure/dns/dns-reverse-dns-overview)
- [Palisade Domain Overview documentation](https://docs.palisade.email/page-breakdowns/domain-overview/)

## Frequently asked questions

### Can I set a PTR record in my normal DNS provider?

Not usually. The party assigned the IP block manages the reverse zone, or its provider may manage it on that party's behalf, as explained in [Microsoft's reverse-DNS overview](https://learn.microsoft.com/en-us/azure/dns/dns-reverse-dns-overview). Your regular DNS provider can host the forward A or AAAA record, but it cannot change a PTR in a reverse zone it does not manage.

### Must the PTR hostname exactly equal the SMTP banner?

Not as a universal SMTP protocol rule. However, the exact warning compares those names, and using one intended public hostname for both is the narrowest way to resolve that comparison after confirming the service and endpoint.

### Does fixing reverse DNS repair DMARC?

No. Reverse DNS repair changes infrastructure identity, while DMARC evaluates whether SPF or DKIM authenticated an identifier aligned with the visible From domain. Check the delivered message and DMARC reports separately after the infrastructure repair.

### Why does the warning persist after I changed the server hostname?

The tested IP may reach a different SMTP interface, load balancer, or secondary service. Repeat the check against the exact IP and port, capture the `220` line, and identify the service that returned it before changing more settings.

### Can a DNS checker prove the warning is fixed for every receiver?

No. A DNS checker can show the published PTR and forward answers, but it cannot prove which SMTP service answered a test or predict each receiver's private policy and reputation decision. Retest the same endpoint and port.