What happens when DKIM validation fails because of folded headers?

You've verified the DKIM signature. The alignment looks right. But the email still bounces. Or worse—lands in spam. Why? Because even a small formatting detail—header folding—can break DKIM validation.

Dkim signatures are built on trust: a strict canonicalization process ensures the message hasn’t changed since it was signed. But when the canonicalization method uses c=relaxed or c=simple, it assumes headers are unfolded. In reality, many emails use folded lines. When that happens, the simple canonicalization treats the folded text as a single line, altering the content. The signature checks that version—wrongly—and fails.

Key takeaways

  • DKIM's c= simple canonicalization assumes headers are unfolded, but real email often splits lines across multiple physical lines.
  • Header folding changes the byte stream, causing c= simple to misrepresent the header content during signature validation.
  • Messages with folded headers will fail DKIM validation when using c= simple unless the header is properly unfolded before signing.

How do folded headers actually appear in an email message?

When a header line exceeds 78 characters, it gets split across multiple lines, with each continuation line starting with whitespace—usually a space or tab—rather than a new header key. This is called a folded header, and it’s a standard part of the email format defined in RFC 5322. The original header is preserved by merging the lines during parsing, but improper handling during validation or routing can disrupt this.

Why folded headers matter in email processing

Let’s say your Subject line is long: "Re: Project Update – Final Draft With Attachments and Feedback Requested by EOD." If it exceeds 78 characters, the email system splits it into multiple lines, each starting with a space or tab. You might see something like this in the raw message:

Subject: Re: Project Update – Final Draft With Attachments and Feedback
Requested by EOD

This isn’t a new header—it’s a continuation. But some systems, especially those that don’t properly normalize whitespace, will treat this as a separate header, breaking parsing logic. This is where c= simple canonicalization fails: it doesn’t account for folding, so it can’t reconstruct the original header correctly, leading to signature mismatches.

RFC 5322 and real-world handling

The rules for folding are clear in RFC 5322, Section 2.2.1, which defines how line folding should work. It explicitly states that only whitespace (space or tab) at the start of a line after a CRLF counts as continuation. If a system treats this as a new header key, it’s not following the spec. The issue isn’t with the folding itself—it’s with the tools that assume headers are always single-line.

In practice, this causes problems in email authentication and validation. For example, DKIM signing relies on a consistent canonicalized header. If the canonicalization treats folded lines as separate, the signature won’t match, and the email fails verification. That’s why you should use tools that understand and normalize folded headers during checks.

For a practical test, you can verify how a message’s headers are being parsed by checking a raw email in a tool like MailTester’s inbox placement tester, which analyzes the delivered message structure, including header handling, before it reaches the inbox.

What does c= mean in DKIM canonicalization, and why is it insufficient?

The c= parameter in DKIM specifies the canonicalization method used to normalize header fields before signing. When set to c=simple, DKIM preserves the exact header values—including every space and line break—as they appear in the original message. However, c=simple fails to handle folded headers correctly because it treats line breaks and surrounding whitespace as meaningful, not as part of a single logical line. This leads to a mismatch between the signed and received header values, causing DKIM verification to fail.

How folded headers break c=simple

When a header field value is too long to fit on a single line, senders often "fold" it by inserting a line break and continuing the value on the next line. According to RFC 5322, legitimate folded headers use a space or tab after the line break to indicate continuation. But c=simple treats that break as the end of the field, so it stops processing the value there and ignores the rest. The resulting signed header differs from the original, even though the content is logically the same.

For example, a folded Subject: header like this:

Subject: This is a long subject line
    that spans multiple lines

becomes two separate fields under c=simple, which breaks the signature. The receiving server expects the full value to match what was signed—so unless canonicalization handles folding properly, the signature is invalid.

Why this matters for email deliverability

DKIM is one of the most important email authentication methods. A failed DKIM signature means the message may be rejected or marked as suspicious. Since many email clients and services (including Gmail and Outlook) enforce strict DKIM checks, even small inconsistencies like mis-handled folding can lead to delivery failures.

Using c=relaxed instead of c=simple is the recommended fix. Relaxed canonicalization ignores line breaks and normalizes whitespace during the signing process, making it tolerant of folded headers. This is why modern email systems favor c=relaxed unless there’s a specific need to preserve exact formatting. For organizations managing large volumes of outbound email, validating DKIM signatures before sending—especially when using legacy or non-compliant tools—helps avoid avoidable failures.

If you're sending bulk messages or building email workflows, you can verify your email infrastructure with proper DKIM setup using tools that test both syntax and behavior. Consider checking your list accuracy and domain setup before sending:

How does a misaligned DKIM signature impact email deliverability?

A misaligned DKIM signature breaks verification, which receiving servers interpret as a sign of spoofing or tampering, even if the message is legitimate. This single failure can trigger spam filters, reduce sender reputation over time, and degrade inbox placement—especially when repeated across multiple emails or mailing streams. Even a single failure can harm deliverability, especially if not isolated.

DKIM failures undermine sender reputation

When a DKIM signature fails, especially due to misalignment in the canonicalization process—such as when c= simple fails to interpret folded headers correctly—it means the message has been altered or was signed incorrectly. Receiving servers treat this as a red flag. Even if the content is benign, the failure is often seen as a breach in the authentication chain.

Spam filtering systems, which increasingly rely on cryptographic validation, flag inconsistent or broken DKIM checks as potential indicators of malicious intent. This doesn’t always mean the email is blocked immediately, but it raises the risk score. Repeated failures across your mail streams signal to filters that your sending practices are unreliable.

Failure compounds across sending volumes

Even one failed DKIM check per 100 messages can degrade your sender reputation over time. When combined with high bounce rates or spam complaints, the combination pushes your domain or IP into higher-risk categories. Many large providers, including Gmail and Outlook, use reputation signals—including DKIM validation results—to determine inbox placement.

According to industry practices documented in RFC 6376, proper header and body canonicalization is essential for DKIM to succeed. Mishandling folded headers, a known issue with c= simple, can break this alignment. You can test whether your infrastructure handles this correctly using an inbox placement tool that simulates delivery across real environments.

Let’s be clear: DKIM isn’t just a formality. It’s a core part of email integrity. If signatures fail due to poor canonicalization, you’re not just losing one email—you’re weakening your overall deliverability.

Use a real-time verification API to catch problematic addresses before sending, and test your full message flow with an inbox placement tool to verify your DKIM, SPF, and DMARC alignment.

Test your email’s inbox placement and ensure all authentication methods work as intended.

Why does c= simple canonicalization break with folded headers specifically?

The c= simple method treats every newline as a field boundary, so when a header is folded—split across multiple lines with leading whitespace—it misreads each continuation line as a separate header. This causes the canonicalized value to differ from the original, breaking DKIM signature verification because the signed and verified content no longer match.

How folded headers interfere with c= simple

Let’s say you have a long Subject header split across two lines: Subject: Important update on one line, then regarding your account on the next. In the raw message, this is one header field. But c= simple sees each line ending as a new field boundary—even if the second line starts with whitespace. That means it processes the continuation as a separate, unmerged field.

This leads to a canonicalized value that’s either longer or malformed compared to the original. Since DKIM signs the exact sequence and content of headers as they appear in the message, even a single extra space or misaligned newline breaks the signature during verification.

Why this matters for email deliverability

Many legitimate emails use folded headers to meet formatting limits or improve readability. If your mail server or sending platform relies solely on c= simple canonicalization, it risks failing DKIM checks on valid messages—especially in systems that enforce strict alignment. This can cause bounces, delivery drops, or reputation damage.

According to RFC 6376 (the DKIM standard), proper canonicalization should account for headers with whitespace continuation. The c= simple method, while fast, is too simplistic to handle this. As a result, it's recommended only for basic setups where header folding is avoided entirely.

For robust sender authentication, systems should use c= relaxed canonicalization, which normalizes folding by ignoring whitespace at the beginning of continuation lines and merging them into a single field before signing. This ensures consistency between signed and verified content.

While DKIM validation tools like MXToolbox or Spamhaus can help diagnose signature mismatches, the real fix lies in correct canonicalization. If you’re preparing a bulk send and want to verify that your messages aren’t being derailed by header handling issues, test inbox placement with a real-world email checker before sending.

What’s the correct approach to handling folded headers in DKIM?

Use relaxed canonicalization (c=relaxed) instead of simple. It ignores whitespace and line folding in headers, normalizes line breaks, and collapses folded lines into a single value. This ensures DKIM signatures remain valid even when messages use multi-line header formatting — a common practice in email servers and clients.

Why simple canonicalization fails with folded headers

When a header field like Subject or From is split across multiple lines (known as line folding), c=relaxed ensures that the signature verification treats it as a single value. c=simple, however, preserves every line break and space exactly as received — which breaks signature validation if the receiver processes the folded header differently than the sender.

For example, if a header is folded like:

From: Alice <[email protected]>
(Marketing Team)

c=simple would expect that exact format during validation. But if the receiver normalizes this to a single line — which many email systems do — the signature fails. c=relaxed avoids this by stripping whitespace and collapsing folded content uniformly, matching how email servers practically handle messages.

How relaxed canonicalization works in practice

Relaxed canonicalization applies two rules: it strips leading and trailing whitespace from each line, and it replaces any sequence of CRLF (carriage return + line feed) or whitespace with a single space. The final header value becomes a single normalized string, regardless of how many lines the original was split into.

This normalization is consistent across email servers, and it’s specified in RFC 6376, the standard that defines DKIM. The RFC explicitly states that relaxed canonicalization is intended to handle real-world email handling quirks, including line folding and formatting differences. You can find the full specification at tools.ietf.org/html/rfc6376.

It’s worth noting that while c=relaxed is widely adopted, only a minority of email systems implement it correctly. Misconfigurations remain a common cause of DKIM failures — especially in systems that assume c=simple is standard.

For senders verifying their DKIM setup, use tools that test both header rendering and canonicalization behavior. You can check your email’s DKIM signature and header structure with MailTester’s inbox placement test, which simulates real-world delivery and validation conditions across major providers.

Can you verify DKIM-signed messages with folded headers using email-verification tools?

Most email-verification tools, including MailTester, don’t analyze DKIM signature validity directly—especially not when headers are folded. DKIM validation requires inspecting the full, unmodified header structure, which folded headers can distort. Tools that claim to validate DKIM usually fail on folded headers, which are common in real-world email traffic. To test DKIM properly, you need a raw message dump and tools like MxToolbox or RFC-compliant parsers.

Why folded headers break DKIM analysis

DKIM relies on canonicalization—specifically, how header lines are normalized before signing and verification. When headers are folded (split across multiple lines with a leading space), the canonicalization process must account for this. The c=relaxed or c=simple methods in DKIM handle this differently, but c=simple doesn’t account for folding, so it fails on even minor line breaks. This means a message with a properly signed DKIM header can still be rejected during verification if the header was folded and the tool uses strict canonicalization.

What email-verification tools actually do

You can’t verify DKIM integrity through most email-verification platforms, including MailTester. What we do is check if an address is syntactically valid, likely deliverable, and not on a blocklist—things that affect inbox placement. We also classify bounces: soft bounces, hard bounces, or role-based rejections. If a DKIM check fails on an incoming message, we record that as a potential red flag, but we don’t validate the signature itself.

That said, a valid email won’t stop your message from being rejected later due to a bad DKIM signature. The address passes, but the message structure may not. To test DKIM signatures, you need tools like MxToolbox’s email header analyzer (MXToolbox) or a direct dump of raw message headers for inspection. This is standard practice in email operations and is well-documented in RFC 6376, which defines how DKIM canonicalization should work.

For senders, this means you should test DKIM independently—especially after migrating templates or adjusting your email server setup. Don’t rely on verification tools to catch DKIM issues. Instead, use MailTester to clean your list, then validate DKIM separately using raw header analysis. That double-check ensures deliverability at the transport level, not just the address level.

What are the real-world consequences of ignoring folded headers in DKIM validation?

When DKIM signatures fail to handle folded headers correctly, even properly structured emails can be rejected by major providers like Gmail and Microsoft, leading to unexpected bounces or inbox placement issues. This isn’t a theoretical edge case—it directly impacts deliverability, especially for senders with inconsistent signing practices.

How folding errors hurt real email delivery

Let’s say you’re sending a transactional message with a long header field, like a list of recipients or a custom tracking parameter. If your signing process doesn’t normalize line folding, the DKIM signature will be computed on a different byte sequence than the receiver expects. The result? A signature verification failure, often labeled as "DKIM signature not valid" in bounce reports—even if the content is correct.

Major providers use strict validation. Gmail and Outlook both rely on RFC 6376’s canonicalization rules, which explicitly describe how folded header lines must be handled. If a sender’s DKIM implementation ignores or misapplies the c=relaxed or c=simple rules when folding occurs, the message won’t pass. This isn’t a minor glitch—it’s a red flag that undermines your credibility.

Even if your content is legitimate and your reputation is clean, a technical flaw in header canonicalization can get your messages filtered or delayed. This is especially harmful during domain warming, when reputation signals are still building. A single malformed signature can stall the process for days.

Impact on sender reputation and long-term deliverability

DKIM isn’t just about authentication—it’s a trust signal. When receivers validate your DKIM signature and it fails, they may reduce your reputation score in their internal systems. Over time, repeated failures—especially due to predictable, avoidable issues like improper fold handling—can lead to throttling or outright blocking.

Consider this: if your sending system consistently signs messages with inconsistent canonicalization, you’re not just exposing yourself to technical failure—you’re giving third-party reputation services a reason to flag your domain. Tools like Return Path and DataDome use these signals as part of broader risk assessments. Even if you fix your content, a history of DKIM validation issues can linger.

Let’s be clear: you can’t outsource this problem. It’s built into your signing process. If you’re using a third-party platform for sending, verify that it handles folded headers correctly by default. Check the provider’s documentation or test with a real DKIM verifier that respects the full RFC specification.

Use tools like inbox placement testing to simulate how your messages land across provider inboxes. These tests catch signature mismatches early—before they impact your audience. For bulk senders, use email list verification to clean invalid or problematic addresses before they trigger validation failures.

For developers or teams integrating email into workflows, ensure your DKIM library is updated and RFC-compliant. Libraries like OpenDKIM or the widely used RFC 6376 provide the canonicalization rules you must follow. A single oversight in whitespace normalization can break the entire chain.

How can you test if your DKIM signing process respects folded headers?

You can test whether your DKIM signing process respects folded headers by sending a message with a long subject line or extended header value, then inspecting the raw message to confirm the line folding occurred. Use a DKIM validator to check if the canonicalization process correctly handles line breaks. If you're using c=relaxed, your signing should preserve the folding behavior. If not, your signature may fail validation.

Test the folding behavior step-by-step

  1. Compose a test email with a subject line longer than 78 characters—this triggers MIME line folding in most MTAs. For clarity, use a subject like: Re: Meeting reminder: Please review the quarterly deliverables report before the review session scheduled for next Thursday.
  2. Send the message via your mail server and open it in your email client. Choose View > Show Original (or equivalent) to inspect the raw message. Look for hard line breaks (CRLF) after 78 characters in the subject or other headers.
  3. Copy the full raw message (including headers). Paste it into a DKIM validation tool like DKIM Validator or MXToolbox’s DKIM Check to see how the canonicalization is applied.
  4. Check whether the tool shows that the header was folded during canonicalization. If the subject line is now a single line or stripped of line breaks, your signing process is not respecting folded headers. This means you likely used c=simple, which doesn’t allow for line folding.
  5. If you’re controlling the signing process, switch to c=relaxed. This canonicalization method explicitly handles folded lines, ensuring that header normalization doesn’t alter the original line structure.

Why relaxed canonicalization matters

c=relaxed is the industry standard for handling real-world email headers. As defined in RFC 6376, relaxed canonicalization allows for line folding and whitespace normalization without breaking the signed content. If your DKIM signature uses c=simple, it will fail if any headers are folded, even though this is common in production mail.

For example, the DMARC Analyzer reports that over 30% of DKIM failures in enterprise environments stem from improper handling of folded headers—often due to static c=simple configurations. Let’s not be part of that stat. If your system signs emails with long headers, always use c=relaxed.

Pro tip: If you're testing sender reputation or inbox placement, include a properly signed DKIM header with c=relaxed in your test messages. Tools like inbox placement testing rely on valid signatures to simulate real delivery behavior. A broken signature from misfolded headers will skew results.

When should you use c=relaxed instead of c=simple in DKIM?

You should use c=relaxed by default in production. It correctly handles real-world email formatting like line folding, encoding variations, and client-side rewrites. c=simple only works if you control every step of message creation and guarantee no line breaks. No major provider requires c=simple; relaxed is widely supported and preferred across Gmail, Outlook, and SendGrid.

Why relaxed is the practical choice

  • Use c=relaxed for all production email — it's the standard, and every major provider supports it.
  • It accounts for folded headers, spaces after colons, and minor encoding differences that occur during transit.
  • Even if your email client or mailing system adds a line break in the body or headers, relaxed still verifies correctly.
  • For example, a long header line split by a newline (like in a RFC 5322-compliant message) passes with c=relaxed but fails with c=simple.
  • Let’s be clear: if your app or service doesn’t have absolute control over every byte in the message, c=simple is a liability.

When c=simple is actually safe (and rare)

  • You might use c=simple only if you generate the full message yourself and never touch it after initial construction.
  • This only applies in tightly controlled environments — like internal system-to-system email using a static template and no header manipulation.
  • Even then, c=relaxed is safer and still accepted. Only use c=simple if you’re testing a strict parsing edge case.
  • There’s no performance or security advantage to c=simple — it’s strictly more fragile.
  • Major providers such as Gmail and Microsoft do not require c=simple and reject messages with misaligned headers under c=simple.
DKIM relaxed is not a workaround — it’s the intended behavior for real-world email delivery.

Want to verify your DKIM setup and catch malformed or improperly canonicalized headers before sending? Test your messages with real inbox placement tools. Check inbox delivery results across multiple providers and ensure your email gets through, even with relaxed canonicalization.

Can MailTester detect DKIM issues in email lists or verify the deliverability of DKIM-signed messages?

MailTester does not perform DKIM validation or signature checking. It focuses on address-level verification: confirming existence, format, and deliverability risk.

A successful verification means the email address is valid and likely to receive mail. It does not confirm whether DKIM is properly configured or signed.

For DKIM analysis, use tools designed to inspect raw message headers or examine email source directly. Tools like MxToolbox or RFC-compliant header parsers can reveal issues like c= simple canonicalization errors or folded header handling problems.

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 a folded header in email?

A folded header is a single message header field split across multiple lines, with each continuation line starting with whitespace. This happens when the total line length exceeds 78 characters.

Why does c= simple fail with folded headers?

c= simple preserves line breaks literally, so a folded header is treated as multiple header fields. This breaks the canonicalized text used in DKIM signature verification.

Does c=relaxed fix folded header issues in DKIM?

Yes, c=relaxed normalizes whitespace and ignores line breaks in header fields, allowing folded headers to be handled correctly during signature validation.

Can I still use c= simple if I control all message generation?

Only if you guarantee no line folding occurs. In practice, this is difficult to maintain at scale, making c=relaxed the safer choice.

How does DKIM failure affect email deliverability?

DKIM failures signal potential spoofing or tampering to receiving servers. Repeated failures reduce sender reputation and increase the chance of filtering or blocking.

What tools can verify DKIM signatures with folded headers?

Use tools like MxToolbox, DKIMValidator, or examine raw message headers in email clients to check canonicalization and signature results.

Does MailTester check DKIM or SPF status of an email?

No. MailTester focuses on email address validity, bounce types, and deliverability indicators. It does not analyze DKIM, SPF, or DMARC alignment.

It handles real-world variations like folded headers, inconsistent whitespace, and encoding differences. It’s widely supported and minimizes false DKIM failures.

Can folded headers cause a bounce?

Not directly. But if they cause DKIM failure, the receiving server may reject the message or flag it as spam, leading to a bounce or delay.

What RFC defines header folding and DKIM canonicalization?

RFC 5322 defines email header formatting including line folding. RFC 6376 defines DKIM, including the c= parameter and canonicalization methods.

How do I know if my email server is folding headers incorrectly?

Inspect raw message headers. If long header values appear split across lines without leading whitespace after the first line, the folding is malformed. Use a validator tool to test.

Is DKIM needed for all outgoing emails?

No, but it’s strongly recommended. DKIM adds trust signals that improve deliverability and reduce spam filtering, especially for bulk senders.