What do PTR and HELO records mean in relation to AT&T email blocking, and whose responsibility are they?

Key findings

• PTR Records: A PTR record, also known as a reverse DNS (rDNS) record, maps an IP address back to a hostname. It functions as a server's caller ID, verifying the sending IP address is associated with a legitimate domain name. This is a critical trust signal for recipient mail servers.
• HELO/EHLO Command: The HELO or EHLO command is the first step in an SMTP transaction, where the sending mail server introduces itself to the receiving server with its hostname. This name should ideally align with the PTR record for the sending IP.
• AT&T's Requirements: AT&T, like many other large ISPs, expects a match between the hostname presented in the HELO command and the hostname returned by a reverse DNS lookup (PTR record) of the sending IP. This consistency is a strong indicator of legitimate email sending practices. Understanding how AT&T handles filtering can help prevent blocks.
• Shared vs. Dedicated MTAs: For shared Mail Transfer Agents (MTAs), a generic PTR record might be considered acceptable by AT&T. However, for dedicated MTAs (which are often used by senders with high volume or specific reputation needs), AT&T explicitly advises that the PTR record should match the HELO hostname for optimal deliverability.

Key considerations

• ESP Responsibility: For most businesses, particularly those using an Email Service Provider (ESP), the responsibility for correctly configuring and maintaining PTR records and HELO settings falls squarely on the ESP. They manage the sending infrastructure, including the IP addresses and their associated DNS records. It is vital to clarify the division of responsibility between ESPs and businesses.
• Technical Alignment: Ensuring proper HELO and PTR record alignment is a fundamental part of email authentication and is crucial for avoiding blocks from major ISPs.
• Proactive Monitoring: Regularly checking the PTR records and HELO string of your sending IPs can help preempt deliverability issues. This is especially important if you are experiencing reverse DNS failure bounces from AT&T.
• ISP Communication: While an ISP might remove an immediate block, they may not always reveal the full extent of their filtering criteria. Persistent issues suggest deeper underlying problems that require ongoing investigation.

Key opinions

• Technical Jargon: Many marketers find the terminology around PTR records and HELO commands to be complex and confusing. They often rely on their ESP or a technical expert to translate and resolve these issues.
• ESP Accountability: There is a strong sentiment among marketers that the proper configuration of these records is the ESP's responsibility, as they manage the email sending infrastructure.
• Block Resolution: While getting a block removed is a priority, marketers often seek clarification on the root cause to prevent future occurrences, especially when initial explanations are vague or seemingly contradictory, such as when AT&T blocks emails without details.
• Underlying Issues: Some marketers suspect that ISPs might not always disclose the full range of reasons for a block, hinting at deeper, unrevealed filtering criteria beyond just PTR/HELO issues. This can be why AT&T email domains experience block bounces.

Key considerations

• Clear Communication: Marketers need to press their ESPs for clear, understandable explanations of technical issues and the steps being taken to resolve them.
• Escalation: If an ESP's initial response doesn't resolve the issue or provide sufficient clarity, marketers should not hesitate to escalate the problem within the ESP's support structure.
• Impact on Campaigns: Email marketers must understand that even seemingly small technical misconfigurations can have a large impact on campaign performance and overall deliverability, affecting critical metrics like open and click rates.
• ISP Feedback: While AT&T's responses can be cryptic, marketers should use any information provided by the postmaster to guide discussions with their ESP. Further insights can often be found by checking community forums or help documentation for other AT&T email issues.

Key opinions

• Defining PTR and HELO: Experts clearly define PTR as the record mapping an IP to a hostname (reverse DNS) and HELO as the hostname used by the sending MTA during the initial SMTP handshake. They stress that these two hostnames should ideally match.
• ESP Accountability: From an expert perspective, the responsibility for configuring and maintaining correct PTR and HELO records typically rests with the ESP, as they manage the IP infrastructure.
• ISP Filtering: Experts acknowledge that ISPs, including AT&T, use PTR and HELO consistency as a significant factor in their filtering decisions. A mismatch can trigger blocks, even if other authentication methods like SPF and DKIM are correctly implemented.
• Ambiguous Responses: Some experts find AT&T's specific response regarding shared versus dedicated MTAs to be somewhat unusual or incomplete, suggesting that there might be other undisclosed factors contributing to the blocks.

Key considerations

• Root Cause Analysis: While an immediate block removal is helpful, experts advise focusing on the underlying configuration issues. PTR records and HELOs impact deliverability significantly.
• Proactive Configuration: ESPs should proactively ensure that their sending IPs have proper PTR records that align with the HELO strings, especially for dedicated IP clients, following best practices for Email Service Providers.
• Reputation Impact: Inconsistent PTR and HELO settings can negatively affect sender reputation, leading to more frequent blocks or emails being sent to the spam folder, even if not explicitly blocklisted. Understanding PTR records for email is essential.
• Beyond Compliance: While compliance with basic technical standards is necessary, experts suggest that ISPs may employ additional, undisclosed heuristics for filtering. Therefore, senders should strive for overall excellent sending practices to avoid future issues.

Key findings

• RFC 5321 (SMTP): This foundational RFC for SMTP specifies that sending mail clients should identify themselves with a fully-qualified domain name (FQDN) in the HELO or EHLO command. It also implies that the reverse lookup of the sending IP address (PTR record) should correspond to this FQDN for proper identification.
• Trust and Authentication: Documentation often emphasizes that PTR records are a vital part of the overall email authentication process. They provide a reciprocal check to DNS 'A' records, verifying that the IP address used for sending email has a valid and expected reverse DNS entry, thereby building trust.
• Industry Best Practices: Organizations like the M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) consistently recommend that forward and reverse DNS records (PTR) match. This best practice helps to ensure good sending reputation and minimizes the chances of being caught by spam filters.
• Consistency for Deliverability: Multiple sources of documentation agree that consistent HELO and PTR records are critical factors for recipient servers to determine the legitimacy and trustworthiness of incoming email, directly influencing inbox placement.

Key considerations

• Adherence to Standards: Email senders and ESPs should strictly adhere to RFC standards and industry best practices regarding PTR and HELO configuration to ensure compliance with ISP requirements.
• DNS Management: The administration of PTR records is typically handled at the IP address level by the network or hosting provider (often the ESP for email sending IPs). PTR records are essential for deliverability.
• Preventing Blocks: Proper alignment of PTR and HELO is a preventative measure against blocks and blacklists. It signals to receiving mail servers that the sender is legitimate and not attempting to spoof their identity.
• Monitoring Tools: Utilizing tools to verify DNS records and server behavior (such as HELO/EHLO responses) is recommended to ensure ongoing compliance and prevent issues like reverse DNS failures from AT&T.