How to fix DKIM failing due to apostrophe in From header at ATT.net?
Michael Ko
Co-founder & CEO, Suped
Published 9 Aug 2025
Updated 19 Aug 2025
7 min read
Dealing with email deliverability challenges can be complex, especially when specific mailbox providers introduce unexpected behaviors. We recently encountered a perplexing issue where emails sent to ATT.net recipients were failing DKIM authentication. The root cause? An apostrophe in the 'From' header, which led to header rewriting by the receiving server.
This rewriting process, while seemingly innocuous, invalidated the DKIM signature, resulting in DMARC failures and ultimately, bounced emails. For senders with a DMARC 'reject' policy, these bounces presented a significant hurdle to reliable communication. Given that SPF domain alignment wasn't an option for our setup, DKIM became the sole determinant for DMARC pass.
We observed that other major providers, like Gmail, performed similar header rewrites, yet DKIM and DMARC passed successfully. This discrepancy pointed to a unique handling by ATT.net and Yahoo's mail infrastructure. We dove into understanding why this happens and, more importantly, how to fix it.
Email headers are governed by specifications like RFC 5322. Our Java Mail implementation, specifically using the javax.mail.internet.InternetAddress class, adheres to this standard. According to the RFC, an apostrophe is considered part of an 'atext' character set, meaning it can appear in a display name without requiring double quotes. For example, emfluence's name should technically be valid as an unquoted display name.
However, the practical reality of email ecosystems often diverges from strict RFC compliance. Many mailbox providers implement their own interpretations or apply additional heuristics to sanitize email headers, particularly when they contain special characters or spaces. While our system was technically compliant, the behavior of receiving servers like ATT.net showed a different expectation.
When a display name includes a space or other characters that some parsers deem problematic, even if technically allowed by older RFC versions, mail servers tend to enclose the entire display name in double quotes. This is a common practice to ensure proper parsing and display across various email clients and systems.
The impact of header rewriting on DKIM
The core of the problem lies in how mail servers handle these 'non-standard but technically valid' 'From' headers. When ATT.net receives an email with an unquoted display name containing an apostrophe, it 'fixes' the header by wrapping the display name in double quotes. This modification happens *before* DKIM validation, effectively changing the message's byte stream.
DKIM (DomainKeys Identified Mail) works by creating a cryptographic signature of the email's headers and body. Even a slight change to these elements, like the addition of double quotes to the 'From' header, will invalidate the signature. This leads to a DKIM failure, which in turn causes DMARC (Domain-based Message Authentication, Reporting, and Conformance) to fail if there isn't a successful SPF (Sender Policy Framework) alignment.
In contrast, providers like Google (and some other ISPs) often add ARC (Authenticated Received Chain) headers when rewriting. While ARC is primarily designed for forwarding scenarios and preserving authentication results across intermediaries, its presence can sometimes indicate a more forgiving approach by the receiving server to initial authentication checks, or at least transparency about header modifications. ATT.net, however, does not add these headers, making its header modifications more impactful on DKIM.
Practical solutions for senders
The most effective solution is to proactively ensure your 'From' headers are formatted in a way that minimizes the chance of modification by intermediate mail servers. This means being super conservative with your header syntax. Even if technically correct according to RFCs, it's better to align with practical expectations of major mailbox providers.
The primary recommendation is to always wrap the display name portion of your 'From' header in double quotes, especially if it contains any characters beyond basic alphanumeric characters, including apostrophes, commas, or spaces. This prevents the receiving server from altering the header and invalidating the DKIM signature.
For those using Java Mail or similar libraries, you might need to explicitly instruct the library to quote the display name. While the default behavior might be RFC-compliant, it may not be practical for robust email deliverability across all providers. Review your email sending library's documentation for options to control 'From' header formatting.
This specific issue highlights a broader principle in email deliverability: the importance of strict adherence to widely accepted practices, even if they sometimes go beyond the minimum requirements of a technical specification. DKIM, in particular, is notoriously sensitive to even minor changes in the email content or headers. Any transformation by an intermediate server can easily break the signature.
For domains with a DMARC policy set to 'reject', authentication failures mean messages will not reach the inbox, impacting legitimate communications. Monitoring your DMARC reports is crucial to identify these types of issues promptly. Tools that provide insight into DMARC reports can pinpoint exactly why emails are failing, whether it's a DKIM body hash mismatch or header modifications. This particular problem results in a DKIM body hash failure since the header modification affects the signed content.
Ultimately, email deliverability is a moving target, constantly influenced by updates from mailbox providers and evolving spam countermeasures. Staying updated on best practices and proactively addressing potential issues like character handling in headers is essential for maintaining strong sender reputation and ensuring your emails reach their intended recipients. When in doubt, being conservative with your email formatting is often the safest bet to avoid unexpected authentication failures.
Views from the trenches
Best practices
Always wrap the display name in double quotes, even if characters like apostrophes are technically allowed unquoted.
Aim for conservative email header formatting that aligns with the broadest possible interpretation by mailbox providers.
Monitor your DMARC reports diligently to catch authentication failures caused by header modifications or other issues.
Ensure your DKIM setup is robust, as it's a critical component for DMARC success when SPF alignment isn't guaranteed.
Common pitfalls
Relying solely on RFC technical correctness without considering real-world mailbox provider interpretations.
Assuming that all mailbox providers will handle header rewrites in a DKIM-friendly way, like Google often does.
Overlooking special characters or spaces in the 'From' display name as potential causes for DKIM breakage.
Not having a DMARC policy that alerts you to these types of authentication failures (e.g., p=none or p=quarantine for reporting).
Expert tips
If a mailbox provider modifies a header, DKIM will fail; always ensure your headers remain byte-for-byte identical.
ARC headers indicate mail forwarding, not necessarily that the initial server was lenient with authentication.
The display name should ideally be formatted as a quoted string to prevent issues with various parsers.
DKIM is very fragile; strive for minimal header changes between sender and receiver for reliable validation.
Expert view
Expert from Email Geeks says senders are expected to quote or escape apostrophes in the From header to ensure proper delivery.
November 27, 2024 - Email Geeks
Expert view
Expert from Email Geeks says any mail with an invalid From header will be fixed up by the receiving server, which will then break the signature.
November 27, 2024 - Email Geeks
Ensuring email authentication success
The issue of DKIM failing due to apostrophes in the 'From' header at ATT.net, while seemingly specific, underscores a fundamental aspect of email deliverability: the crucial interplay between RFC standards and real-world implementation by mailbox providers. To ensure robust deliverability, especially when DMARC 'reject' policies are in place, proactive formatting of your 'From' headers to consistently use double quotes for display names is the most reliable approach.
This practice helps prevent unintended header modifications that invalidate DKIM signatures and lead to bouncebacks. By being conservative and aligning with the practical expectations of major email services, you can significantly improve your email authentication success rates and overall deliverability.
Gmail, performed similar header rewrites, yet DKIM and DMARC passed successfully. This discrepancy pointed to a unique handling by ATT.net and Yahoo's mail infrastructure. We dove into understanding why this happens and, more importantly, how to fix it.
Google (and some other ISPs) often add ARC (Authenticated Received Chain) headers when rewriting. While ARC is primarily designed for forwarding scenarios and preserving authentication results across intermediaries, its presence can sometimes indicate a more forgiving approach by the receiving server to initial authentication checks, or at least transparency about header modifications. ATT.net, however, does not add these headers, making its header modifications more impactful on DKIM.
