Summary
Email Service Providers (ESPs) play a critical role in ensuring their clients' email deliverability. This hinges significantly on the correct implementation and maintenance of foundational technical elements like HELO, rDNS, and SPF. These protocols work in concert to verify the sender's identity, preventing spoofing and improving inbox placement. Best practices involve meticulous configuration and ongoing monitoring to ensure these records accurately reflect sending infrastructure and adhere to evolving internet service provider (ISP) requirements.
Key findings
- Order of checks: The SPF specification dictates that HELO checks are performed before MAIL FROM checks, reflecting the SMTP protocol flow.
- rDNS importance: rDNS (reverse DNS) verification ensures that the sending IP address resolves back to the HELO hostname, a crucial trust signal for receiving mail servers. This is further explained in our guide on reverse DNS resolution best practices.
- SPF DNS lookup limit: The SPF record must not exceed 10 DNS lookups to avoid PermError results, which can negatively impact deliverability.
- ESP identifier in headers: It is generally considered good engineering practice for ESPs to use their own rDNS for dedicated IPs and for the HELO value. This clearly identifies the sending server and the ESP responsible for it.
- Authentication with third-party senders: Proper SPF, DKIM, and DMARC configuration is essential when using multiple ESPs or third-party senders. More information can be found in our comprehensive guide on how email authentication affects deliverability with third-party ESPs.
Key considerations
- Consistent alignment: Ensure that the HELO domain, rDNS entry, and MAIL FROM domain are consistently configured and align, even if they reflect the ESP's domain rather than the client's. This helps to prevent SPF authentication failures, as highlighted by Webex Connect.
What email marketers say
Email marketers often grapple with the technical intricacies of email authentication, relying heavily on their ESPs to manage HELO, rDNS, and SPF. Their primary concern is often deliverability and maintaining a strong sender reputation, without necessarily diving into the granular technical details. They look for ESPs that handle these complexities seamlessly, especially when dealing with dedicated IPs and subdomains.
Key opinions
- Confusion over SPF specifics: Many marketers find the SPF specification, particularly the order of HELO and MAIL FROM checks, counter-intuitive or complex.
Key considerations
- Leveraging ESPs: Marketers should expect their ESPs to handle the complexities of rDNS and HELO configuration, especially for dedicated IPs. This allows marketers to focus on content and strategy, while the ESP ensures technical compliance for seamless transactional email delivery.
Marketer view
Email marketer from Email Geeks notes the initial confusion when reading the SPF specification, particularly the section discussing HELO checks appearing before MAIL FROM checks. This order can seem counter-intuitive to those accustomed to prioritizing the sender address.
Marketer view
Email marketer from HighLevel Support Portal explains that their guide helps users avoid the spam folder by landing emails in the inbox. This indicates a strong reliance on proper technical setup, including SPF and other authentication methods.
What the experts say
Email deliverability experts emphasize that while SPF may have historical quirks, its adherence to SMTP protocol order and its role in basic authentication remain crucial. They highlight the importance of rDNS (and PTR records) as a fundamental aspect of good engineering practice, especially for ESPs. Proper configuration of these elements is not just about avoiding blacklists (or blocklists) but also about providing clear accountability for email traffic. For more on how email authentication impacts deliverability, see our guide on DMARC, SPF, and DKIM.
Key opinions
- Historical context: The design of SPF, including the order of HELO and MAIL FROM checks, dates back to earlier authentication efforts where mail servers asserted their sending authority.
- rDNS as good practice: Using the ESP's rDNS and HELO values for dedicated IPs is considered sound engineering practice because it identifies the server's origin and the ESP's responsibility.
- Identity in headers: The HELO (or EHLO) command and corresponding rDNS provide the only location in the email headers that clearly identifies the sending server's identity, especially since the return-path may point to a bounce handler.
Key considerations
- Avoiding blocklists: Improper HELO configuration, particularly using it to signal unauthorized sending, can lead to inclusion on CSS (Composite Blocking List) or other blacklists (or blocklists), impacting deliverability for all traffic from that IP. Our in-depth guide to email blocklists provides more detail.
Expert view
Expert from Email Geeks explains that the order of HELO and MAIL FROM checks in SPF is intentional because it reflects the sequential nature of the SMTP conversation. The HELO command is issued first by the sending server, establishing its identity before the email transaction proceeds.
Expert view
Expert from SpamResource highlights that the foundation of email authentication relies on correctly identifying the sending server. This means that a properly configured HELO or EHLO value, which matches the rDNS of the sending IP, is a critical trust signal for receiving mail servers. Without this basic alignment, even SPF checks may be viewed with suspicion.
What the documentation says
Official documentation and industry standards provide the foundational rules for HELO, rDNS, and SPF. These documents outline the technical specifications that ESPs must adhere to for proper email authentication and reliable delivery. Key findings often revolve around the order of operations in SMTP and the strict limitations on DNS lookups for SPF validation. Understanding these guidelines is paramount for any email infrastructure, whether managed directly or through an ESP. We provide further insights on these topics in our detailed articles, such as how to set up DMARC, DKIM, and SPF.
Key findings
- SPF lookup limit: The SPF specification (RFC 7208) clearly limits the number of DNS lookups during SPF evaluation to a maximum of 10. Exceeding this limit results in a PermError, causing authentication failure.
- SMTP connection flow: According to SMTP protocol (RFC 5321), the HELO or EHLO command, which carries the sending hostname, is sent at the beginning of the session, prior to the MAIL FROM command.
- Reverse DNS (PTR) records: Documentation on rDNS emphasizes the necessity of a matching PTR record for the sending IP. This record maps an IP address back to a hostname and is a common check performed by receiving mail servers to verify sender legitimacy.
- Transactional email best practices: Official guides for transactional email emphasize setting up SPF records as a fundamental step to authenticate domains and signal legitimacy to mailbox providers. This foundational step is critical for avoiding spam folders and ensuring reliable delivery of time-sensitive emails.
Key considerations
- Regular updates: Documentation (e.g., from AutoSPF) advises regular review and updates of SPF records whenever there are changes to sending infrastructure or third-party ESPs. This is crucial for maintaining authentication effectiveness.
Technical article
Documentation from Mailgun states that SPF implementation must limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check. This is a critical technical constraint that ESPs and domain owners must adhere to in order to avoid authentication failures and ensure emails are delivered reliably.
Technical article
Documentation from Mutant Mail emphasizes the importance of regularly reviewing and updating all records related to email delivery, including MX records, SPF, and DKIM, as well as understanding the significance of rDNS and PTR records. This holistic approach ensures comprehensive email deliverability.
Related resources
12 resources
Related pages
What is the best practice for reverse DNS resolution when sending email via an ESP?
How to set up DMARC, DKIM, and SPF for emails from a web server and manage bounce responses?
A simple guide to DMARC, SPF, and DKIM
How do SPF, DKIM, DMARC, and dedicated IPs affect email deliverability when using a third-party ESP?
How to troubleshoot SPF authentication issues with multiple ESPs, subdomains, and CNAMEs?
Why your emails fail at Microsoft: the hidden SPF DNS timeout
Boost Email Deliverability Rates: Technical Solutions from Top Performing Senders
Demystifying the SPF TempError in your DMARC reports
Why Your Emails Fail: Expert Guide to Improve Email Deliverability [2025]
What is a DNSBL and how does it affect email deliverability?
