Why does DKIM fail when email headers are folded?

You sent a perfectly formatted email, signed it with DKIM, and still got a rejection. The logs say “signature validation failed.” You didn’t change anything. Why?

Because DKIM doesn’t just sign the content—it signs the exact byte sequence of headers, including line breaks and whitespace. Any deviation, even a subtle one introduced by header field folding, breaks the signature.

Header field folding—where a long header line is split with a newline and space—might seem harmless. But it alters the canonicalized form of the header. If the folding happens differently during signing versus verification, the calculated hash changes. The signature is valid only if both ends agree on the exact line structure.

Key takeaways

  • DKIM signatures depend on the precise format of email headers, including whitespace and line breaks.
  • Header field folding introduces variability in the canonicalized header string, which can invalidate signatures if not handled consistently.
  • Even small differences in spacing or line continuation during folding—such as extra spaces or missing newlines—can cause DKIM verification to fail, especially when systems use different folding rules.

What is header field folding, and why does it matter for DKIM?

Header field folding is a legacy email standard that lets long header values wrap across multiple lines by inserting a line break followed by a space. While email clients and servers should recombine folded lines into a single logical header during processing, DKIM requires the canonicalized header set to match exactly what was signed at send time—any change, even whitespace adjustment from folding, breaks validation. This is why a single misplaced space or line break during header processing can cause DKIM to fail silently, even if the message content is correct.

How header field folding works in practice

When a header like From: or Subject: exceeds standard line length limits (typically 78 characters), email systems use a CRLF followed by a single space to break the line. For example, a long subject might appear as:

Subject: Re: Important update regarding quarterly planning and resource allocation for Q3
                and team alignment meetings

When the message is processed, the receiving server must reconstruct the original header as a single line. But if that reconstruction is inconsistent—due to a misaligned space, missing whitespace, or incorrect line joining—DKIM will see a different header than the one originally signed, resulting in a validation failure.

Why DKIM demands strict header consistency

Digital signatures in DKIM are based on a specific, pre-computed string of header fields. Even a single extra space or a line break inserted during processing alters the hash value. The DKIM signature is tied to that exact hash—any mismatch invalidates the signature, regardless of message content. This is why tools that modify email headers during delivery (like relay systems, filters, or mail merge engines) are prone to breaking DKIM if they don’t preserve folding behavior.

The root cause of many DKIM failures lies in how header folding is handled during transit. If the original header was folded and a later system rewrites it without preserving the exact whitespace pattern, DKIM breaks. This is especially common in automated sending platforms or email gateways that reformat or sanitize headers without regard to canonicalization rules.

For teams debugging DKIM, checking how headers are folded and reassembled is critical. Tools like MailTester’s email checker can verify whether an address is valid and help identify delivery issues early—before they impact your sender reputation or inbox placement.

How does header field folding break DKIM signatures?

DKIM signatures rely on an exact match between the signed header data and the data the verifier reassembles. When a header like Received: is folded across lines with a space after the line break, and that space is stripped by a receiving server, the canonicalized string changes—breaking the signature even if the email content is correct. This mismatch happens because DKIM’s canonicalization algorithm treats every character, including whitespace, as part of the signed data.

What DKIM expects: strict header preservation

DKIM signers apply a strict algorithm to canonicalize headers. They keep every byte exactly as sent, including spaces after line breaks and literal CRLF sequences. This means the signature is based on the precise text layout, even if it’s visually formatted with line breaks for readability. Any change—like trimming a space or merging lines—alters the hash and invalidates the signature.

Why folding seems harmless—but isn’t

Let’s say your mail server adds a Received: header with a folded line: Received: from mail.example.com (localhost [127.0.0.1])
by mx.example.org with ESMTP The space before by is part of the data. But some mail processors normalize line folding by removing that leading space during parsing. Now the canonicalized header differs from the original signed version. The verifier can’t reconstruct the signed data, so the signature fails—even though the email is legitimate.

This is why header field folding must be preserved intact. Even small whitespace inconsistencies disrupt the cryptographic verification. The issue isn’t with DKIM itself, but with how intermediate systems handle line breaks. The DKIM specification explicitly requires maintaining all whitespace as sent; violating it breaks trust.

You might think this is rare, but it's a common source of failures in bulk mail. If your email client or MTA applies post-processing that alters whitespace, your DKIM signature may fail even with valid content. Verifying your outgoing messages at the header level—especially before sending—can catch these issues early.

Use a tool like MailTester’s inbox placement test to simulate how your messages appear in real inboxes and catch formatting issues before they hit large audiences. It checks not only deliverability but whether headers are preserved correctly during transit. For developers and administrators, testing raw headers with a real-time verification API also helps detect mismatches before sending to thousands.

Which tools or platforms are most likely to cause DKIM failures due to folding?

Platforms like SendGrid, Mailgun, and Amazon SES are among the most likely to cause DKIM signature failures due to header field folding, especially when they modify message structure during relay or queuing. These services may apply inconsistent folding rules, and older or non-compliant MTAs sometimes strip leading spaces from folded headers, violating the canonicalization step required by DKIM. If your DKIM signature fails validation, folding issues are a common, often overlooked culprit.

How delivery platforms introduce folding inconsistencies

When an email passes through multiple servers—especially in cloud-based delivery stacks—each hop may interpret and rewrite header folding differently. This divergence breaks the canonicalization process, which relies on consistent formatting of folded header fields. For example, a header that's folded with a space after the line break on one server might be unfolded or stripped of spaces on another, invalidating the computed signature.

While RFC 5322 defines how headers should be folded and processed (see Section 2.2.3 of RFC 5322), not all MTAs adhere strictly to it. Some older mail transfer agents assume that all whitespace after line breaks in folded headers should be removed, which violates the standard and breaks DKIM validation.

When fold handling becomes a hard failure

The key issue isn’t just folding—it’s the assumption that folding is reversible. DKIM requires that the header set used to compute a signature be identical to the one used during validation. If a platform rewrites folded headers by altering indentation or collapsing lines, even slightly, the canonicalized version differs and the signature fails.

These problems are particularly common in platforms that queue or proxy messages. For instance, when you send through an ESP like SendGrid, the message may be reprocessed, cached, or rewritten before relay, introducing folding anomalies. If your verification setup doesn’t simulate real-world delivery paths, you might miss these edge cases.

You can test this behavior with a real inbox placement test that checks how your message is interpreted in final delivery, including header handling across major inboxes. It’s one of the few ways to catch folding issues that don’t surface in basic syntax checks.

How can you detect DKIM failures caused by header field folding?

You can detect DKIM signature failures caused by header field folding by reviewing DMARC reports for dkim=permerror or dkim=fail without any apparent content issue. Look for patterns of failure across multiple messages from the same system where headers were folded inconsistently. Use a real-time email verification service with inbox-placement testing to replay the full message headers and catch mismatches in signed content due to folding.

Check DMARC reports for subtle signature errors

  • Examine both aggregate and forensic DMARC reports for dkim=permerror or dkim=fail indicators — even when headers appear valid at a glance.
  • Focus on failures labeled permerror, which often point to structural issues like incorrect header formatting, including folding.
  • Compare reports across time and senders — recurring failures from the same domain suggest a consistent misconfiguration, such as non-standard line folding.

Validate header folding consistency with real message replay

  • Use a service that replays full email headers (including folds) exactly as sent to detect mismatches between what was signed and what was delivered.
  • Look for differences in how header lines are broken — especially in Subject, To, or From fields — where folding may alter the canonical text without visible changes.
  • Test multiple messages from the same system using the same headers and authentication setup; inconsistent folding patterns across them are a red flag.
  • Verify against RFC 5322, the standard for email message formatting, which specifies how headers should be folded with a single CRLF and space or tab after the line break.

Header field folding issues are hard to spot because they don’t always break parsing — but they can break DKIM signature validation. The signature is computed on a normalized version of the header, and any deviation in folding (like adding extra spaces, multiple CRLFs, or splitting lines mid-word) changes the canonical content.

You can use inbox placement testing to replay your email with real headers, including all folding, and confirm whether the DKIM signature still matches. This step simulates real-world delivery conditions and helps catch invisible errors before they hit filters or blocklists.

While DMARC reports tell you something went wrong, only real-time header replay shows you the exact cause. You're not just debugging a failure — you're validating the integrity of every byte sent.

How to test and verify DKIM header folding issues in real time?

You can debug DKIM signature failures caused by header field folding by sending a test email through MailTester’s real-time verification API with carefully crafted headers, then checking the raw output against the original signed content. Use inbox-placement testing to see if the receiving server accepts the message with a valid DKIM signature. If whitespace or line breaks were altered during transmission—common with non-compliant mail servers—you’ll catch it before it impacts deliverability.

Step-by-step: Test DKIM header folding in real time

  1. Send a test email via MailTester’s real-time verification API with headers constructed to simulate known folding issues. Use the API email checker to control the exact format of each header line, including intentional line breaks and whitespace. This lets you reproduce the failure condition intentionally.
  2. Enable inbox-placement testing during the send. This uses real recipient mail servers to evaluate the full delivery path. You’ll see whether the DKIM signature passes or fails at the receiving end—this reveals whether header folding altered the message body or signature verification failed due to whitespace changes in transit.
  3. Download and compare raw headers from the test result. The API returns the exact headers sent, and the inbox placement result includes the headers received by the test inbox (via MxToolbox or similar infrastructure). Use a diff tool or careful visual inspection to spot differences: extra spaces, missing line breaks, or altered folding points that violate RFC 5322's rules on header formatting.
  4. Check for misfolded lines where line breaks were inserted in the middle of a header value instead of after a whitespace character. This is a common mistake in non-RFC-compliant mail servers or poorly configured email clients. If your DKIM signature was generated on a header that was later re-folded differently, the signature will fail validation.
  5. Re-send with corrected formatting. Adjust the header structure to ensure line breaks occur only after a space or within a valid folding location. Use a DKIM validator like RFC 6376 as a reference for correct header signing and folding rules.

Why this works

DKIM relies on an exact match between the header fields used during signing and those present during verification. Even one space change or a split line where it shouldn’t be can invalidate a signature. Testing with real mail servers—like those used in MailTester’s inbox placement tool—reveals whether folding issues matter in practice, not just in theory. Many modern systems now enforce strict header checking, so misfolding is a common root cause of otherwise mysterious DKIM fails.

“DKIM signatures are sensitive to whitespace and line folding. Even minor differences between the signed and verified headers can result in a failed verification.” — RFC 6376, Section 3.6

Testing early with tools like MailTester’s real-time API gives you the ability to catch these edge cases before they hurt your sender reputation. You’re not guessing—you’re validating with real results.

How can you fix DKIM failure due to header field folding?

DKIM signature failures from header field folding happen when your mail server or sending platform alters folded line breaks in email headers during transmission. To fix this, enforce strict canonicalization (simple or relaxed) as defined in RFC 6376, disable any feature that trims leading whitespace from folded lines, and use a tool like MailTester’s inbox placement tester to inspect raw SMTP traces and identify problematic lines.

Ensure proper canonicalization is enforced

  • Confirm your email system uses strict canonicalization—either simple or relaxed—when signing emails, as specified in RFC 6376.
  • Simple canonicalization preserves every byte of the header, including whitespace and line breaks; relaxed allows minimal normalization (e.g., folding and trimming trailing spaces).
  • If your sender platform applies its own header normalization, it can break DKIM validation. Verify this behavior with your provider’s documentation or by analyzing raw email headers.
  • Use tools like RFC 6376 to validate your implementation matches the standard.

Disable header normalization that alters folded lines

  • Check whether your email service, API, or mail server applies automatic “cleaning” to headers—particularly trimming leading whitespace from folded lines.
  • Even a single space or CRLF difference can break the DKIM signature because the signing and verification processes must see identical byte sequences.
  • Many platforms default to aggressive normalization. Look for settings like “normalize headers,” “sanitize,” or “folded line handling” and disable them if they modify content.
  • Let’s be clear: any auto-removal of leading space on folded lines—especially at the start of a line after a line break—is a likely cause of DKIM signature failure.
  • Use a real-time verification tool to analyze actual delivery traces. MailTester’s inbox placement tester can show you exactly how your email was parsed and where the signature validation failed.
DKIM isn't just about signing—it's about guaranteeing the message seen by the verifier matches the one signed. Even a single invisible byte change breaks the chain.

In practice, many platforms that claim to support DKIM will still interfere with validation if they normalize headers. The fix is never to change the signing method, but to ensure consistency between signing and delivery. Run a test with a known good header structure and compare it against the raw trace from a receiving server. If the headers don’t match byte-for-byte, you’ve found the source of the failure.

What should you do if DKIM signing still fails after fixing folding?

If DKIM signing fails despite fixing header field folding, you need to validate that the correct headers are signed, their names are case-sensitive, and your DNS records match your DKIM selector and domain. Misconfigurations in any of these areas can break signatures even when folding is fixed. Let’s walk through the next steps.

Check the header canonicalization and inclusion

  1. Verify all headers listed in the DKIM-Signature header's h tag are explicitly included in the canonicalized header set. For example, if h=From:To:Subject:Date, ensure each of those headers appears exactly as they do in the message's final header block. Missing or misnamed headers will cause the signature to fail during verification, even if folding is correct. See RFC 6376 for the canonicalization rules.
  2. Ensure no header is folded or altered during preprocessing. Lines longer than 78 characters must be folded with a soft line break, but some tools mishandle this. Use a tool like RFC 6376 to validate your canonicalization process—especially for the h field order and spacing.

Confirm DNS and selector alignment

  1. Check that the DKIM selector in the From header matches the one published in DNS. The selector is the first part of the dkim-selector._domainkey.example.com record. A mismatch here means the receiving server won’t find the public key, leading to a signature failure even with correct header values.
  2. Ensure the domain in the DNS record matches the signing domain. If your message uses From: [email protected], the DKIM record must be published at dkim.company.com, not mail.company.com. Use MXToolbox to query your DNS records and confirm the key is published and reachable.
  3. Validate header name case. DKIM is case-sensitive. Date and date are different fields. If one is signed, the other cannot be substituted. Ensure your signing algorithm treats header names exactly as they appear in the original message.

These steps cover common but often overlooked causes of persistent DKIM failures after header folding fixes. If your signature still fails, verify your private key matches the public key in DNS and that no proxy or middleware is rewriting headers after signing. Use inbox placement testing to check how your signed emails perform in real inboxes across major providers.

How does MailTester help debug DKIM signature issues?

You can catch DKIM signature failures caused by header field folding before they break deliverability by testing your emails in real inboxes across Gmail, Yahoo, and Outlook. MailTester runs inbox-placement tests using live servers to spot signature mismatches resulting from improper header formatting—like folding during transport. These tests expose issues early, so you send only well-structured messages that pass verification.

Real-time inbox testing detects signature flaws

DKIM signing relies on perfect alignment between the headers in the original message and those used during verification. If headers are folded incorrectly—say, by a misconfigured system during SMTP transmission—DKIM can fail, even if the content is otherwise correct. MailTester simulates delivery to major inboxes and validates the full signing chain, including header structure and canonicalization. This catches folding errors that tools checking only the header text might miss.

API validation pinpoints header-body mismatches

When you use MailTester’s real-time verification API, you get a full analysis of the email’s header and body structure before sending. The API checks for subtle issues—like improper line breaks in headers, non-canonicalized content, or missing whitespace—that can break DKIM validation. It highlights mismatches between what was signed and what was received, especially where field folding disrupts the signed header order. This gives teams granular feedback right at the point of integration.

According to RFC 5322, proper MIME header formatting requires that folded lines begin with whitespace. Violations of this rule are common in automated systems, often leading to silent DKIM failures. MailTester ensures your email adheres to this standard, reducing surprises post-send.

With 98.9% accuracy in identifying valid, invalid, and catch-all addresses, MailTester helps teams verify both the envelope and the full header-body structure. It's used by developers and marketers alike to validate email infrastructure before scaling out campaigns. You can test individual addresses, bulk lists, or integrate directly into your send flow—using the verification API or inbox-placement tester.

Can you prevent DKIM failures from header folding in the first place?

Yes — you can reduce the risk of DKIM signature failures caused by header folding by strictly controlling how headers are formatted during message generation. Avoid folding long headers unless necessary, keep field values concise, and validate header structure before sending. DKIM relies on exact header content, so any deviation—even from line folding—can invalidate the signature.

How to avoid folding issues before they cause problems

  • Configure your sending system to emit headers without unnecessary line breaks. Use RFC 822-compliant formatting and disable automatic line folding for headers like Subject, From, or To unless they exceed 78 characters.
  • Reduce header length where possible. A subject line longer than 70 characters increases the risk of improper folding. Use shorter, clearer subject matter and avoid concatenating large values in header fields.
  • Test header output using known-good message templates. Tools like Mail-Tester can verify how your message headers are interpreted by receiving systems, including how they handle line breaks and folding.
  • Review outgoing headers from your email service or application before deployment. Use a local debugging tool to inspect the raw MIME output and confirm that headers are not folded during transmission.

Why this matters for DKIM validation

DKIM signatures are computed over the exact bytes of header fields. If a receiving server reassembles folded lines differently than the sender did—due to software-level folding rules—signature verification will fail. This is especially common when mail systems use different folding thresholds, especially if legacy or broken implementations are involved.

Even subtle differences, like adding a space after a line break or inserting a newline in an unexpected place, can invalidate the signature. The sender's responsibility is to ensure header content is exactly what the signing algorithm sees. Using tools like MailTester’s inbox placement tester helps simulate real-world receipt and catch issues like these before sending to real users.

Summary: The key to reliable DKIM is consistency in header presentation.

DKIM signatures are sensitive to the exact formatting of email headers, including how line breaks and whitespace are applied. Even minor deviations in header field folding can invalidate a signature, leading to failed authentication and delivery issues.

Header field folding must be handled consistently across all stages of email generation and transmission. Do not rely on assumptions that servers will normalize whitespace—always verify the output matches the expected format.

Prevent issues before they reach inbox filters

  • Use real-time inbox testing to validate DKIM signatures under actual receiving conditions.
  • Inspect raw headers via API to catch folding inconsistencies before sending.
  • Integrate tools like MailTester early in your workflow to detect signature failures before they impact sender reputation.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does 'DKIM signature failure caused by header field folding' mean?

It means the email’s DKIM signature was signed using a specific header format, but the receiving server processed the headers differently—often due to inconsistent line folding or whitespace handling—leading to a mismatch in the canonicalized content.

Can header folding ever be harmless?

Only if both sender and receiver apply identical rules for folding and reassembly. Most systems do not, so folding poses a risk to DKIM validity.

Do all email clients parse folded headers the same way?

No. Clients and servers vary in how they interpret folded lines, especially when space or line breaks are involved, leading to canonicalization differences.

How do I know if my emails are failing DKIM due to folding?

Check DMARC reports for dkim=fail or permerror. Re-test using inbox-placement tools that analyze raw headers and detect folding inconsistencies.

Can I use DNS records to fix DKIM folding issues?

No. DKIM folding issues are caused by message content, not DNS. DNS only controls domain alignment and key retrieval.

Does MailTester detect header field folding issues?

Yes—MailTester’s inbox-placement and real-time verification API test the full header structure, including whitespace and line folding, to uncover DKIM mismatches.

What happens if DKIM fails due to folding?

The email may be treated as unauthenticated, leading to rejection, quarantine, or delivery to spam folders by receiving mail servers.

Is header field folding still used in modern email systems?

Yes—RFC 5322 remains in force, so header folding is still part of the standard, but implementation varies widely across platforms.

Can email providers auto-fix DKIM failures from folding?

No—mail providers reject or mark messages as suspicious if DKIM fails. They do not attempt to correct folding inconsistencies in headers.

How many senders experience DKIM failures due to folding?

Many do, especially those using third-party platforms that modify headers. The exact number is not publicly reported, but it’s a commonly observed issue in deliverability troubleshooting.