How to fix DKIM failing due to apostrophe in From header at ATT.net?

Key findings

• Header modification: When an apostrophe is present in the display name portion of the 'From' header (e.g., 'emfluence's name'), ATT.net's servers often rewrite it by enclosing the entire name in double quotes (e.g., "emfluence's name").
• DKIM invalidation: This server-side rewriting changes the header in a way that breaks the original DKIM signature, leading to authentication failure.
• DMARC impact: For domains with a DMARC policy of 'reject', DKIM failure results in messages being bounced, indicating they were 'not accepted for policy reasons'.
• RFC 5322 interpretation: While technically an apostrophe is an 'atext' character in RFC 5322, suggesting it might not require quoting, the presence of spaces makes it a 'phrase' that often needs to be a 'quoted-string'.
• Gmail vs. ATT.net: Gmail handles similar header rewriting without DKIM failure, possibly due to the inclusion of ARC headers or more forgiving authentication processes compared to ATT.net.

Key considerations

• Sender responsibility: Despite potential ambiguities in RFC interpretation, the consensus is that it is the sender's responsibility to format headers to ensure broad compatibility and authentication success. Our article on what RFC 5322 says vs. what actually works delves deeper into this.
• Conservative formatting: To prevent DKIM failures, it is highly recommended to proactively wrap display names containing apostrophes, spaces, or other unusual characters in double quotes. This eliminates ambiguity for diverse mail servers.
• Software library behavior: If using a mail library (e.g., Java Mail's InternetAddress class), investigate if it offers options for more conservative header formatting, or if a custom workaround is needed to enforce double quoting.
• DMARC policy awareness: Senders with a 'p=reject' DMARC policy will experience direct message bounces for DKIM failures, making robust authentication crucial. Understanding how DMARC, SPF, and DKIM work together is vital.

Key opinions

• Quote everything: Most marketers advocate for consistently quoting the friendly 'From' name, especially if it contains any character that might be interpreted differently by various mail servers, even if not strictly required by RFCs.
• Recipient server behavior: Marketers note that recipient mail servers, like ATT.net, will often 'fix' what they perceive as invalid headers by rewriting them, which subsequently invalidates the DKIM signature.
• Old issue, new problems: The underlying header formatting rules are decades old, but the strictness of modern authentication protocols (like DMARC with a 'reject' policy) brings these subtle compliance issues to the forefront.
• Varied forgiveness: Different mailbox providers have varying degrees of forgiveness for non-standard headers. Gmail, for instance, might be more lenient or use mechanisms like ARC to mitigate DKIM breakage.
• Impact of p=reject: While a 'p=none' DMARC policy might mask these issues, a 'p=reject' policy immediately reveals header formatting problems through bounce messages. We also have insights into how to fix DKIM body hash failing errors.

Key considerations

• Header standardization: Implement proactive measures to ensure all 'From' headers are formatted in the most compatible way, even if your current mail library seems to follow the RFC. Our guide on decoding DKIM temperror has relevant advice.
• Testing across ISPs: Regularly test email deliverability and authentication across a range of major ISPs to catch inconsistencies in how headers are processed.
• Tooling and libraries: Evaluate the behavior of email sending libraries or platforms; they may need configuration adjustments or custom logic to enforce consistent quoting for 'From' headers.
• Understanding RFCs: While the RFC 5322 provides the technical foundation, practical application often means adhering to the most widely accepted (and sometimes stricter) interpretation.

Key opinions

• Technical correctness vs. reality: A 'From' header might be technically correct according to RFC 5322, but still cause problems with real-world mailbox providers if it deviates from common expectations.
• Fragile DKIM: DKIM signatures are highly sensitive to any changes in the signed headers or body. Even a space or quote added by an intermediary can invalidate the signature.
• ISP variations: Mailbox providers behave differently. Some may be more forgiving or implement mechanisms like ARC to preserve authentication across modifications, while others are stricter.
• Legacy syntax: Relying on obsolete (obs-phrase) syntax, even if historically permitted, is risky because modern systems might not handle it consistently, leading to unintended header rewrites.
• DMARC enforcement: A 'p=reject' DMARC policy will immediately expose any underlying authentication issues caused by header modifications, underscoring the need for perfect alignment. This aligns with advice on safely transitioning DMARC policy.

Key considerations

• Conservative sending practices: Adopt the most conservative formatting for email headers. This means consistently quoting display names, especially if they contain any non-alphanumeric characters or spaces, to ensure maximum compatibility across all recipients.
• Proactive header quoting: Ensure your sending platform or mail library explicitly wraps the 'From' display name in double quotes, even if it might seem optional based on a literal reading of the RFC.
• Understanding alignment issues: Recognize that header modifications directly impact DKIM alignment, a critical component for DMARC success. Read more about fixing compauth failure due to domain alignment issues.
• Adaptation over advocacy: While an ISP might technically be in the wrong regarding header handling, it is usually more pragmatic for senders to adapt their practices than to expect the ISP to change its behavior.

Key findings

• 'Atext' and atoms: RFC 5322 (Internet Message Format) defines 'atext' characters (including apostrophes) that can appear unquoted within an 'atom' (a sequence of 'atext' characters).
• Quoted-string necessity: If a display name contains characters not allowed in an 'atom' (e.g., spaces), it must be formatted as a 'quoted-string', enclosed in double quotes. This ensures proper parsing.
• Obsolete syntax ('obs-phrase'): RFCs include 'obs-phrase' for backward compatibility, which historically allowed display names with spaces to go unquoted. However, relying on obsolete syntax is highly discouraged in modern email systems.
• DKIM and header integrity: DKIM (DomainKeys Identified Mail) is designed to detect any unauthorized modification of email headers or body after signing. Any change, including adding quotes to a 'From' header, will invalidate the signature. Our guidance on how to fix DKIM body hash verification failures is relevant here.
• ARC (Authenticated Received Chain): ARC is a protocol designed to preserve authentication results (like DKIM and SPF) across trusted intermediaries that might legitimately modify a message during transit, but its adoption is not universal.

Key considerations

• Strict adherence to modern norms: While RFCs outline possibilities, the current de facto standard for 'From' headers with special characters or spaces dictates using double quotes. This avoids reliance on obsolete syntax and ensures wider compatibility.
• Pre-signing integrity: Ensure the 'From' header (and all other signed headers) is in its final, universally compatible format *before* the DKIM signature is applied. Any post-signing modification will break it.
• DMARC report analysis: Regularly review DMARC aggregate reports, particularly from major receivers like Google and Yahoo, to identify authentication failures. These reports can highlight if header modifications are occurring. Our guide on understanding DMARC reports is a valuable resource.
• ARC deployment (where applicable): If sending through intermediaries that frequently modify headers, implementing ARC can help maintain authentication, provided the receiving ISP also supports and trusts ARC.