What are the best practices for Email Service Providers regarding HELO, rDNS, and SPF?
Matthew Whittaker
Co-founder & CTO, Suped
Published 2 Jun 2025
Updated 15 May 2026
10 min read
Summarize with
The best practice for an email service provider is to use a stable, fully qualified HELO name controlled by the ESP, set reverse DNS for each sending IP to that same operational hostname, make the hostname forward-resolve back to the sending IP, and publish SPF that authorizes both the customer return-path domain and the HELO identity used for null senders. I do not treat HELO, rDNS, and SPF as interchangeable checks. They answer different questions, and receivers use all of them to decide whether the connection looks traceable, authorized, and consistent.
- HELO: Use a real FQDN, not a customer marketing domain, not a bare domain, and not a temporary host label.
- rDNS: Point the IP's PTR record to the sending host, then make that host resolve back to the same IP.
- SPF: Authorize the envelope sender domain for customer mail and the HELO domain for bounce and null-sender cases.
- DMARC: Use SPF and DKIM results on customer-owned domains to pass DMARC for the visible From domain.
For dedicated IPs, I still prefer ESP-owned HELO and rDNS names in most cases. The ESP operates the MTA, handles abuse reports, controls routing, and needs the hostname to identify the cluster or region that sent the message. Customer-branded rDNS has a place in narrow enterprise requirements, but it creates more operational risk than value when it hides who runs the server.
How the checks fit together
The confusing part is that the checks arrive in SMTP order, not in the order most marketers think about authentication. The receiver sees the connecting IP first, then the HELO or EHLO name, then the envelope sender in MAIL FROM, then the message headers. That is why SPF includes a HELO identity check before the MAIL FROM check. The HELO name exists before the receiver knows the envelope sender.
Google's current sender requirements also push senders toward authenticated, traceable mail. The Google sender guidelines call for SPF or DKIM authentication, DMARC for bulk senders, and valid forward and reverse DNS for sending IPs. That does not mean rDNS passes DMARC. It means receivers care about connection identity before they even parse the message body.
|
|
|
|
|---|---|---|---|
HELO | MTA host | Stable FQDN | No direct pass |
rDNS | IP owner | Forward-confirmed | Trust signal |
SPF | Return path | Authorized sender | Passes if matched |
DKIM | Signing domain | Customer domain | Passes if matched |
A compact map of the identities receivers inspect during SMTP and message authentication.
A clean setup makes each identity obvious. The HELO name says which machine or cluster connected. rDNS proves the IP points at that same host. SPF proves the envelope sender or HELO domain authorizes the IP. DKIM signs the customer domain so DMARC has a second route to pass when SPF uses a bounce subdomain.
Infographic showing the receiver path through IP, HELO, rDNS, SPF, and DMARC checks.
Best practice answer for ESPs
The short answer is that the ESP should use its own operational hostname for the SMTP server identity, while the customer should control the envelope sender and DKIM domains used for DMARC. Trying to make every layer look like the customer domain creates fragile routing and weak incident response. I want the header trail to show the truth: this customer sent through this provider, on this host, using this IP.
That distinction matters most on dedicated IPs. A dedicated IP gives the customer a separate reputation pool, but it does not make the customer the operator of the mail server. The ESP still controls the MTA, queue behavior, TLS settings, bounce handling, complaint routing, and emergency suspension. The hostname should help the ESP and receiving networks diagnose issues quickly.
Good operational identity
- Ownership: The ESP domain appears in HELO and PTR records.
- Traceability: The hostname identifies the sending pool, region, or MTA group.
- Diagnostics: Receivers can report the exact host that caused the issue.
- Control: DNS changes stay with the team that operates the mail server.
Risky customer branding
- HELO misuse: The customer domain is used as the server name.
- PTR drift: Reverse DNS changes depend on customer branding requests.
- Harder abuse work: The real operator is less obvious in headers and logs.
- Higher listing risk: Policy blocklists and blacklists dislike misleading host identity.
I separate branding and accountability. The customer brand belongs in the visible From address, DKIM signing domain, custom return-path domain, and tracked links. The ESP's accountability belongs in HELO, rDNS, Received headers, abuse contacts, and operational hostnames.
Do not use HELO as customer branding
A customer domain in HELO does not make mail more authenticated. It makes the sending server identity less clear. Receivers already have better places to evaluate the customer domain: SPF on the return-path domain, DKIM on the signing domain, and DMARC on the visible From domain.
How to configure HELO and rDNS
For HELO, I use a hostname that exists in public DNS, has an A or AAAA record, and belongs to the ESP's domain. I avoid using a root domain, a customer domain, or a name that changes every deployment. The hostname can include a region or pool code, but it should stay readable in headers.
For rDNS, I expect forward-confirmed reverse DNS. That means the IP's PTR record points to the HELO hostname, and that hostname resolves back to the same IP. If you want a deeper treatment of PTR behavior, the sibling notes on PTR and HELO impact and reverse DNS setup cover the edge cases in more detail.
Forward-confirmed rDNS exampleDNS
HELO: mta01.use1.mailer.example IP: 203.0.113.25 mta01.use1.mailer.example. 300 IN A 203.0.113.25 25.113.0.203.in-addr.arpa. 300 IN PTR mta01.use1.mailer.example.
One PTR record per sending IP is the cleanest default. Some DNS providers allow multiple PTR records, but many receivers and diagnostic tools expect one clear answer. Multiple names also make incident reports harder to read because different tools can show different PTR values for the same IP.
- FQDN: Use a complete hostname such as mta01.use1.mailer.example, not localhost or a bare domain.
- Forward match: The PTR target should resolve back to the sending IP over the address family used.
- Stable naming: Do not rotate hostnames as part of routine queue movement or customer onboarding.
- Abuse handling: Make the ESP operator clear enough that receivers know who can fix bad traffic.
How SPF should work
For SPF, the main customer-facing goal is simple: the domain in the envelope sender should authorize the ESP's sending infrastructure. In modern ESP setups, that usually means the customer creates a return-path subdomain such as bounce.example.com, then publishes an SPF record or CNAME path that lets the provider manage the exact sending sources.
The HELO domain also needs SPF coverage. That matters for null senders, delivery status notifications, and receivers that check HELO SPF early. It does not replace SPF on the customer's envelope sender. It is a separate sender identity.
SPF records for return path and HELODNS
bounce.example.com. 300 IN TXT "v=spf1 include:spf.mailer.example -all" mta01.use1.mailer.example. 300 IN TXT "v=spf1 ip4:203.0.113.25 -all"
SPF breaks in predictable ways. It exceeds the 10 DNS-lookup limit, includes abandoned senders, uses mechanisms that pull in too many hosts, or authorizes a root domain more broadly than intended. Before a production cutover, I validate the record with an SPF checker and then confirm the actual header results with a real test message.
SPF lookup budget
A practical way to think about the SPF 10 DNS-lookup limit before a record reaches permerror territory.
Healthy
0-5
Enough room for provider changes and nested includes.
Watch
6-8
Review nested includes before adding another sender.
High risk
9-10
One provider change can push the record into permerror.
Failing
11+
Receivers can return SPF permerror.
I avoid SPF macros unless there is a very specific provider design that demands them. They are hard to reason about, hard to test at scale, and hard for customers to debug. If a normal include, hosted SPF record, or return-path subdomain solves the problem, that is the cleaner path.
Amazon SES console showing DKIM and custom MAIL FROM settings for a verified domain.
How to test the finished setup
DNS validation catches record syntax. A real message catches the actual identity path. I test both because ESP mail often looks correct in DNS but fails in headers because the return-path domain, DKIM domain, or sending pool differs between staging and production.
My test starts by sending mail through the same route customers use. Then I inspect Received headers, Authentication-Results, envelope sender, DKIM signature domain, SPF result, DMARC result, and the PTR record for the connecting IP. A good email tester should show the difference between a DNS record that exists and a message that actually authenticates.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
After that, I run a broader domain check. The domain health checker is useful when I want one view of DMARC, SPF, and DKIM status before I look at live traffic. That catches missing TXT records, weak DMARC policy, and obvious SPF lookup problems before they turn into campaign failures.
The last check is reputation. If a sending pool has generic rDNS, mismatched HELO, or a history of noisy customers, the problem can show up as blocklist or blacklist pressure before it shows up as a clean authentication failure. That is where ongoing blocklist monitoring helps separate DNS mistakes from reputation damage.
Header checks I care about
- Received line: Confirms the connecting IP and the hostname the receiver saw.
- SPF result: Shows whether the envelope sender or HELO identity authorized the IP.
- DKIM domain: Shows whether the customer domain has a valid cryptographic signature.
- DMARC result: Shows whether SPF or DKIM passed using a domain tied to the visible From.
Where Suped fits
Suped is relevant once the DNS design moves into production. A single test message tells you whether one route works now. DMARC reports tell you which providers, IPs, and domains are actually sending over time. That is the evidence I use to catch an ESP route that authenticates one campaign but fails another.
In Suped's product, the practical workflow is to monitor DMARC sources, verify SPF and DKIM outcomes, watch for unverified senders, and use issue detection to get specific fix steps. For most teams, Suped is the best overall DMARC platform because it joins DMARC monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, real-time alerts, blocklist monitoring, and multi-tenant reporting in one place.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The important part is not a prettier report. It is being able to connect a failed source to the DNS record, the sending IP, the provider, and the fix. That matters when an ESP changes a sending pool, a customer adds a new tool without updating SPF, or a return-path domain points at the wrong provider.
- Issue detection: Suped flags authentication problems and gives steps to fix the underlying record or sender setup.
- Hosted SPF: Suped can host and flatten SPF so teams stay under lookup limits without constant DNS edits.
- Alerts: Real-time alerts help catch authentication drops instead of waiting for a weekly review.
- MSP scale: The multi-tenant dashboard keeps many domains and clients visible without spreadsheet tracking.
Views from the trenches
Best practices
Use one stable HELO name per MTA or cluster, and make its forward DNS match the IP.
Keep PTR records under the ESP domain unless a customer has a clear operational need.
Publish HELO SPF for null senders and keep SPF focused on the return-path domain.
Common pitfalls
Using customer branding in HELO hides the operator and makes abuse investigation slower.
Treating rDNS as reverse SPF creates false confidence because PTR does not authorize mail.
Letting SPF records grow without lookup budgets causes permerror during major campaigns.
Expert tips
Put cluster and region hints in hostnames, but avoid customer names in server identity.
Test with a real message because DNS can look correct before headers reveal failure.
Track DMARC reports after each DNS change, not only the SPF checker output for a week.
Marketer from Email Geeks says HELO checks arrive before MAIL FROM checks because SMTP gives the receiver the HELO name first.
2024-02-08 - Email Geeks
Marketer from Email Geeks says reverse DNS should match the hostname and that hostname should resolve back to the connecting IP.
2024-02-09 - Email Geeks
The practical bottom line
The best ESP setup is honest and easy to investigate. Use ESP-owned HELO and rDNS for the machine identity. Use customer-controlled return-path and DKIM domains for customer authentication. Keep SPF tight, keep PTR and forward DNS consistent, and verify the result with real mail, not only with DNS lookups.
When those pieces are in place, receivers can see who operated the server, which customer domain authorized the mail, and whether DMARC passed. That is the setup I trust for shared pools, dedicated IPs, and high-volume customer mail because it balances deliverability, accountability, and practical operations without hiding the ESP's role.
