How Your Mail Server Identifies Itself During an SMTP Connection
When your mail server connects to a recipient server to deliver email, the very first thing it does after the TCP connection is established is introduce itself. That introduction happens through the EHLO command (or its older predecessor HELO), and it looks like this:
220 mail.example.com ESMTP Postfix
EHLO mail.example.comThat hostname in the EHLO line is your SMTP banner. It is what your server claims to be.
The receiving server then does something independent of whatever you just said: it takes the IP address your connection came from and looks it up in reverse DNS. The question it is asking is: "what hostname does this IP address actually belong to?" That answer comes from your PTR record, which is a DNS record that maps an IP address back to a hostname.
If the EHLO says mail.example.com but the PTR record for your sending IP says vps123.hostingprovider.com, those two identities do not match. That is the warning.
The receiving server is essentially asking: "You say you are mail.example.com, but the IP you are connecting from is registered to something else. Which one is real?" It is a legitimate question.
Why receiving servers care about this
The reason this check exists is that legitimate mail servers have consistent identities. A properly configured mail server has a hostname that matches both its forward DNS (the A record for that hostname points to the IP) and its reverse DNS (the PTR for that IP points back to the hostname).
This bidirectional match is called Forward-Confirmed Reverse DNS, or FCrDNS, and it is one of the oldest and most reliable signals that a sending IP is operated by someone who actually knows what they are doing with it.
Spam infrastructure almost never passes FCrDNS. Compromised residential machines, botnet nodes, and hastily spun-up VPS instances all tend to have the generic PTR their provider assigned, or no PTR at all. The FCrDNS check fires before SPF, DKIM, and DMARC are even evaluated.
The receiving server is making a trust decision at the connection layer, before it has seen a single byte of your message content or headers.
This ordering matters more than most people realize. You can have perfect SPF alignment, a valid DKIM signature, and a strict DMARC policy, and still get throttled or rejected at the connection stage because the FCrDNS check failed.
Those are message-level authentication checks. PTR alignment is infrastructure-level. They are different layers, and the infrastructure check runs first.
The Three Pieces That Have to Align
There are three records that all need to agree on the same hostname and IP combination. Getting any one of them wrong produces this warning.
The PTR record maps your sending IP to a hostname. If your server sends from 192.0.2.10, the PTR for that IP needs to point to your mail server's fully qualified domain name, for example mail.example.com.
The A record maps that hostname back to the IP. So mail.example.com needs an A record pointing to 192.0.2.10. This is the "confirmed" part of Forward-Confirmed Reverse DNS. The check is not just that a PTR exists, but that the hostname the PTR points to also resolves forward to the original IP.
The SMTP banner is what your mail server says in the EHLO command. This needs to match the PTR hostname exactly. If your PTR says mail.example.com but your server's EHLO says server.example.com, you still have a mismatch even though both are in your domain.
All three need to point to the same hostname. The PTR points to the hostname. The hostname's A record points back to the IP. And your EHLO announces that same hostname. When those three things agree, FCrDNS passes cleanly.
Who Actually Controls Each Record
Here is where a lot of people get stuck, and where the fix path diverges completely.
The A record and your SMTP banner are things you control directly. The A record lives in your domain's DNS zone at your registrar or DNS provider. The SMTP banner is configured in your mail server software: myhostname in Postfix, ServerName in Exim, smtp_helo_name in other MTAs.
The PTR record is controlled by whoever owns the IP address block, which is your hosting provider, VPS provider, or ISP. Not your domain registrar. You cannot set a PTR record at Cloudflare or GoDaddy. The PTR lives in a special reverse DNS zone under .in-addr.arpa (for IPv4) or .ip6.arpa (for IPv6), and that zone is delegated to the organization that owns the IP range.
This means if you are on a VPS at DigitalOcean, Hetzner, Vultr, Linode, or any similar provider, you need to set the PTR through their control panel. Most of them surface it as a "Reverse DNS" or "PTR" field in the droplet or server settings.
AWS is the annoying exception: you either do it through the Elastic IP settings or open a support ticket, depending on the type of IP assignment. Azure and Google Cloud have their own control panel paths.
If you are on shared hosting, you almost certainly cannot set a custom PTR. The IP is shared across hundreds of customers and your provider controls the PTR. In that case, the fix is either to move to a dedicated IP, switch to a transactional email service like Postmark, SendGrid, or Mailgun (which manage their own PTR records on their infrastructure), or accept the warning as unfixable in your current environment.
The Scenarios That Cause This Warning
This warning has a short list of root causes. Most of them come down to one of four situations.
VPS or dedicated server with default PTR. You spun up a server, configured Postfix or Exim, pointed your MX records at it, and started sending. The server works fine. But your hosting provider assigned a PTR record by default that looks like vps12345.provider.com or static.123-45-67-89.example-isp.net.
Your EHLO says mail.yourdomain.com. Mismatch. This is the most common cause by far, and the fix is just going into your provider's control panel and setting the PTR to match your mail server's hostname.
Server migration without updating PTR. You moved to a new IP, updated your A record and MX, updated the EHLO on the new server, but forgot to request a PTR update on the new IP. The old IP's PTR still exists but is now irrelevant. The new IP has a generic provider PTR. Same mismatch, different cause.
Shared outbound gateway or relay. If multiple servers route outbound mail through a single gateway IP, that IP has exactly one PTR record. If the servers announce different hostnames in their EHLO commands, some of those connections will fail FCrDNS. This is a common problem in environments where internal infrastructure passes mail through a central relay before it exits to the internet.
The relay's IP is what the receiving server sees, and the relay needs to be the thing announcing a hostname that matches its PTR.
IPv6 sending without an IPv6 PTR. This one catches people constantly, and it is worth calling out specifically. Your server may have both IPv4 and IPv6 addresses. You set up a PTR for your IPv4 address and moved on. But your server's networking stack prefers IPv6 for outbound connections, so when it connects to Gmail or Microsoft, it is connecting from the IPv6 address, which has no PTR record at all, or has the generic provider PTR. Gmail in particular enforces IPv6 PTR requirements strictly and will issue a 550 5.7.1 rejection with a specific IPv6 error message.
You can either configure a PTR for your IPv6 address through your provider, or force your mail server to use IPv4 for outbound SMTP connections until you get the IPv6 PTR set up.
How to Diagnose Which Piece Is Wrong
Before making any changes, verify the current state of all three records. This takes about two minutes.
Check your PTR record:
dig -x YOUR.SENDING.IP +shortReplace YOUR.SENDING.IP with the actual IP your server sends mail from. If you are not sure what that IP is, send a test email and look at the Received headers. The connecting IP will be in the first Received line.
The output should be your mail server's FQDN. If it is a generic provider hostname, that is your problem. If it returns nothing (NXDOMAIN), you have no PTR at all.
Check the A record for that hostname:
dig mail.example.com A +shortIt should return the same IP your server sends from. If it returns a different IP, or no result, your FCrDNS will fail even after you fix the PTR.
Check your SMTP banner:
telnet YOUR.SENDING.IP 25After connecting, you will see the server's greeting line. It should show your mail server's hostname. Alternatively, run an MXToolbox SMTP test against your domain: it will show the full SMTP session transcript including the EHLO banner.
Now compare all three. The PTR hostname, the A record hostname, and the EHLO hostname need to be identical.
How to Fix It
The fix path depends on which record is wrong.
If the PTR is wrong or missing: Go to your hosting provider's control panel and update the reverse DNS for your sending IP to your mail server's FQDN. Before doing this, confirm that the A record for that hostname already exists and points to the correct IP. Most providers validate the A record before applying the PTR to prevent abuse.
After updating, PTR propagation is generally faster than forward DNS, usually within an hour, but some providers cache aggressively so give it a few hours before testing.
If the SMTP banner is wrong: Find the hostname configuration in your mail server software and update it to match the PTR hostname.
Postfix: set
myhostname = mail.example.comin/etc/postfix/main.cf, then runpostfix reloadExim: set
primary_hostname = mail.example.comin the Exim configuration, then restartcPanel/WHM: go to Service Configuration, then Exim Configuration Manager, find the SMTP banner setting, update it there
If you are on cPanel/WHM specifically: The Exim Configuration Manager has an option to customize the SMTP banner. The default banner often uses the server's hostname, which may not match the PTR if the server was set up before proper PTR configuration. Set the banner to the same FQDN as your PTR.
After making changes, verify with:
dig -x YOUR.SENDING.IP +short
dig mail.example.com A +shortBoth should resolve to the same hostname and IP respectively. Then run a full SMTP test through MXToolbox or mail-tester.com to confirm the warning is gone.
The Piece Nobody Explains: This Check Precedes Your Authentication Stack
Most guides cover the fix steps and stop there. What they skip is the implication of where this check sits in the sequence.
When a receiving server accepts an inbound SMTP connection, it evaluates trust in layers. The connection-level check, which includes the PTR lookup and FCrDNS verification, happens before the server has seen your SPF record, your DKIM signature, or your DMARC policy.
At this point, all the receiving server knows is: an IP address connected to me, and I can either verify or not verify that this IP is what it claims to be.
Gmail documents this explicitly. A server without a valid PTR can trigger a 421 4.7.23 temporary rate limit or a 550 5.7.25 permanent rejection before any message-level evaluation happens. Microsoft's filters assign negative sender reputation scores to IPs with missing or mismatched PTR records.
These penalties accumulate in sender reputation databases even if your messages are not individually rejected, meaning they degrade your deliverability over time on warm sending pools.
The practical implication: if you manage mail infrastructure for clients, whether you are an MSP running customer mail servers or an IT team managing internal infrastructure, a PTR mismatch is not just a health check warning.
It is an ongoing deliverability tax that compounds quietly. Emails that make it through are still being scored as marginally less trustworthy. Over time, that affects inbox placement rates, not just bounce rates.
What DNS Spy Flags and Why
DNS Spy's scanner flags this warning when the PTR record for a domain's mail server IP does not match the hostname the mail server announces in its SMTP banner. The check is part of the mail infrastructure health scan, not just the DNS record scan, because the mismatch lives at the intersection of DNS configuration and mail server configuration.
The value of catching this through monitoring is not just the initial detection. PTR records can drift. Your hosting provider can reassign IPs during infrastructure maintenance. You can migrate to a new server and do everything right on day one, but six months later a provider-side change breaks the alignment silently. Your SPF and DKIM keep passing.
Your mail keeps delivering. But your connection-layer trust score is quietly degrading. Without ongoing monitoring, you do not find out until deliverability starts showing unexplained dips.
Run a full DNS and mail infrastructure scan on your domains at dnsspy.io. The scanner checks PTR alignment alongside CNAME chains, SOA values, WHOIS expiration, and dangling records so you are not finding these issues by chasing bounce logs.
