Quick answer
A sending IP whose reverse DNS (PTR) record is missing, generic, or does not agree with the HELO/EHLO name your server announces gets distrusted by large receivers, even when your SPF, DKIM, and DMARC are clean. The fix is to set a forward-confirmed PTR that resolves to a hostname you control, make that same hostname the name you greet with in HELO/EHLO, and request the change from whoever controls the IP. For managed senders such as Google Workspace, Microsoft 365, SendGrid, or Amazon SES, the provider already owns a correct PTR and there is nothing for you to set.
What receivers actually check
Reverse DNS is a PTR record in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) zone that maps a sending IP back to a hostname. When a large receiver opens an SMTP connection, it inspects four things about that IP:
- A PTR record exists. A sending IP with no reverse DNS at all is the weakest possible signal. RFC 1912 §2.1 states plainly that every Internet-reachable host should have a matching PTR record, and that forward and reverse DNS should correspond.
- The PTR hostname is not a generic ISP default. A PTR like
203-0-113-10.dynamic.example-isp.netreads as an unmanaged or residential IP, and receivers weight it as such. A deliberate hostname under a domain you operate reads as a managed mail source. - It is forward-confirmed (FCrDNS). The PTR hostname must itself resolve, via an A or AAAA record, back to the exact sending IP. PTR and forward record have to agree in both directions. Google requires this loop explicitly in its sender guidelines: the IP needs a PTR that resolves to a hostname, and that hostname must have an A or AAAA record pointing back to the same IP.
- The hostname matches the
HELO/EHLOgreeting. At connection time your server greets with a name. RFC 5321 §4.1.1.1 says that name is the fully-qualified domain name of the SMTP client. When the greeting name, the PTR hostname, and the forward record all line up, the IP presents a consistent identity. When they disagree, that inconsistency becomes a reputation penalty.
One thing this is not: reverse DNS (the PTR record) is a different thing from the SPF ptr mechanism. The SPF ptr mechanism is deprecated. RFC 7208 §5.5 titles that section "ptr (do not use)" and states the mechanism SHOULD NOT be published. Do not add a ptr token to your SPF record to satisfy a reverse-DNS requirement. The two are unrelated, and the SPF ptr mechanism is the wrong tool.
It is worth being precise about how hard this signal is. Base SMTP does not turn a mismatch into a rejection. RFC 5321 §4.1.4 says a server MAY verify that the EHLO domain corresponds to the client IP, but if that check fails the server MUST NOT refuse the message on that basis. The result is captured for logging and tracing only. So a HELO/PTR mismatch is not a protocol-level bounce in the base RFC. The reason it still matters is reputation. Large receivers fold reverse DNS, FCrDNS, and HELO consistency into the trust score they apply to your IP, and weak or inconsistent reverse DNS pushes that score down regardless of a clean authentication stack.
How to diagnose a reverse DNS or HELO mismatch
First, find the IP that actually sent the message and the name it greeted with. Both live in the message headers. Read the Received: lines from the bottom up; the originating hop records the sending IP and often the HELO name. Use the real outbound IP here, not your website's IP or your inbound MX host.
Then read the PTR for that IP from any command line:
nslookup -x 203.0.113.10 # Windows
dig -x 203.0.113.10 # macOS / Linux
Take the hostname that comes back and forward-check it:
dig mail.example.com
The address returned has to equal the sending IP. If the PTR is missing, the hostname is a generic ISP string, the forward lookup returns a different IP, or the PTR hostname differs from the HELO name in your headers, you have found the gap. Relaymetry's reverse DNS lookup tool runs the PTR and forward-confirmation check for you if you would rather not reach for the command line.
How to fix reverse DNS and HELO consistency
- Identify the real outbound IP from the
Received:headers of a sent message. - Determine who controls that IP. If you send through a managed provider such as Google Workspace, Microsoft 365, SendGrid, or Amazon SES, the provider owns the PTR for its sending infrastructure, it is already forward-confirmed, and there is nothing for you to configure. Stop here.
- If you send from your own VPS or dedicated IP, request a PTR from the hosting provider. This is set by the network operator that owns the IP block, not by your DNS host or registrar. Most providers expose it through a control-panel field, a support ticket, or a cloud API. AWS, for example, documents how senders bring and operate their own dedicated IPs in Amazon SES.
- Point the PTR at a hostname under a domain you control, for example
mail.example.com, and publish an A (and AAAA, if you send over IPv6) record for that hostname resolving back to the same IP. - Configure your mail server to greet with that exact same hostname in
HELO/EHLO, so the greeting name, the PTR, and the forward record all agree. - Confirm the loop closes:
dig -x <ip>returns the hostname, anddig <hostname>returns the IP. Then send a controlled test to a Gmail or Outlook account and re-check.
What this does not prove
A correct, forward-confirmed PTR that matches your HELO is necessary trust hygiene, not a guarantee of inbox placement. It removes one reason a receiver distrusts your IP. It does not by itself overcome a poor sending reputation, content that trips spam filters, or missing alignment in SPF, DKIM, and DMARC. A clean reverse-DNS check and a clean inbox are different outcomes.
Relaymetry publishes a reverse-DNS tool that reads the PTR and runs the forward-confirmation check from public DNS. What that check cannot do is set the PTR for you. The record lives with the network operator that owns the IP, so the actual change happens in your hosting provider's panel or ticket queue, not in your DNS zone.