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 19 Aug 2025
7 min read
For Email Service Providers (ESPs), ensuring emails reach the inbox reliably is a constant challenge. Beyond content and list hygiene, the foundational technical aspects of email sending play a critical role. Among these, the proper configuration of HELO, rDNS, and SPF records is paramount for establishing trust with receiving mail servers and maintaining a positive sender reputation.
These three elements serve as digital identifiers, telling recipient servers who is sending the email and whether they are authorized to do so. Misconfigurations can lead to emails being marked as spam or outright rejected, impacting deliverability and potentially landing your IPs on a blacklist (or blocklist).
The HELO or EHLO command is one of the first interactions in an SMTP conversation, where the sending mail server introduces itself to the receiving server. This greeting typically includes the sending server's fully qualified domain name (FQDN).
An accurate HELO/EHLO is crucial as it's the first impression a sending server makes. Receiving servers often perform checks to verify that the domain presented in the HELO/EHLO command resolves back to the IP address of the connecting server. This initial verification helps establish legitimacy and can influence whether the connection is accepted or flagged as suspicious. As a general rule, the HELO/EHLO name should match the PTR record for the sending IP address.
For ESPs, it is common and often considered good engineering practice to use their own domain in the HELO string, even when clients are sending from dedicated IP addresses. This approach clearly identifies the server's origin and helps the ESP in diagnostics and accountability. It also provides a consistent identity for the ESP's infrastructure, which can be beneficial for reputation management.
However, inconsistencies between the HELO domain and the sending IP's PTR record or the email's "From" domain can lead to immediate rejections. Mail servers are configured to look for these alignments to prevent email spoofing and ensure that the sender is who they claim to be.
Mastering rDNS for email deliverability
Reverse DNS (rDNS) is the opposite of a standard DNS lookup. Instead of translating a domain name into an IP address, rDNS resolves an IP address back to a hostname, using a PTR (pointer) record. This record is crucial for email deliverability because many receiving mail servers perform rDNS lookups on the connecting IP address as a spam prevention measure.
If an email server's IP address lacks a valid PTR record, or if the PTR record does not match the HELO/EHLO hostname, it raises a red flag. This mismatch is a common characteristic of spam or malicious email. For instance, according to an article on ServerFault, a typical reverse DNS lookup verifies that the SMTP hostname provided in the EHLO/HELO command matches the PTR record.many anti-spam systems will penalize or reject mail from IPs without proper rDNS.
Best practices for ESPs include ensuring that all their sending IP addresses, whether shared or dedicated, have valid PTR records configured. These records should point to FQDNs that are consistent with the ESP's domain or a subdomain associated with the client's sending domain. This consistent setup is vital for maintaining a credible sender identity and improving inbox placement. You can learn more about this by reading about reverse DNS resolution best practices.
Proper rDNS setup
FQDN configured: Each sending IP has a PTR record that resolves to a fully qualified domain name (e.g., mail.your-esp.com).
Matching HELO: The HELO/EHLO greeting sent by the server matches its PTR record.
ESPs control PTR: ESPs typically manage PTR records for their IPs, even for dedicated IPs, to ensure consistency and accountability.
Common rDNS pitfalls
Missing PTR record: The sending IP has no PTR record at all.
Generic PTR: The PTR record is a generic ISP hostname or an automatically assigned one that doesn't reflect the sender.
Mismatch: The PTR record does not match the domain used in the HELO/EHLO command.
SPF records and their impact on authentication
SPF (Sender Policy Framework) is a DNS TXT record that lists all authorized mail servers permitted to send email on behalf of a particular domain. It's a critical email authentication method designed to detect sender spoofing.
When a receiving server gets an email, it checks the SPF record of the domain found in the "Mail From" (also known as "Return-Path" or envelope sender) address. It compares the sending IP address against the list of authorized IPs in the SPF record. If the IP is listed, the email passes SPF authentication. If not, it fails, significantly increasing the likelihood of the email being marked as spam or rejected.
ESPs and their clients must implement SPF records carefully. Key best practices include: ensuring the record is specific, listing all legitimate sending sources (including third-party services), and keeping it updated. You can also read our guide on what is the full form of SPF in email. A common pitfall is the "10-DNS lookup limit." Each mechanism in an SPF record that requires a DNS lookup (like `a`, `mx`, `ptr`, or `include`) counts towards this limit. Exceeding it results in a `PermError`, causing SPF validation to fail.
Exceeding the 10-DNS lookup limit in your SPF record can cause a `PermError`, leading to authentication failures and impacting deliverability. This often happens when multiple "include" mechanisms are used for various third-party services. Optimize your SPF record to stay within this limit.
Microsoft, for example, is known to enforce this limit strictly, leading to deliverability issues if not adhered to. Learn more about Microsoft's hidden SPF DNS timeout.
Holistic approach to email authentication
While HELO, rDNS, and SPF are crucial, they are components of a broader email authentication ecosystem that includes DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance). These protocols work in concert to provide comprehensive protection against spoofing and phishing, ultimately improving email deliverability. Companies like Google and Yahoo are increasingly making these authentication standards mandatory for bulk senders.
A key concept here is alignment. For DMARC to pass, either SPF or DKIM must align. SPF alignment means the domain in the "Mail From" header (Return-Path) matches the domain in the "From" header (visible sender). ESPs often use subdomains for the Return-Path, which requires careful configuration to ensure alignment with the customer's primary sending domain under DMARC.
Maintaining a strong sender reputation is an ongoing process. Even with perfect technical configurations, deliverability can suffer if your sending practices are poor or if your IPs end up on a blocklist. Continuous monitoring of your email deliverability, including DMARC reports and blocklist statuses (or blacklists), is essential. You can monitor your email program using a free email deliverability tester.
Component
Role in deliverability
Key best practice for ESPs
HELO/EHLO
Initial server greeting, establishes identity of the sending server.
Must match the IP's PTR record. Often ESP's own domain.
rDNS (PTR)
Resolves IP to hostname, verifies sender legitimacy.
Authorizes sending IPs for a domain, prevents spoofing.
Carefully configure for all sending IPs and third-party services, adhere to 10-DNS lookup limit.
Views from the trenches
Best practices
Ensure all elements of your email infrastructure (HELO, rDNS, SPF, DKIM, DMARC) are consistently configured and aligned.
Always set up a valid PTR record for every sending IP address that points to a fully qualified domain name.
Make sure your HELO/EHLO greeting matches the PTR record of the sending IP for initial server trust.
Regularly review and update your SPF records to include all legitimate sending sources and avoid exceeding the 10-DNS lookup limit.
Common pitfalls
Using generic PTR records from your ISP or having no PTR records at all for sending IPs.
Not aligning your HELO/EHLO hostname with your sending IP's PTR record, leading to immediate scrutiny.
Exceeding the 10-DNS lookup limit in your SPF record, resulting in a "PermError" and authentication failures.
Using overly broad SPF mechanisms like `+all` which can inadvertently authorize spammers to use your domain.
Expert tips
Monitor DMARC reports to identify authentication issues with HELO, rDNS, and SPF that might not be immediately apparent.
For ESPs, it is often beneficial to maintain control of the HELO/rDNS for their IPs, even dedicated ones, for better diagnostic capabilities.
Implement DMARC alongside SPF and DKIM to gain visibility into authentication failures and enforce policy.
Remember that email authentication is a continuous process requiring regular auditing and adjustments as your sending infrastructure changes.
Expert view
Expert from Email Geeks says the SPF specification, in its design, prioritizes HELO checks before evaluating MAIL FROM checks, which can sometimes be counter-intuitive to new implementers.
2019-09-12 - Email Geeks
Expert view
Expert from Email Geeks says the processing order for HELO/EHLO commands before MAIL FROM checks is the established protocol sequence within SMTP, making that the correct order for validation.
2019-09-12 - Email Geeks
Summary of best practices
For Email Service Providers, mastering HELO, rDNS, and SPF isn't just about adhering to technical standards; it's about building and maintaining the trust necessary for successful email delivery. These protocols are the bedrock of a healthy sender reputation, signaling to recipient servers that your emails are legitimate and safe.
By meticulously configuring and regularly auditing these technical elements, ESPs can significantly enhance their clients' email deliverability, reduce the likelihood of being flagged by spam filters or blocklisted (or blacklisted), and ultimately ensure that important messages consistently reach their intended inboxes.
