Summary
For optimal email deliverability and to maintain strong sender reputation, Email Service Providers (ESPs) must meticulously configure HELO/EHLO commands, reverse DNS (rDNS), and SPF records. The HELO/EHLO command should always present a Fully Qualified Domain Name (FQDN) that resolves to the sending IP, ideally aligning with the rDNS. A foundational requirement is that all sending IP addresses possess a valid rDNS record which resolves to an FQDN, and that FQDN, in turn, resolves back to the same IP-a crucial practice known as Forward-Confirmed Reverse DNS (FCrDNS). Furthermore, SPF is indispensable; ESPs are responsible for publishing comprehensive SPF records for their own sending domains and must also guide their clients on how to correctly update their domain's SPF records to explicitly authorize the ESP's sending infrastructure. Adhering to these integrated best practices is vital for establishing sender authenticity, preventing spoofing, and significantly minimizing the risk of emails being flagged as spam or rejected by recipient mail servers.
Key findings
- FQDN for HELO/EHLO: ESPs must use a Fully Qualified Domain Name (FQDN) in HELO/EHLO commands, ensuring it resolves to the sending IP and ideally aligns with the rDNS hostname for consistency and trust.
- FCrDNS as a Baseline: Forward-Confirmed Reverse DNS (FCrDNS), where the sending IP's PTR record resolves to an FQDN that also resolves back to the IP, is a fundamental requirement for all legitimate mail servers.
- Mandatory SPF Implementation: SPF is a critical authentication standard, requiring ESPs to publish comprehensive SPF records for their own sending domains and to ensure clients' SPF records authorize the ESP's sending infrastructure.
- Deliverability Consequences: Without proper HELO, rDNS, and SPF configurations, emails are highly likely to be marked as spam, throttled, or completely rejected by receiving mail servers.
- ESPs' Responsibility in Guidance: ESPs bear the responsibility for managing rDNS for their sending IPs and must provide clear instructions and support to clients for correctly updating their domain's SPF records.
- Consistency Aids Trust: Maintaining alignment between the HELO name and the rDNS hostname, along with consistent FCrDNS, is vital for building trust with recipient email systems.
- Engineering Rationale for ESP rDNS: Using the ESP's own hostname/rDNS in HELO, even for customer-authenticated IPs, is considered good engineering practice as it aids in diagnosis and clarifies the ESP's responsibility.
Key considerations
- Proactive FCrDNS Maintenance: ESPs should proactively monitor and maintain accurate Forward-Confirmed Reverse DNS (FCrDNS) for all dedicated and shared sending IPs, as this directly impacts deliverability and sender reputation.
- Client SPF Education: Providing comprehensive and easily understandable guidance to clients on how to properly add the ESP's 'include' directive or specific IP ranges to their domain's SPF record is crucial for client-side authentication.
- Consistency vs. Diagnostics: While HELO should ideally match rDNS, ESPs may sometimes use their own rDNS/HELO for diagnostic purposes or to clearly state responsibility, which is an acceptable engineering choice.
- Avoid Generic Identifiers: It is imperative to avoid using generic, invalid, or non-resolving names in HELO/EHLO commands to prevent immediate distrust from receiving servers.
- Understanding SPF Mechanics: ESPs should have a deep understanding of SPF mechanisms (e.g., 'a', 'mx', 'ip4', 'include', 'redirect') to correctly implement and troubleshoot authentication for their own infrastructure and their clients.
- Regular Configuration Audits: Implement a routine audit process for HELO, rDNS, and SPF configurations to ensure ongoing accuracy, consistency, and compliance with evolving industry best practices and receiving server requirements.
What email marketers say
11 marketer opinions
Email Service Providers (ESPs) play a crucial role in email deliverability, with their best practices for HELO/EHLO commands, reverse DNS (rDNS), and SPF records forming the bedrock of trust and authentication. A core principle is that the HELO/EHLO command should always present a Fully Qualified Domain Name (FQDN) that resolves to the sending IP, ideally matching the rDNS. For all sending IP addresses, a valid rDNS record is indispensable, resolving to an FQDN which then, in turn, resolves back to the same IP-a practice known as Forward-Confirmed Reverse DNS (FCrDNS). SPF is equally non-negotiable; ESPs must publish robust SPF records for their own sending infrastructure and diligently guide their clients to correctly update their domain's SPF records to authorize the ESP's sending servers. Adherence to these integrated practices ensures sender authenticity, thwarts spoofing, and significantly reduces the likelihood of emails being flagged as spam or outright rejected by recipient mail servers.
Key opinions
- FQDN for HELO/EHLO: ESPs must use a Fully Qualified Domain Name (FQDN) in HELO/EHLO commands, ensuring it resolves to the sending IP and ideally aligns with the rDNS hostname for consistency and trust.
- FCrDNS as a Baseline: Forward-Confirmed Reverse DNS (FCrDNS), where the sending IP's PTR record resolves to an FQDN that also resolves back to the IP, is a fundamental requirement for all legitimate mail servers.
- Mandatory SPF Implementation: SPF is a critical authentication standard, requiring ESPs to publish comprehensive SPF records for their own sending domains and to ensure clients' SPF records authorize the ESP's sending infrastructure.
- Deliverability Consequences: Without proper HELO, rDNS, and SPF configurations, emails are highly likely to be marked as spam, throttled, or completely rejected by receiving mail servers.
- ESPs' Responsibility in Guidance: ESPs bear the responsibility for managing rDNS for their sending IPs and must provide clear instructions and support to clients for correctly updating their domain's SPF records.
- Consistency Aids Trust: Maintaining alignment between the HELO name and the rDNS hostname, along with consistent FCrDNS, is vital for building trust with recipient email systems.
- Engineering Rationale for ESP rDNS: Using the ESP's own hostname/rDNS in HELO, even for customer-authenticated IPs, is considered good engineering practice as it aids in diagnosis and clarifies the ESP's responsibility.
Key considerations
- Proactive FCrDNS Maintenance: ESPs should proactively monitor and maintain accurate Forward-Confirmed Reverse DNS (FCrDNS) for all dedicated and shared sending IPs, as this directly impacts deliverability and sender reputation.
- Client SPF Education: Providing comprehensive and easily understandable guidance to clients on how to properly add the ESP's 'include' directive or specific IP ranges to their domain's SPF record is crucial for client-side authentication.
- Consistency vs. Diagnostics: While HELO should ideally match rDNS, ESPs may sometimes use their own rDNS/HELO for diagnostic purposes or to clearly state responsibility, which is an acceptable engineering choice.
- Avoid Generic Identifiers: It is imperative to avoid using generic, invalid, or non-resolving names in HELO/EHLO commands to prevent immediate distrust from receiving servers.
- Understanding SPF Mechanics: ESPs should have a deep understanding of SPF mechanisms (e.g., 'a', 'mx', 'ip4', 'include', 'redirect') to correctly implement and troubleshoot authentication for their own infrastructure and their clients.
- Regular Configuration Audits: Implement a routine audit process for HELO, rDNS, and SPF configurations to ensure ongoing accuracy, consistency, and compliance with evolving industry best practices and receiving server requirements.
Marketer view
Marketer from Email Geeks clarifies that the order of checks in SPF dates back to its predecessors. He explains SPF's compatibility with ESPs using customer subdomains and details why it is good engineering practice for ESPs to use their own hostname/rDNS in the HELO: it aids in diagnosis, clearly states the ESP's responsibility, and provides the only record of the sending server's identity.
19 Dec 2022 - Email Geeks
Marketer view
Marketer from Email Geeks explains that reverse lookup (checking an IP's PTR record against its hostname) is a valid process, and notes that while a "reverse SPF" concept has been discussed, it is not a standard.
23 Jul 2022 - Email Geeks
What the experts say
3 expert opinions
Ensuring optimal email deliverability hinges on Email Service Providers (ESPs) expertly managing several foundational protocols: HELO/EHLO commands, reverse DNS (rDNS), and SPF records. A core principle dictates that the HELO/EHLO string must be a Fully Qualified Domain Name (FQDN), ideally matching the reverse DNS of the sending IP address. Essential for deliverability, every IP address utilized for email transmission requires a precisely configured rDNS entry that resolves to a valid FQDN. Moreover, ESPs bear the dual responsibility of publishing robust SPF records for their own sending domains and providing clear guidance to their clients on how to correctly update their domain's SPF records to authorize the ESP's sending infrastructure. This comprehensive approach is vital for validating email origin and maintaining sender reputation.
Key opinions
- HELO/EHLO FQDN Alignment: ESPs should configure HELO/EHLO commands with a Fully Qualified Domain Name (FQDN) that ideally matches the reverse DNS of the sending IP for optimal deliverability.
- Universal rDNS Requirement: All IP addresses used by an ESP for sending mail must have a properly configured reverse DNS entry that resolves to a valid FQDN.
- ESP-Managed SPF: ESPs are responsible for publishing comprehensive SPF records for their own sending domains to authenticate their outgoing mail.
- Client SPF Guidance: ESPs must provide clear instructions and support to clients, enabling them to correctly update their domain's SPF records to include the ESP's authorized sending infrastructure.
- HELO/rDNS Consistency for Diagnosis: While ideal alignment is preferred, some ESPs may use their own rDNS and HELO values, even for customer-authenticated IPs, a practice that can aid in diagnosis and clarify responsibility.
Key considerations
- Prioritize FQDN and rDNS Match: ESPs should strive for a HELO/EHLO FQDN that consistently matches the sending IP's rDNS for maximum trust signals to receiving servers, which is a cornerstone of good deliverability.
- Comprehensive Client SPF Support: Beyond publishing their own SPF records, ESPs must offer detailed, user-friendly guidance to clients to ensure their SPF records correctly authorize the ESP's sending infrastructure.
- Strategic Use of ESP-Owned HELO/rDNS: ESPs might leverage their own rDNS and HELO values for diagnostic clarity, even when sending on behalf of clients with authenticated IPs, a practice observed as an acceptable engineering choice.
- Verification of All IP rDNS: Regular verification of rDNS entries for all sending IPs is critical to ensure they correctly resolve to valid FQDNs, a non-negotiable for reliable email deliverability.
- Proactive SPF Record Management: ESPs should proactively manage and update their SPF records, adapting to infrastructure changes and evolving authentication standards to maintain optimal sender reputation.
Expert view
Expert from Email Geeks explains that HELO often matches the IP's rDNS and may not always be consistent with the 5321.from domain. She observes that some ESPs, even with dedicated customer-authenticated IPs, continue to use their own rDNS and HELO values.
11 Jul 2022 - Email Geeks
Expert view
Expert from Word to the Wise explains that for optimal email deliverability, ESPs should ensure their HELO/EHLO string is a fully qualified domain name (FQDN) that ideally matches the reverse DNS of the sending IP address. Additionally, every IP address used for sending mail must have a correctly configured reverse DNS entry that resolves to a valid FQDN.
11 Apr 2025 - Word to the Wise
What the documentation says
4 technical articles
Email Service Providers (ESPs) maintain robust email deliverability and sender reputation by diligently managing their HELO/EHLO commands, reverse DNS (rDNS), and SPF records. A core principle is using a Fully Qualified Domain Name (FQDN) in HELO/EHLO that resolves accurately to the sending IP. Crucially, every sending IP address must have a valid reverse DNS (PTR) record that resolves to an FQDN, which then resolves back to the original IP, a process known as Forward-Confirmed Reverse DNS (FCrDNS). Additionally, ESPs are responsible for publishing comprehensive SPF records to authorize their sending infrastructure and must guide their clients to correctly update their domain's SPF records to include these authorized sending IPs. These integrated authentication protocols are fundamental for establishing sender authenticity, preventing email spoofing, and significantly reducing the likelihood of messages being flagged as spam or rejected by recipient servers.
Key findings
- HELO/EHLO FQDN: ESPs must present a Fully Qualified Domain Name (FQDN) in their HELO/EHLO commands that correctly resolves to the sending IP address.
- FCrDNS Essential: All sending IP addresses require valid Forward-Confirmed Reverse DNS (FCrDNS) records, where the PTR record resolves to an FQDN that also resolves back to the original IP. This is crucial for reputation and deliverability.
- ESPs' SPF Responsibility: Email Service Providers are mandated to publish robust SPF records that authorize their own sending IPs to prevent spoofing and validate authenticity.
- Client SPF Enablement: ESPs are responsible for guiding clients on how to correctly update their domain's SPF records to include the ESP's sending infrastructure, detailing relevant mechanisms.
- Rejection Risk: Failure to adhere to proper HELO, rDNS, and SPF configurations leads to a high likelihood of emails being throttled, blocked, or delivered to spam folders by major receivers.
Key considerations
- Maintain FCrDNS Accuracy: Proactive and continuous maintenance of accurate Forward-Confirmed Reverse DNS (FCrDNS) records for all sending IPs is paramount for consistent deliverability and positive sender reputation.
- Educate Clients on SPF: Offer comprehensive and easy-to-follow guidance to clients for configuring their SPF records, especially regarding the 'include' mechanism for authorizing the ESP's infrastructure.
- Align HELO and rDNS: Strive for the HELO/EHLO FQDN to align with the sending IP's rDNS hostname, as this consistency builds trust with recipient mail servers and aids in diagnostics.
- Master SPF Specifications: ESPs should possess expert knowledge of SPF mechanisms and how they are processed by receiving servers to effectively manage and troubleshoot authentication for both their own domains and client domains.
- Conduct Regular Audits: Implement routine checks of HELO, rDNS, and SPF configurations to guarantee ongoing compliance with evolving industry standards and prevent potential deliverability issues.
Technical article
Documentation from M3AAWG Sender Best Current Practices explains that ESPs and other senders should use a Fully Qualified Domain Name (FQDN) in their HELO/EHLO commands that resolves to the sending IP. The sending IP must have a valid reverse DNS (PTR record) that resolves to an FQDN, which in turn resolves back to the same IP (FCrDNS). Additionally, senders must publish SPF records to authorize their sending IPs, helping to prevent spoofing.
27 Apr 2025 - M3AAWG Sender Best Current Practices
Technical article
Documentation from Google emphasizes that for ESPs, the sending domain used in HELO/EHLO commands must have a valid A or AAAA record. It states that having a valid PTR record (rDNS) for the sending IP that resolves to a FQDN, which then resolves back to the IP, is crucial for sender reputation. Furthermore, ESPs must ensure SPF records are published to include all servers sending mail for their domain.
26 Feb 2024 - Google Workspace Admin Help
Do PTR records and HELOs impact email deliverability?
What are common misconceptions and best practices regarding SPF records and email deliverability for small mail servers?
What are the best practices for email deliverability when using SparkPost and Amazon SES, including reverse DNS, blacklist monitoring, and handling dedicated IPs?
What are the best practices for PTR records and domain alignment in email sending?
What are the best practices for setting up SPF, DKIM and DMARC for email authentication?
What is the best practice for reverse DNS resolution when sending email via an ESP?
