DKIM Failures at Microsoft: The Long Header Problem (January 2026)

A specific DKIM failure pattern emerged in January 2026 that caught many email operators off guard: DKIM signatures failing validation specifically at Microsoft domains (Outlook.com, Hotmail, Microsoft 365) while passing correctly at Gmail, Yahoo, and Apple Mail. The failure is not caused by incorrect DKIM key configuration, selector problems, or authentication misalignment. It is caused by email headers that are too long or that are improperly folded — a header format issue that Microsoft's DKIM validation is more strict about than other major ISPs. The issue was first documented publicly by Postmark's engineering blog in January 2026 and highlighted by Al Iverson at Spam Resource. It affects any sending platform that generates headers exceeding RFC line length limits, and the symptoms closely resemble reputation-based filtering until the root cause is identified.

The Issue: DKIM Failing at Microsoft but Passing Everywhere Else

The pattern presents as follows: a sender reports that their email is landing in the Junk folder at Outlook.com and Microsoft 365 recipient domains but delivering correctly to Gmail, Yahoo, and Apple Mail inboxes. Authentication monitoring shows DKIM passing in the Gmail Authentication-Results header. But when a Microsoft 365 recipient checks the email headers, they see dkim=fail or dkim=none in the Authentication-Results added by Microsoft's mail servers.

This Microsoft-specific DKIM failure pattern is counterintuitive because it appears identical in surface symptoms to a reputation-based filtering problem at Microsoft. The sender assumes their Microsoft SNDS reputation has degraded or their sending domain is on a Microsoft blocklist — because DKIM failures at Microsoft but DKIM passes elsewhere seems impossible if the DKIM keys and signing configuration are correctly set up. The natural diagnostic path (checking SNDS, checking Microsoft Postmaster Tools, checking IP reputation) finds nothing — because the actual cause is a header format issue that manifests specifically in Microsoft's stricter DKIM validation implementation.

Root Cause: Overly Long or Improperly Folded Headers

DKIM signing works by creating a cryptographic hash of specified email headers and the email body, then signing that hash with the sending domain's private key. The DKIM verification process at the receiving end re-creates the same hash by reading the same headers in the same format, then verifies the signature against the published public key.

The problem: DKIM signs headers as they appear in the email, including any whitespace, line breaks, and character positions. When a header is formatted differently at the receiving end than it was when signed — because the receiving server normalised the header by folding it differently — the hash that the receiver calculates does not match the hash that was signed, and DKIM fails.

RFC 5322 (Internet Message Format) specifies that email header lines must not exceed 998 characters, and recommends a soft limit of 78 characters, with folding (line breaks followed by whitespace) used to break longer headers into multiple lines. When sending platforms generate headers that exceed these limits — particularly very long List-Unsubscribe headers, very long Message-ID headers, or long Received chain headers — the headers may be folded or truncated differently by different mail servers along the delivery path.

Microsoft's DKIM validation is more strict than Gmail's about the canonical form of folded headers. When Microsoft receives a DKIM-signed email with improperly folded headers, its DKIM verification may calculate a different hash than was signed — producing a DKIM fail result even though the DKIM keys are correct and the email was properly signed. Gmail's DKIM verification applies more aggressive header normalisation before hash calculation, which accommodates some folding inconsistencies. Microsoft's implementation is more literal about the header format, causing failures that Gmail would pass.

The ActiveCampaign/Postmark Real-World Case

The specific case that Postmark documented in January 2026: ActiveCampaign's Postmark platform was generating List-Unsubscribe headers that were very long — long enough that when they were folded for RFC compliance, the folding was done in a way that Microsoft's DKIM validator interpreted as a header format violation. The resulting DKIM failure at Microsoft domains affected all email sent through that configuration.

This is not unique to ActiveCampaign or Postmark — it is a class of problem that can occur in any sending platform that generates long headers. The specific headers most commonly implicated: List-Unsubscribe (which can be very long when it includes both a mailto: and https: unsubscribe URL with long query strings), Message-ID (when generated with very long unique identifiers), and MIME boundary strings in complex multipart messages.

The fix in this specific case: Postmark updated its header generation to produce properly folded List-Unsubscribe headers that stay within the RFC line length limits at every fold point, ensuring Microsoft's DKIM validator receives headers in a format that produces the same hash as was signed. The fix is a sending platform-level change — individual senders could not resolve it by changing their authentication configuration.

Which Headers Are Most Commonly Too Long

# Headers most commonly found to exceed RFC limits or fold improperly:

# 1. List-Unsubscribe — both mailto and https URLs together can be long
List-Unsubscribe: <mailto:unsub@brand.com?subject=unsub>, 
  <https://unsubscribe.brand.com/opt-out?token=very_long_token_here_that_
  pushes_total_length_over_998_characters_when_combined>
# Fix: Keep unsubscribe URLs short, use URL shorteners or path-based routing

# 2. Message-ID — some platforms generate very long IDs
Message-ID: <very-long-unique-identifier-with-many-components-timestamp-
  serverid-randomchars-morerandomchars@sending.platform.com>
# Fix: Message-ID should be under 200 characters total

# 3. Received headers — added by each hop, can accumulate to long chains
# Each Received header can be up to 998 chars + folding
# Multiple long Received headers can complicate DKIM header signing
# (DKIM does not sign Received headers, but they contribute to overall size)

# 4. X-Mailer or custom X-headers — some platforms add verbose headers
X-Campaign-Information: campaign_id=12345678;list_id=87654321;
  segment_id=99999999;automation_id=11111111;send_time=2026-04-20T09:00:00Z;
  estimated_recipients=150000;region=us-east-1;datacenter=aws-us-east-1a
# Fix: Keep custom X-headers concise or don't include them

# RFC 5322 limits:
# Hard limit: 998 characters per line (including CRLF)
# Recommended limit: 78 characters per line (with folding for longer)
# Folding: insert CRLF + whitespace at any whitespace position in the header
# Proper fold: CRLF must be followed by at least one WSP (space or tab)

Diagnosing the Long Header DKIM Problem

The diagnostic process for Microsoft-specific DKIM failures:

Step 1 — Confirm the pattern: Send the same email to a Gmail address and a Microsoft 365 address. Check the Authentication-Results header in both. If Gmail shows dkim=pass and Microsoft shows dkim=fail or dkim=none with no other authentication differences between the two — the long header pattern is the likely cause.

Step 2 — Extract and examine the email headers: Get the full raw headers of the email as received by the Microsoft mailbox. Look at the List-Unsubscribe, Message-ID, and any custom X-headers. Count the character length of each header line including the header name. Any header line exceeding 78 characters that is not properly folded (CRLF + whitespace) is a candidate for the problem.

# Check header lengths from raw email source:
# Copy the full email headers, then in Python:
import email

with open('raw_email.eml', 'r') as f:
    msg = email.message_from_file(f)

for key in msg.keys():
    val = msg[key]
    header_line = f"{key}: {val}"
    print(f"{len(header_line):4d} {key}: {val[:60]}...")

# Any header showing >998 chars needs fixing
# Any header showing >78 chars without fold characters (\r\n followed by space/tab) is improperly folded

# Check for proper folding in the raw source:
# grep to find lines that are long:
# awk 'length > 998 {print NR": "length" chars: "$0}' raw_email.eml

Step 3 — Check the DKIM signed headers list: In the DKIM-Signature header, the h= field lists which headers are included in the signature. If the problematic long header (e.g., List-Unsubscribe) is in the h= list, it is covered by the DKIM signature — and its improper folding is causing the hash mismatch at Microsoft. If it is not in h=, the long header is not causing the DKIM failure and the cause is elsewhere.

Header Folding: What RFC 5322 Requires

Header folding is the process of breaking a long header value across multiple lines using a CRLF (carriage return + line feed) followed by whitespace (space or tab). This allows long headers to comply with the 998-character hard limit while preserving the full header value when parsed by a compliant parser that removes the CRLF+whitespace fold points and reconstructs the original value.

# CORRECT folding example:
List-Unsubscribe: <mailto:unsub@brand.com>,
 <https://brand.com/unsubscribe?token=abc123>
# The CRLF + single space before the second URL is the fold point
# RFC-compliant parsers reconstruct: 
# "<mailto:unsub@brand.com>, <https://brand.com/unsubscribe?token=abc123>"

# INCORRECT folding (what causes problems):
List-Unsubscribe: <mailto:unsub@brand.com>,<https://brand.com/unsubscribe?token=
abc123>
# The fold breaks in the middle of the URL with NO leading whitespace on next line
# RFC-non-compliant — different parsers handle this differently
# Microsoft's DKIM validator may not normalise this correctly before hashing

# Key rules:
# 1. Fold ONLY at whitespace positions (after comma, at space between items)
# 2. Always follow CRLF with at least one WSP (space or tab) character
# 3. Don't fold in the middle of non-whitespace sequences
# 4. Keep each folded line under 78 characters (recommended) or 998 (hard limit)

Fixing Long Headers That Break DKIM

The fix depends on where the long headers are being generated:

If using a managed ESP (Mailchimp, Klaviyo, Campaign Monitor): Open a support ticket with the header length issue documented. Provide the raw email headers showing which specific headers are over the RFC limit or improperly folded. ESPs are responsible for generating RFC-compliant headers — this is a platform bug report, not a sender configuration issue.

If using PowerMTA: PowerMTA has header folding configuration that controls how long headers are handled. Review the MTA configuration for header-related settings:

# PowerMTA header configuration relevant to folding:
<domain brand.com>
  # Ensure headers are properly folded at 76 chars (safe under 78 limit)
  max-msg-rate 1000/h
  
  # For List-Unsubscribe specifically, keep URL values short:
  # Use path-based unsubscribe routing rather than query-string heavy URLs
  # /unsubscribe/TOKEN rather than /unsubscribe?email=xxx&list=yyy&...
</domain>

# Also check the DKIM signing configuration for header list:
# Only include headers that are stable and necessary in h= parameter
# Exclude headers that may be modified in transit (Received, etc.)
<dkim-signing>
  domain brand.com
  selector mail2026
  private-key /etc/pmta/dkim/brand.com.private
  header-list from:to:subject:date:message-id:list-unsubscribe:list-unsubscribe-post
  # Note: only include list-unsubscribe if URL lengths are controlled
</dkim-signing>

Workaround for uncontrollable header length: If the sending platform generates long headers that cannot be directly controlled, remove the problematic header from the DKIM h= signed headers list. This means the header is no longer covered by the DKIM signature — it can be modified in transit without breaking the signature. This is a security trade-off (List-Unsubscribe becomes unsigned) that is preferable to DKIM failing entirely at Microsoft for every recipient.

Checking Your Own Infrastructure for This Pattern

Proactive check for the long header DKIM failure risk — run this before a Microsoft-specific DKIM failure is reported in production:

#!/bin/bash
# Quick check: send test email and examine headers for length issues

# 1. Send a test email to a Microsoft 365 test account you control
# 2. Download the raw email (in Outlook: File > Save As > .msg, then extract)
# 3. Run this check on the raw email file:

python3 << 'EOF'
import email, sys

with open('test_email.eml', 'r', errors='replace') as f:
    raw = f.read()

# Check line lengths
for i, line in enumerate(raw.split('\n'), 1):
    clean = line.rstrip('\r')
    if len(clean) > 78 and not clean.startswith(' ') and not clean.startswith('\t'):
        # This is a header or body line over the recommended limit
        # and not a continuation/folded line
        if i < 50:  # First 50 lines are likely headers
            print(f"LINE {i} ({len(clean)} chars): {clean[:80]}...")

# Parse and check specific headers
msg = email.message_from_string(raw)
for key in ['List-Unsubscribe', 'Message-ID', 'DKIM-Signature']:
    val = msg[key] or ''
    total_len = len(f"{key}: {val}")
    if total_len > 200:
        print(f"\nLONG HEADER: {key} ({total_len} chars)")
        print(f"  Value: {val[:100]}...")
EOF

echo "Check complete — any output above indicates potential DKIM folding issues"

The long header DKIM failure at Microsoft is a real, documented issue from January 2026 that affects senders using platforms that generate long headers — and is easily missed because the Microsoft-specific nature of the failure does not match the usual diagnostic hypothesis of "my DKIM keys are misconfigured." When DKIM is passing at every ISP except Microsoft, check the headers before checking the keys. The fix is almost always in the header format, not the cryptographic configuration.

The Microsoft DKIM long-header issue is a reminder that email authentication operates at multiple levels simultaneously — cryptographic correctness, RFC format compliance, and ISP-specific validation implementation. A DKIM implementation can be cryptographically correct, using valid keys and proper signatures, while still failing at a specific ISP because of format-level issues in how headers are constructed. Monitoring DKIM pass rates separately by ISP — Gmail, Yahoo, Microsoft, Apple — provides the per-destination visibility needed to detect ISP-specific failures that aggregate DKIM monitoring misses. Any sender who sees DKIM pass rates below 95% at Microsoft specifically while achieving 99%+ elsewhere should investigate header format as the first hypothesis, before pursuing the longer diagnostic paths of reputation analysis and key validation.