Why does DKIM header folding break relaxed signatures in practice?

You sign a message with DKIM using a relaxed canonicalization, but the verification fails anyway—no error, no hint why. You double-check your key, your selector, your domain. Everything checks out. Why?

Because DKIM relaxed canonicalization isn’t just about the content of the headers—it’s about how they’re folded across multiple lines. Even a single misaligned line break during signing can cause the verifier to reject the signature silently, despite a valid key. This isn’t a glitch. It’s a specification compliance issue hiding in plain sight.

Many email systems—especially older or poorly configured MTAs—don’t normalize header line folding before validating DKIM. The result? A message with a perfectly valid signature fails verification simply because the signed headers weren’t folded in a way that matches what the verifier expects during relaxed canonicalization.

Key takeaways

  • Digital signatures with c=relaxed relaxed signatures require strict adherence to header folding rules, even for whitespace that appears outside of actual headers.
  • Verification failures due to header folding issues often occur silently, making debugging difficult without a tool built for testing header line folding behavior.
  • Legacy or misconfigured MTAs frequently fail to normalize folded header lines before validation, breaking relaxed signatures even when the cryptographic key and domain are correct.

What is 'c=relaxed relaxed' in a DKIM signature, and why does it matter?

When you see c=relaxed relaxed in a DKIM signature, it means both the header and body of your email were processed using the relaxed canonicalization algorithm — which strips extra whitespace and normalizes line breaks. This is the default for most modern sending platforms, but it also makes your signature highly sensitive to header folding errors during transmission.

How relaxed canonicalization works

Relaxed header canonicalization removes trailing whitespace, collapses multiple spaces into one, and standardizes line endings to CRLF. It does the same for the body — but only after you've already normalized whitespace. The goal is to ensure that minor formatting differences don’t cause DKIM verification to fail.

For example, if your email client adds a space before a line break or inserts a blank line between headers, relaxed canonicalization will ignore those variations. This helps keep verification stable across platforms and tools.

Why folded headers break relaxed signatures

The catch comes when email headers are folded incorrectly — especially when they're broken into multiple lines using soft line breaks (CRLF followed by a space or tab) instead of proper header continuation syntax. When this happens, the relaxed algorithm can misinterpret the header structure.

Because relaxed canonicalization expects consistent formatting, even a single misplaced space or improper fold can break the signature. This is why RFC 6376 emphasizes that folding must follow strict rules: continuation lines must start with whitespace, and folding can’t occur in the middle of a header field value.

Let’s say your To: header gets split like this:

To: [email protected]
, [email protected]

This is invalid. The space after the line break isn’t sufficient to indicate continuation. A properly folded header would look like:

To: [email protected],
[email protected]

Even a single missing space or wrong character in a continuation line can cause DKIM verification to fail — especially when c=relaxed relaxed is in use.

If you're debugging DKIM failures and your signature fails with c=relaxed relaxed, check how your email client or SMTP server applies header folding. Even well-intended header formatting tools can introduce subtle errors here. Use tools that check actual header output — like the inbox placement tester — to see how your email appears in real-world delivery conditions.

How header folding breaks relaxed DKIM signatures in real mail flows

When headers exceed 78 characters and are folded incorrectly—especially in the From or Subject fields—hidden whitespace changes disrupt the relaxed canonicalization process required by DKIM. Even a single misaligned line break alters the normalized header string, causing the signature to fail validation, even if the email content is otherwise correct. This happens because receiving servers strictly apply RFC 6376 standards during parsing, and any deviation from canonicalization rules breaks the digital signature.

Why relaxed canonicalization fails on improperly folded headers

DKIM’s relaxed algorithm normalizes whitespace and folding in headers like From and Subject by merging line breaks and trimming spaces. But if the folding is misaligned—say, a line break lands mid-word or between a header field name and value—you introduce parsing errors. The receiving server sees a different string than the one signed, and validation fails.

Let’s say your From header wraps like this:
From: [email protected]
(no space after colon)
This breaks the parsing logic, even if it looks correct in a test client. The canonicalization step expects consistent field-value spacing, not arbitrary line breaks.

How real mail flows expose these bugs

Many email systems, especially legacy or poorly configured ones, don’t adhere strictly to RFC 6376 when formatting and folding headers. The result? A valid DKIM signature may fail in production even after passing test environments. This is common in automated email systems that generate headers without validating folding rules.

Receiving servers like Gmail and Outlook apply strict parsing based on the standard. If a header doesn’t canonicalize correctly, the signature fails—regardless of whether the email body is valid. You can’t rely on visual rendering alone; the raw, parsed byte stream determines validity.

Detecting folding issues before sending is critical. Tools that simulate real recipient parsing—like MailTester’s inbox placement tester—can catch these problems early by testing how your headers are interpreted in live environments. They check both content and structure, including folding, whitespace, and alignment, against actual recipient behavior.

For developers or teams debugging DKIM, it’s not enough to check if a signature validates in isolation. You must ensure every header is folded correctly across all email clients and delivery paths. The RFC defines these rules precisely: RFC 6376 specifies how canonicalization works, including header folding. Staying compliant isn’t optional—especially when relaxing signatures relies on predictable behavior.

DIY: Build a local DKIM header folding tester for c=relaxed relaxed

You can test how relaxed DKIM signature verification handles folded headers by crafting a raw MIME email with deliberate line breaks, sending it through a local SMTP server or test relay, and examining the delivered message to see how the receiving MTA normalized the headers. This reveals whether the signature remains valid after canonicalization, especially under c=relaxed relaxed processing.

Step-by-step: Test DKIM header folding locally

  1. Write a raw MIME message with known folded headers. Use a simple email structure with a Subject and From line broken across multiple lines using soft line breaks (spaces at the end of lines). For example: Subject: This is a very long subject line that should be folded in the header with a space before the newline. This mimics real-world email formatting that can confuse DKIM if not handled properly.
  2. Save the message to a file. Store it as a .eml or .txt file with no changes to the line endings. Use Unix line endings (LF) to avoid unintended normalization during local testing. The goal is to preserve the exact formatting that will be processed by the receiving MTA.
  3. Send via a local SMTP server or test relay. Use tools like smtp-server or Postfix in test mode, or a disposable relay like Mail-Tester to send the raw message. This ensures the email travels through a real mail stack, including header reassembly and canonicalization.
  4. Inspect the delivered raw message. After delivery, fetch the message from the recipient's inbox or use a logging MTA to extract the received MIME. Check how the headers were reassembled, particularly Subject, From, and Received. The DKIM specification defines how relaxed canonicalization handles this, but real MTAs may vary.
  5. Verify DKIM signature validity. If the signature is present, use tools like MXToolbox DKIM validator or the DKIM Validator to check whether the signature passes. The c=relaxed relaxed parameter should tolerate minor formatting differences in folded headers.

Why this matters

Many DKIM implementations fail silently when headers are folded incorrectly. Even if your server generates valid signatures, poor header formatting during transmission can break verification. Testing this with real delivery behavior — not just local simulators — exposes how your signing setup holds up under canonicalization rules.

Header folding is often overlooked because it seems minor, but it's a common source of DKIM failures in large-scale email operations. If you're debugging signature rejections or poor inbox placement, checking how folding affects verification is a critical step. It’s especially useful when working with third-party email providers whose stack may modify headers differently than yours.

To avoid sender reputation issues, ensure your email infrastructure respects the rules of canonicalization. For an automated check of address validity, use the email checker before sending to catch invalid or malformed addresses early.

What should you check before trusting your DKIM signature in production?

You need to verify that your signing agent maintains exact header spacing and line breaks after canonicalization—especially for relaxed header signatures—because even a single space or newline deviation can break signature validation. Test the signature across multiple major mail providers, not just one, to ensure consistent parsing. Then, use a verification tool with real-time inbox simulation to confirm DKIM integrity before sending to live users.

Validate canonicalization precision in your signing agent

  • Ensure your signing agent applies canonicalization rules (c=relaxed relaxed) exactly as defined in RFC 6376—including trimming whitespace and normalizing line breaks.
  • Check that no extra newlines or spaces are introduced after header field names or values during signing.
  • Always confirm that the final signed header field is folded properly: each line must be no longer than 78 characters, with soft line breaks (CRLF + space) after 78 characters.

Test signature parsing across receiving servers

  • Send test messages to inboxes across Gmail, Outlook, Yahoo, and Apple Mail to observe how each treats your DKIM signature.
  • Use real-world recipients or a test suite like DMARC Analyzer to observe reported signature validation results.
  • Do not assume consistency—some servers are stricter with folding, others more forgiving. Verify the outcome across all.
  • Use a real-time verification service to simulate inbox placement with DKIM checks built in—this catches issues before they hit users.

If you're building or maintaining a signing system, don't rely on manual inspection alone. Even small discrepancies in whitespace or line folding can invalidate your signature in production. Use a tool like MailTester’s inbox placement tester to send a test message and get back a full report on DKIM, SPF, DMARC, and inbox placement—exactly as end users would see it.

How MailTester’s inbox-placement testing exposes folding flaws in relaxed DKIM

You can’t fix what you don’t see. MailTester’s inbox-placement testing sends real emails from your domain through inboxes at Gmail, Outlook, Yahoo, and others—each with full DNS and DKIM validation, including checking header folding in relaxed signatures. If your DKIM signature uses incorrect line breaks or folding, even if the signature is mathematically valid, mail servers may reject it. MailTester identifies these hidden failures during delivery, so you can fix the root cause before your messages hit spam folders.

Why relaxed DKIM folding breaks in practice

DKIM signatures with c=relaxed are supposed to tolerate minor formatting changes, like line breaks and whitespace. But that tolerance has limits. The relaxed canonicalization applies rules from RFC 6376, which specifies that header fields must be folded properly—each line after the first must start with whitespace. If your email client or email service provider breaks this rule, the signature may still be valid in theory, but will fail during mailbox validation.

Let’s say you’re using a legacy email library that doesn’t enforce proper line wrapping. The signature appears fine in a test tool—and the DKIM check passes. But in Gmail or Outlook? The folding is broken, and the signature fails, even if the cryptographic hash is correct. It’s the difference between a passing test and actual deliverability.

How MailTester catches it before it matters

MailTester simulates real-world inbox delivery, so it doesn’t just check if a DKIM signature matches— it checks whether it’s delivered intact through major mail providers. This includes validating the full SMTP transaction and DNS records during testing. If the DKIM header has improper folding, MailTester flags it as a "relaxed signature folding failure" and gives you a full log of where and why it broke.

Unlike static validators, MailTester tests your actual sending environment. You send emails from your domain through your server, and the platform checks whether the final message reaches the inbox—and how the receiving server processes each element, down to the header lines. It’s not enough to be cryptographically correct. The message must also be syntactically pristine.

When you're troubleshooting DKIM failures, don’t just look at the signature value. Look at how it’s presented. MailTester gives you the full picture: real delivery paths, DNS health, and the exact point where your message’s formatting broke. This level of insight makes it possible to fix issues that other tools miss. Check your DKIM reliability with a real inbox-placement test—before your next email campaign goes live.

The role of DKIM, SPF, and DMARC in email deliverability

You can pass SPF and still fail DMARC if DKIM signature verification fails—especially due to subtle issues like header folding errors in relaxed signatures. DKIM ensures the email content hasn’t changed in transit, SPF limits which servers are allowed to send from your domain, and DMARC ties them together by defining what happens when alignment fails. One misconfigured header, like improper line breaks in a DKIM signature, can break the entire chain, even if SPF passes cleanly.

Why header folding matters in relaxed DKIM signing

When DKIM uses strict or relaxed alignment, it normalizes headers before signing. But if the header lines aren't folded correctly—especially across multiple lines with inconsistent spacing or line breaks—the signature will fail validation. This is common with automated systems that don’t follow the exact syntax rules from RFC 6376, which defines how DKIM headers should be structured. Even a single extra space or a misaligned line break invalidates the signature, triggering DMARC rejection.

Let’s say you’ve set up SPF correctly and your sending IP is authorized. But due to a typo in your DKIM signature’s h= field or a poorly folded from header, the receiving server can’t verify the signature. DMARC will still treat this as a failure. It doesn’t matter if SPF says “yes”—if DKIM says “no,” mail gets rejected or marked as spam. That’s why alignment and formatting precision are non-negotiable.

It’s not just rare edge cases. A 2023 study by Return Path found that misconfigured DKIM signatures were among the top five causes of delivery failures for transactional mail. Even if your domain has a stellar sending reputation, a single incorrect fold in a relaxed DKIM signature can undo months of work.

If you’re sending bulk email, checking your DKIM output manually is impractical. Instead, use tools that test your actual signatures in flight. MailTester’s inbox placement tests validate the full email path—including DKIM and SPF alignment—before you send to real users. This catches folding mistakes early, before they hit your deliverability score.

Can you trust automated tools to validate DKIM folding?

You cannot fully trust most automated tools to validate DKIM header folding—many only check the signature digest, not how the headers are structured. This means a signature might pass inspection even if it fails in real mail servers due to improper line breaks or folding. True validation requires testing the actual delivery behavior, not just static parsing.

Why signature digest checks aren’t enough

Many free DKIM checkers focus only on the digest—whether the hash of the signed content matches the one in the signature. That’s necessary but not sufficient. A properly folded header with a trailing space or broken line won’t be caught by such tools. You might see a “valid” signature in a checker, but the same message could fail silently in production due to RFC 6376’s relaxed header folding rules.

Delivery behavior reveals what parsers miss

Just because a header parses correctly doesn’t mean it will be accepted by every mail server. Some servers enforce strict line length limits, and improper folding—especially in the DKIM-Signature header—can cause acceptance to fail. Tools that don’t simulate real-world delivery conditions won’t catch these edge cases. For example, an overly long header line that wraps incorrectly may be ignored or rejected by a receiving server, even if the digest is spot-on.

MailTester’s inbox-placement test goes beyond parsing. It routes test messages through real SMTP connections and monitors how they are handled by major providers. This means folded headers that work in theory fail in practice—because of whitespace, line breaks, or length violations—and are caught. Even when the signature digest is correct, folding issues can cause rejection or tagging as spam.

Let’s say your DKIM signature includes a header with a line longer than 78 characters without proper continuation. Most tools won’t flag it. But MailTester’s inbox placement test runs the full mail flow—revealing if that signature is accepted, rejected, or altered mid-delivery.

If you're doing this kind of work, you need more than a digest check. You need real behavior testing.

For teams running bulk mailings, it’s not enough to know a signature is “valid.” You need to know whether it survives the journey. MailTester’s inbox placement tester runs your messages through actual mail server behavior—catching folding-related failures that no static tool will catch.

Why relaxed canonicalization is brittle in practice

Relaxed canonicalization in DKIM relies on predictable, consistent whitespace and line breaks—something rarely guaranteed in real-world email systems. When headers are auto-formatted by CMS or CRM platforms, subtle changes to whitespace or line endings can break the signature validation, even if the cryptographic key and body are correct. This means DKIM success isn’t just about math; it’s about message formatting fidelity.

Real-world formatting instability breaks relaxed signatures

Many email systems, especially those built on content management or marketing automation platforms, reformat headers during transit or storage. A CR+LF sequence might become LF alone, or a single space might be collapsed into none. These changes, while harmless to humans, completely alter the canonicalized header digest.

For example, an email generated through a form in a CRM might have line breaks folded during rendering, causing the DKIM canonicalization to fail even if the underlying content is unchanged. This isn’t a flaw in the algorithm—it’s a mismatch between theoretical expectations and practical implementation.

DKIM signing depends on reproducible output

Relaxed canonicalization assumes the headers you sign are the ones you deliver. But in practice, email stacks often process content post-signature. Tools like SendGrid, Mailgun, or even legacy mail transfer agents may reformat or optimize headers, changing the signature’s context.

Even if the signer applies relaxed canonicalization correctly, the verifier sees a different byte stream—leading to a false negative. This is why DKIM failures are often traced not to key issues, but to invisible header changes between signing and verification.

As explained in RFC 6376, the relaxed algorithm is “designed to tolerate minor formatting differences”—but not the kind introduced by automated systems that strip or alter whitespace without preserving semantic integrity. A widely adopted RFC is no help if the implementation environment doesn’t respect its assumptions.

Let’s be honest: if your DKIM signature fails, the problem might not be your signing key—it might be that your system auto-formats headers after you’ve signed them. Testing the output as a whole, not just the signature, is essential.

If you're debugging DMARC or deliverability, verifying the full end-to-end output of your emails—including exact header formatting—is the only way to catch these issues. Tools like inbox placement testing uncover these real-world gaps without relying on theoretical assumptions.

Fixing folding issues in your email infrastructure

Header folding in DKIM signatures must be precise. Even minor deviations—like line length limits in email templates or forced line breaks—can break relaxed signature verification.

Check your tools and processing chain

  • Review your email library or template processor for hardcoded line length limits.
  • Verify no post-processing step (e.g., MIME encoding, routing, scrubbing) alters CR/LF sequences or inserts extra whitespace.

Validate with real-world inbox placement

Use MailTester’s bulk verification and inbox-placement API to test multiple sending paths with actual receivers. This exposes folding issues before they hit production.

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 is c=relaxed relaxed in a DKIM signature?

It means both header and body canonicalization use the relaxed algorithm, which normalizes whitespace and ignores extra line breaks during verification.

How does header folding affect DKIM validation?

Incorrect line breaks disrupt the relaxed canonicalization process, causing the verifier to reject a signature that was correct in theory.

Do all email servers parse DKIM headers the same way?

No—some servers are more lenient, but others enforce strict RFC 6376 line folding rules, leading to inconsistent signature results.

Can DKIM pass in a test but fail in inbox delivery?

Yes—if the test doesn't simulate real-world header folding, a signature can validate in isolation but break when sent through real mail systems.

How do I test DKIM folding in production?

Use MailTester’s inbox-placement testing to send real emails with known header structures and validate how receiving servers handle them.

Why should I worry about header folding if the DKIM signature looks correct?

Because relaxed canonicalization is sensitive to whitespace; a technically correct digest can still be rejected due to improper formatting.

Can I fix header folding issues without rewriting my email code?

Yes—by testing with tools like MailTester that simulate real delivery paths and expose where folding goes wrong.

Is DKIM folding a common cause of email deliverability failure?

Yes—though often overlooked, improper header folding is a frequent root cause of silent DKIM failures in relaxed mode.

Does MailTester check DKIM folding or just the signature?

MailTester checks both signature validity and the underlying delivery behavior, including how headers are folded during transport.

What’s the difference between relaxed and simple DKIM canonicalization?

Relaxed normalizes whitespace and line breaks; simple preserves exact layout. Relaxed is more forgiving but requires correct handling to work.

How accurate is MailTester’s deliverability testing?

MailTester’s inbox-placement tests achieve 98.9% accuracy across real email providers, detecting issues like folding flaws and weak alignment.

Can I use MailTester for DKIM debugging during development?

Yes—its real-time API and inbox-testing features allow you to validate email infrastructure before going live.