What is the best practice for reverse DNS resolution when sending email via an ESP?
Matthew Whittaker
Co-founder & CTO, Suped
Published 17 Apr 2025
Updated 14 May 2026
8 min read
Summarize with
The best practice is straightforward: the IP address that connects to the recipient mail server needs a valid PTR record, and that PTR hostname should resolve forward to the same IP. When you send through an ESP, that hostname often belongs to the ESP, especially on shared IP pools. It does not need to match your visible From domain or your DMARC organizational domain.
If you have a dedicated IP, a branded hostname under your sending domain can be a good choice when the ESP supports it. If you are on shared IPs, ESP-owned rDNS is normal and expected. The operational requirement is a consistent, forward-confirmed hostname that the sending infrastructure controls.
- Shared IPs: The PTR usually points to the ESP's domain, such as an ESP mail host.
- Dedicated IPs: Use a branded hostname if the ESP can set it and the hostname points back to the IP.
- Required match: PTR should match forward DNS for the host returned by the reverse lookup.
- Useful match: The HELO or EHLO hostname should match, or at least be clearly related to, the PTR hostname.
- Not required: The PTR does not need to be the same domain used in the visible From address.
The direct best practice
Reverse DNS starts with the sending IP address, not with the sender's domain name. That sounds obvious until you inspect a real message: headers contain a visible From domain, a Return-Path domain, DKIM signing domains, tracking domains, and the connecting IP. The rDNS question only concerns the connecting IP.
The rule I use is simple: find the IP that delivered the message, query the PTR for that IP, then confirm the hostname returned by the PTR resolves forward to the same IP. If the SMTP transcript or headers show the HELO/EHLO hostname, compare that too. For more background on why this matters, see reverse DNS matters.
Short answer
ESP-owned rDNS is healthy when it has forward-confirmed DNS and belongs to the platform actually sending the message. A shared ESP IP resolving to the ESP's hostname is not a defect. A missing PTR, generic cloud hostname, NXDOMAIN result, or forward mismatch is the real issue.
- Good: PTR exists, hostname is controlled by the ESP or sender, and forward DNS confirms the IP.
- Better: PTR, forward DNS, and HELO/EHLO all use the same sending hostname.
- Bad: PTR is absent, points to an unrelated host, or resolves forward to a different address.
Healthy rDNS
- Shared pool: The PTR points to the ESP's mail hostname.
- Dedicated IP: The PTR uses either the ESP's hostname or a branded sender hostname.
- Forward check: The PTR hostname has an A or AAAA record pointing back to the sending IP.
Risky rDNS
- No PTR: The receiving server cannot map the IP to a hostname.
- Generic host: The hostname looks like unmanaged cloud infrastructure.
- Forward fail: The hostname returned by PTR does not resolve back to the sending IP.
rDNS risk levels
Use these thresholds to decide whether the rDNS result needs action.
Low risk
Pass
PTR exists, forward DNS confirms the IP, and HELO is consistent.
Needs review
Review
PTR exists, but HELO is unrelated or the hostname looks generic.
Fix required
Fail
PTR is missing, NXDOMAIN, or forward DNS does not confirm the IP.
How to check rDNS correctly
The common mistake is checking the sender domain first. Reverse DNS is an IP lookup. If a message came from 35.166.226.36, that is the value to test. If you only test the visible domain, you are testing the wrong thing.
Flowchart showing how to check rDNS for an ESP-sent email.
On a command line, the basic sequence looks like this. The PTR query gives the reverse hostname. The forward query confirms whether that hostname points back to the same address.
Manual rDNS checksbash
dig -x 35.166.226.36 +short dig mta536b.sparkpostmail.com A +short dig mta536b.sparkpostmail.com AAAA +short
A valid ESP-owned result can look like this. The important part is not that the hostname matches the customer's From domain. The important part is that the hostname belongs to the mail system sending the message and has matching forward DNS.
Example PTR resultdns
36.226.166.35.in-addr.arpa. 299 IN PTR mta536b.sparkpostmail.com.
For live mail, send one message through the same ESP stream and inspect the received headers with an email tester. That confirms which IP was used, which authentication results passed, and whether the message path matches the configuration you expected.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
The tester gives context, but still verify the IP. Large ESPs use multiple pools, and a single account can send through different IPs for transactional mail, marketing mail, regional routing, or warmup streams. If the result looks inconsistent, check the headers for the exact message that failed.
Shared IPs versus dedicated IPs
The right rDNS owner depends on the IP model. On shared pools, the ESP owns the infrastructure and sets the PTR. On dedicated IPs, the ESP still controls the address space in many cases, but they can often set a customer-specific hostname if the plan supports it.
Shared ESP IP
A shared IP has one PTR record, but many senders use that IP. The PTR should normally point at the ESP's mail hostname, because that hostname describes the infrastructure.
- Branding: Do not expect the PTR to use one customer's domain.
- Control: The ESP manages the PTR and HELO behavior.
Dedicated ESP IP
A dedicated IP can use a branded hostname when the ESP supports custom rDNS. This is useful for senders that want cleaner infrastructure naming and stable operational ownership.
- Branding: Use a subdomain such as a mail or mta hostname.
- Control: The ESP still has to create or request the PTR change.
If a client asks why a shared ESP IP does not resolve to their domain, the answer is ownership. A shared IP cannot fairly present one customer's hostname as the reverse identity for everyone else using that same address.
|
|
|
|---|---|---|
Shared ESP pool | ESP | Use the ESP hostname. |
Dedicated ESP IP | Brand or ESP | Use branded rDNS if supported. |
Self-hosted MTA | Sender | Set PTR and HELO together. |
Cloud VM | Sender | Avoid generic hostnames. |
Recommended PTR ownership by sending model
Do not force branding on shared IPs
A customer-branded PTR on a shared pool creates confusion because one reverse hostname would describe traffic for unrelated senders. If the brand needs its own rDNS, move to a dedicated IP and ask the ESP whether custom PTR and matching HELO are supported.
Where DMARC, SPF, DKIM, and reputation fit
rDNS is connection-level hygiene. It is not SPF, DKIM, or DMARC domain matching. A message can have ESP-owned rDNS and still pass DMARC if SPF or DKIM uses a domain that matches the visible From domain. A message can also have branded rDNS and still fail authentication if SPF or DKIM is wrong.
- SPF: Checks whether the sending IP is authorized for the envelope domain.
- DKIM: Checks whether the message has a valid cryptographic signature.
- DMARC: Checks whether SPF or DKIM uses a domain that matches the visible From domain.
- rDNS: Checks whether the connecting IP has a sensible reverse hostname.
I keep these checks separate because they answer different questions. If the domain has poor authentication, fix SPF, DKIM, and DMARC. If the connecting IP has no PTR, ask the ESP or hosting provider to fix rDNS. If mail is blocked after authentication passes, check IP and domain reputation, including blocklist and blacklist status.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product is useful when a single rDNS question turns into a broader authentication review. It brings DMARC, SPF, DKIM, rDNS diagnostics, and sender source visibility into one workflow, so the fix is not buried in raw DNS output. For most teams, Suped is the best overall DMARC platform when they need practical monitoring, alerts, and clear steps to fix.
The workflow I prefer is to first validate the exact message path, then use DMARC monitoring to confirm authentication at scale. If reputation is part of the complaint, add blocklist monitoring so IP and domain listings do not get missed.
If you want one broad DNS and authentication check before opening a ticket with the ESP, run the domain through a domain health checker. It will not replace the IP-level rDNS lookup, but it quickly shows whether other authentication records are also contributing to the issue.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The practical point is that rDNS should not be treated as a branding rule. It is one signal among several. A clean PTR does not rescue broken authentication, and strong DMARC does not excuse a missing PTR on the connecting IP.
Operational checklist for ESP senders
When I need to explain this to a client, I avoid arguing about whether the PTR should look branded. I walk through the observable checks instead. That keeps the conversation grounded in what receiver filters can evaluate.
- Find the IP: Use the Received headers from the specific message that had the problem.
- Query PTR: Confirm the IP returns a hostname instead of no result or a generic placeholder.
- Confirm forward: Look up the PTR hostname and confirm it resolves to the same IP.
- Compare HELO: Check whether the SMTP hostname matches or is clearly related to the PTR.
- Check auth: Review SPF, DKIM, and DMARC separately before blaming reverse DNS.
- Open ticket: If PTR or forward confirmation fails, ask the ESP to fix the sending IP setup.
HELO does not always appear in the user-facing parts of a message, but it matters enough to check when you are dealing with hard bounces, receiver-specific deferrals, or a dedicated IP migration. For a deeper comparison, see HELO and rDNS.
The client-ready explanation
For shared ESP sending, it is correct for reverse DNS to resolve to the ESP's hostname. For dedicated IP sending, branded rDNS is acceptable when forward DNS and HELO are configured correctly. The receiver cares that the IP has a trustworthy, consistent identity, not that the PTR repeats the From domain.
Views from the trenches
Best practices
Check the PTR, SMTP banner, and forward lookup together before blaming the ESP's setup.
Use a dedicated IP when the brand needs its own rDNS hostname and volume supports it.
Keep SPF, DKIM, DMARC, and blocklist monitoring in the same review workflow weekly.
Common pitfalls
Treating a shared ESP IP as broken because the PTR points at the ESP domain alone.
Looking up rDNS by domain first, instead of querying the actual connecting IP address.
Changing PTR hostnames without checking forward confirmation and HELO behavior first.
Expert tips
Ask the ESP which hostname they use for HELO before requesting any PTR change on an IP.
Use message headers to find the sending IP that receiver filters actually evaluated.
Separate branding goals from authentication checks, since rDNS is not a DMARC domain match.
Marketer from Email Geeks says reverse DNS should be checked against the actual connecting IP, because looking up the sender domain gives the wrong answer.
2019-04-24 - Email Geeks
Expert from Email Geeks says an ESP-owned PTR on a shared sending IP is normal and does not create a problem by itself.
2019-04-24 - Email Geeks
The practical rule
The best practice for rDNS through an ESP is valid, forward-confirmed reverse DNS for the connecting IP. On shared IPs, that normally means the ESP's hostname. On dedicated IPs, it can mean a branded sender hostname if the ESP supports custom PTR and the forward lookup confirms the same IP.
I would not reject a setup because the PTR resolves to the ESP. I would reject it if the PTR is missing, generic, unrelated, or not forward-confirmed. After that, I would check SPF, DKIM, DMARC, HELO, and blocklist or blacklist status before making a deliverability claim.
