What is the best practice for reverse DNS resolution when sending email via an ESP?
Published 17 Apr 2025
Updated 23 Oct 2026
15 min read
Summarize with
Updated on 23 Oct 2026: We clarified ESP reverse DNS setup, Gmail PTR errors, and the evidence needed to troubleshoot delivery failures.
The best practice is straightforward: the IP address that connects to the recipient mail server needs a valid PTR record, and the PTR hostname should resolve forward to an address set that includes the original sending 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 works well 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: The PTR hostname's A or AAAA answers must include the original sending IP. This is forward-confirmed reverse DNS (FCrDNS).
- Useful match: Use the same fully qualified hostname for outbound HELO/EHLO and PTR where the ESP supports it. This is a best practice, not a DMARC requirement.
- Not required: The PTR does not need to be the same domain used in the visible From address.
Reverse DNS best practice for ESP sending
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 practical rule 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 an answer set containing the same IP. This two-way result is called forward-confirmed reverse DNS (FCrDNS). 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.
Gmail requires valid forward and reverse DNS for mail sent to personal Gmail accounts. Its sender guidelines FAQ lists 4.7.23 for temporary rate limiting and 5.7.25 for blocking when the sending IP has no PTR or the forward lookup does not include that IP. The connecting IP needs a PTR, and the PTR hostname needs the relevant A or AAAA record.
When ESP-owned rDNS is correct
ESP-owned rDNS is healthy when it is forward-confirmed and belongs to the sending infrastructure. A missing PTR or forward mismatch needs correction. An unfamiliar or dynamic-style hostname needs review with the ESP, but its appearance alone does not establish a DNS failure. The hostname can belong to the ESP's network provider rather than the ESP's customer-facing domain.
- Good: PTR exists, hostname is controlled by the ESP or sender, and forward DNS includes the sending IP.
- Better: PTR, forward DNS, and HELO/EHLO use the same sending hostname.
- Fix required: PTR is absent or its forward DNS omits the sending IP. Confirm unfamiliar hostname ownership separately.
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 that includes the sending IP.
Risky rDNS
- No PTR: The receiving server cannot map the IP to a hostname.
- Dynamic-style host: Ask the ESP whether the IP is a static outbound mail server; a hostname alone does not prove the address is dynamic.
- 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 includes the IP, and HELO is consistent.
Needs review
Review
PTR is forward-confirmed, but HELO is unrelated or the hostname looks dynamic.
Fix required
Fail
PTR is missing, NXDOMAIN, or forward DNS omits the sending 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 192.0.2.36, that is the value to test. When an application submits mail to an ESP over SMTP or an API, check the ESP IP that connects to the recipient, rather than the application server or website IP.
Flowchart for checking ESP reverse DNS from sending IP to PTR, forward DNS, HELO, and authentication.
On a command line, the PTR query gives the reverse hostname. The forward query confirms whether that hostname points back to the same address. host and nslookup work too. These examples use documentation addresses and hostnames; substitute the exact sending IP and the hostname returned by its PTR.
Manual rDNS checksbash
dig -x 192.0.2.36 +short dig mta536b.mail.example.net A +short dig mta536b.mail.example.net AAAA +short # Show DNS status when the short PTR query returns nothing dig -x 192.0.2.36 +noall +comments +answer +authority
A valid ESP-owned result can look like this. The hostname does not have to match the customer's From domain. It needs to belong to the mail system sending the message and have matching forward DNS.
Example PTR resultdns
36.2.0.192.in-addr.arpa. 299 IN PTR mta536b.mail.example.net.
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 shows a results button when the test is ready.
?/43tests passed
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.
NXDOMAIN or a successful response with no PTR answer means no PTR was returned. A timeout or SERVFAIL means the lookup failed; retry and investigate DNS availability before declaring the record absent. If PTR returns a hostname, run the matching A or AAAA lookup before calling it valid. In headers, use the Received entry written by the recipient's trusted inbound server to identify the public connecting IP. Earlier, untrusted Received entries are not reliable evidence of that connection.
IPv6 reverse DNS through an ESP
IPv6 needs its own reverse and forward DNS checks. If an ESP connects over IPv6, each outbound IPv6 address needs a PTR record, and the hostname returned by that PTR needs an AAAA answer containing the same IPv6 address. A valid IPv4 PTR and A record do not validate a separate IPv6 sending path.
- Confirm the route: Check received headers to see whether the ESP used IPv4 or IPv6 for the affected message.
- Query the IPv6 address: Run the PTR lookup against the exact public IPv6 address shown in the headers.
- Confirm the AAAA answer: The PTR hostname must resolve forward to an answer set that includes that IPv6 address.
- Escalate to the ESP: The ESP or IP-space owner must correct the PTR if the IPv6 reverse lookup is missing or mismatched.
IPv6 rDNS checksbash
dig -x 2001:db8::36 +short dig mta6.mail.example.net AAAA +short
Do not assume IPv4 results cover IPv6
Gmail's sending IP requirements explicitly cover IPv4 and IPv6. Test the address family that carried the message, and include that exact address in any ESP support ticket. A PTR failure on an IPv6 connection needs correction even when the same ESP has working IPv4 rDNS.
Shared IPs versus dedicated IPs
The right rDNS owner depends on the IP model. The organization that controls the IP address space controls the PTR zone. On shared pools, that is the ESP. On dedicated IPs assigned by an ESP, the ESP or its network provider still controls reverse DNS in many cases, but the ESP can often set a customer-specific hostname when the plan supports it.
Shared ESP IP
A shared IP normally uses one stable PTR hostname, and many senders use that IP. DNS permits multiple PTR records, but adding one for every customer is not a useful email configuration. The PTR should normally point at the ESP's mail hostname because it identifies 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 or network provider has to create 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 | ESP or network provider | ESP-owned rDNS is valid; branded rDNS is optional if supported. |
Self-hosted MTA | IP-space owner | Set PTR and HELO together. |
Cloud VM | Hosting provider | Request a static mail hostname. |
Dynamic ISP IP | ISP | Do not use it for production outbound mail. |
Recommended PTR ownership by sending model
For a dedicated sending IP, use one stable PTR hostname rather than several unrelated names. DNS can return multiple PTR records in some setups, but mail troubleshooting is clearer when each outbound IP has one predictable reverse identity.
Do not force branding on shared IPs
A customer-branded PTR on a shared pool creates confusion because the hostname would describe traffic for unrelated senders. If the brand needs custom rDNS, first confirm that the ESP supports it and that sending volume supports a dedicated IP. Branding alone is not a reason to expect better deliverability.
How to configure custom rDNS on a dedicated ESP IP
Custom rDNS needs coordinated changes by the domain DNS administrator and the ESP. Forward DNS and reverse DNS use separate zones, as explained in the reverse DNS zone documentation. Adding a PTR to your ordinary domain zone does not configure the ESP IP's public reverse lookup.
- Confirm support and choose a hostname. Ask the ESP which dedicated outbound IPs it will use and whether custom PTR and outbound EHLO are supported. Choose a stable fully qualified domain name (FQDN), such as mta1.example.com.
- Publish forward DNS first. For example, create an A record for mta1.example.com pointing to 192.0.2.36. For an active IPv6 sending address, create the corresponding AAAA record. Verify the public answers before requesting the PTR change.
- Have the ESP set the PTR. Give the ESP the exact IP and hostname. The ESP or network provider updates the authorized reverse zone, under in-addr.arpa for IPv4 or ip6.arpa for IPv6, unless reverse DNS control has been delegated to you.
- Coordinate outbound EHLO. Ask the ESP to use the same FQDN for the sending connection where supported. Checking the greeting banner on the ESP submission server does not reveal the EHLO used for delivery to recipients.
- Verify after the change. Allow cached DNS answers to expire according to their TTLs, repeat the reverse and forward lookups, then inspect a live message. Keep old forward records while any active sending IP still uses them as its PTR target, and recheck after IP migrations.
Where DMARC, SPF, DKIM, and reputation fit
rDNS is connection-level hygiene. It is separate from SPF, DKIM, and DMARC domain matching. A message can have ESP-owned rDNS and still pass DMARC when a passing SPF or DKIM domain matches the visible From domain under DMARC rules. 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 sender domain. For a null envelope sender, SPF uses the HELO/EHLO identity.
- DKIM: Checks whether the message has a valid cryptographic signature for the signing domain.
- DMARC: Checks whether a passing SPF or DKIM domain matches the visible From domain under DMARC rules.
- rDNS: Checks whether the connecting IP has a sensible reverse hostname with matching forward DNS.
Do not put ptr in an SPF record to make reverse DNS part of SPF authorization. RFC 7208 discourages that mechanism because it is slow and unreliable. Use the ESP's documented SPF authorization, such as ip4, ip6, or include. A PTR hostname that differs from the From domain does not by itself cause SPF failure. For an SPF rejection, check the actual connecting IP and envelope sender domain in the bounce. Do not change -all to +all to resolve it; +all authorizes every sending IP.
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
In Suped's DMARC reporting product, filter records by sending source or IP, then inspect SPF and DKIM results alongside the visible From domain. The Suped detail view also has rDNS diagnostics, so you can investigate the reported IP while keeping authentication results separate from PTR checks.
A practical workflow 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.
For a 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.
DMARC aggregate reports contain source IPs and authentication results, as defined in RFC 9990. A connection rejected before DMARC evaluation will not have a DMARC result to report. Use ESP delivery logs and live DNS lookups to investigate those failures; an absence of reported failures does not prove that every sending IP has working rDNS.
Operational checklist for ESP senders
When explaining this to a client, avoid arguing about whether the PTR should look branded. 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 that the IP returns a hostname. Investigate empty responses and review dynamic-looking names with the ESP.
- Confirm forward: Look up the PTR hostname and confirm its A or AAAA answers include the original IP.
- Compare HELO: Check that outbound HELO/EHLO is a valid sending hostname, ideally the same FQDN as PTR. A merely related name is not a technical validation.
- Check auth: Review SPF, DKIM, and DMARC separately before blaming reverse DNS.
- Open ticket: If PTR or forward confirmation fails, send the ESP the IP, address family, PTR hostname, forward result, sample timestamp, message ID, and full headers.
Check the HELO/EHLO sent by the outbound ESP server to the recipient. The SMTP greeting banner returned by a submission server is a different identity. RFC 5321 defines the EHLO hostname and server greeting separately; exact PTR equality is an operational recommendation rather than a universal SMTP requirement. 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.
What to send to the ESP
If the lookup fails, send the ESP a concise inventory of the affected sending source. Use one line per active sending IP so support can trace the right pool, dedicated IP, or route without guessing from the From domain alone.
ESP ticket formattext
IP address | address family | PTR hostname | forward DNS result | outbound EHLO | sending domain 192.0.2.36 | IPv4 | mta536b.mail.example.net | 192.0.2.36 | mta536b.mail.example.net | example.com
- Accepted mail: Include the destination server, acceptance timestamp with timezone, queue ID, recipient, and final response after message data. A 250 response at that stage confirms acceptance by that server, not inbox placement.
- Rejected mail: Include the full SMTP error and the ESP delivery log. A rejected message has no delivered copy at that recipient from which to collect headers.
- Missing mail: Explain that the sending logs show acceptance, then provide dates, subject samples, and message IDs.
- Authentication: Add SPF, DKIM, and DMARC results where available. For connection-stage rejections, these results are not always available because evaluation has not occurred.
The associated domain should be the customer-facing sending domain for the affected stream. If the mail uses a separate bounce domain, DKIM subdomain, or ESP tracking hostname, add those values as evidence without replacing the main sending domain in the ticket line.
Views from the trenches
Best practices
Check the PTR, outbound EHLO, 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 (blacklist) checks in the same regular review workflow.
Common pitfalls
Treating a shared ESP IP as broken solely because its PTR points to the ESP's own domain.
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 view
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 view
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
