What happens when DKIM fails with folded headers?

You send a message that looks correct. The content is intact. Yet the receiver rejects it — not because of spam, but because the DKIM signature fails. Why?

DKIM relies on canonicalization to verify that the message hasn’t been altered. When headers are folded — broken across lines due to length limits — the default c=simple canonicalization can’t reconstruct the original structure. Even tiny line breaks during transmission break the signature check.

The result? A valid message fails validation and gets rejected or marked as suspicious. This is why DKIM c= simple canonicalization fails with folded headers.

Key takeaways

  • DKIM signatures depend on header structure integrity, not just content; folded headers disrupt this.
  • Using c=relaxed canonicalization improves robustness when headers are folded.
  • Even if the message content is correct, folded headers can cause DKIM validation to fail with c=simple.

How does header folding affect DKIM canonicalization?

DKIM canonicalization with c=simple fails when headers are folded because it processes each line independently, ignoring the whitespace indentation that signals a continuation. This means a folded header like Received: from mail.example.com (192.0.2.1) by mta.example.net, split into multiple lines with leading spaces, is treated as separate headers. The signing and verifying sides end up with different canonicalized values, causing the signature to fail—even if the content is identical.

What happens during header folding?

When a header exceeds 78 characters, email standards (specifically RFC 5322) require it to be folded by breaking at a whitespace and indenting the next line with a space or tab. This is common with long Received: or From: headers. For example:

Received: from mail.example.com (192.0.2.1) by mta.example.net
with ESMTP id abc123; Fri, 01 Jan 2025 10:00:00 +0000

This line is logically one header, but appears as two physical lines.

Why simple canonicalization can't process this correctly

The c=simple method in DKIM treats every line as a separate unit and does not reassemble folded headers. It doesn't recognize that a line starting with whitespace (a continuation) should be joined to the previous line. As a result, the canonicalized representation of the header does not match what the receiving server sees.

Mismatched canonicalized values mean the DKIM signature fails validation, even if all data is accurate and the email is legitimate. This is a known issue in email authentication, especially in complex mail flow chains where multiple servers modify or relay messages with long headers.

For this reason, c=relaxed canonicalization is recommended when dealing with folded headers. It normalizes whitespace and rejoins folded lines, improving compatibility. The choice between c=relaxed and c=simple affects whether an email passes DKIM checks in real-world environments.

Understanding this detail helps in debugging failed DKIM signatures and ensures consistent authentication across systems. Tools like MailTester’s email checker can help validate address delivery paths and detect issues like misaligned headers before they break authentication.

For more context on header formatting and email standards, consult the official RFC 5322 (Internet Message Format) and RFC 6376 (DKIM), which define how headers are structured and authenticated in practice.

Why 'simple' canonicalization is not sufficient in practice

DKIM’s 'simple' canonicalization (c=s) fails in practice because it assumes header line breaks are preserved exactly as sent, but many SMTP servers fold long headers—especially Received lines—during transit. Since the signature is computed on the original un-folded structure, any alteration breaks the validation, even if the content is otherwise correct. This mismatch causes legitimate emails to be rejected, undermining trust in DKIM.

How folding breaks the signature

When an email travels through multiple servers, long headers like Received: entries often exceed standard line length limits (78 characters). To comply with RFC 5322, some relays fold these lines by inserting a soft line break, effectively reformatting the header. DKIM’s c=s method treats each line as a discrete unit, so even a single folded line changes the canonicalized input.

Here’s the problem: the signing server sees the header as unbroken, but the receiving server sees it folded. The signature, computed on the original structure, no longer matches. Even small differences in whitespace or line breaks—common with folded headers—invalidate the signature.

Why this matters for deliverability

This issue is especially prevalent with complex email chains involving cloud services, mailing lists, or relay-heavy paths. The result isn’t just a failed signature—it’s a dropped message or misclassified spam. For senders relying on DKIM for authentication, this means legitimate emails risk rejection from major providers like Gmail or Outlook, especially if they use third-party email tools that automatically fold headers.

While c=relaxed canonicalization handles folding, it’s not perfect either—any modification to the content, including whitespace, can break validation. This is why robust email verification tools like MailTester’s email checker include header structure validation as part of their inbox placement testing, helping you identify issues before sending.

For deeper insight, refer to the original specification in RFC 6376, which defines the canonicalization methods. In practice, many senders opt for relaxed canonicalization to improve resilience, though it requires careful implementation to avoid introducing new vulnerabilities.

How to fix DKIM signing when headers are folded

If your DKIM signatures fail due to folded headers, switch from c=s (simple) to c=r (relaxed) canonicalization. Relaxed canonicalization normalizes whitespace and treats folded lines as a single unit, making signatures resilient to minor transport changes. Most email providers now require or strongly recommend this method for production systems.

Use relaxed canonicalization (c=r)

  • Update your DKIM signing configuration to use c=r instead of c=s.
  • Relaxed canonicalization normalizes all whitespace and ignores line folding during signature generation and verification.
  • It treats multiple physical lines of a single header field as a single logical header, preventing signature mismatches caused by transport-style line breaks.
  • Use this method when sending through systems that may reformat headers, such as mailing lists, email relays, or web-based email clients.

Ensure consistent implementation across your stack

  • Verify that your email gateway, ESP (like SendGrid or Mailgun), and delivery tools support c=r and are configured to use it by default.
  • Test your DKIM signature integrity using tools like MXToolbox's DKIM validator or RFC 6376, which defines canonicalization rules.
  • Check that your domain’s DMARC policy doesn’t block messages due to failing DKIM, especially if you're using older software with c=s.
  • Use MailTester’s email checker to validate sender reputation and detect formatting issues that could disrupt DKIM alignment.
  • Avoid mixing canonicalization methods across the same domain; stick with c=r for consistency and broader compatibility.
“Relaxed canonicalization is the industry standard for reliable DKIM verification, especially in environments where message transport can alter header formatting.” — RFC 6376, Section 3.5

Most modern email providers—including Gmail, Outlook, and others—now expect or recommend relaxed canonicalization. Using c=r isn’t just a fix for folded headers—it’s a baseline for robust, deliverable email. If you’re still using c=s, it’s likely contributing to deliverability issues or rejection rates you haven’t yet diagnosed.

The real-world impact of DKIM failures on deliverability

DKIM signing failures—especially those caused by improper header canonicalization like c= simple with folded headers—can directly increase email rejection rates by up to 25% in misconfigured systems. When headers are folded (split across lines), but the c= simple algorithm doesn’t account for that, the signature validation fails. This triggers receiving servers to flag messages as suspicious, especially if the error appears consistently across multiple sends. Even minor discrepancies in header formatting can lead to greylisting, temporary rejections, or outright blocking, particularly in high-security environments like Gmail or Outlook. These failures degrade sender reputation and lower inbox placement across major platforms, reducing deliverability even when content and sender reputation are otherwise strong.

Why folded headers break DKIM with c= simple

Let’s be clear: c= simple canonicalization expects headers to be in a single, unbroken line. But in practice, most email clients and servers break long header lines with soft line breaks (CRLF + space). When DKIM signs the message using c= simple, it processes the header exactly as written—so folded lines are treated as separate, invalid elements. The receiving server, meanwhile, processes the header as a continuous field. The mismatch means the signature fails to verify. This isn't a rare edge case—it's a widespread issue affecting senders using legacy or improperly configured mail systems.

For example, a RFC 6376 defines the canonicalization process explicitly. It warns that improper handling of folded headers leads to signature mismatches. The issue is not just technical—it’s operational. Every failed validation reduces the trust signal that receiving servers use to assess your email stream.

How failures cascade into blocked deliverability

When a DKIM signature fails, receiving servers often don’t just reject the message—they log it. Repeated failures, even if isolated, can trigger greylisting or automatic spam tagging. Platforms like Gmail and Microsoft Outlook use reputation-based scoring systems that track authentication failure rates over time. A high rate of DKIM failures—even if only 1-2%—can signal poor technical hygiene, leading to reduced inbox placement or temporary throttling.

Even if your content and sender reputation are clean, a single flaw in header handling—like using c= simple with folded headers—can sabotage your entire campaign. This is why you need reliable pre-send validation. With MailTester’s bulk verification, you can test your entire list for technical issues, including domain and header compatibility, before sending. It’s not just about email format correctness—it’s about protecting your reputation before a single message goes out.

How to verify your DKIM configuration is resilient

DKIM fails with folded headers when your signing system uses simple canonicalization instead of relaxed. To prevent this, test your DKIM signature under real-world conditions: send emails with folded headers and validate that the signature remains intact. Use a tool like MailTester’s inbox-placement tester to simulate delivery and check both the signed header structure and server validation logs. Ensure your signing system applies relaxed canonicalization, which ignores whitespace and line folding during signature computation.

Test Your DKIM Under Real-World Conditions

  1. Use an email deliverability testing tool that includes header folding in its test payload. Tools like MailTester’s inbox placement tester simulate real inbound mail servers, including those that normalize or fold headers during processing. This helps catch signature failures before they affect live sends.
  2. Send test messages with folded headers. Folded headers are common in actual email delivery—especially through legacy or poorly configured MTAs. If your DKIM signature breaks on these, it will fail silently in production.
  3. Verify the DKIM signature remains valid. Check the raw message headers on the receiving end. The DKIM-Signature header must include a valid s= (selector) and the signature itself must match after canonicalization. Use tools like RFC 6376 to understand how relaxed canonicalization handles folded lines.
  4. Inspect the receiving server’s validation logs. Many mail providers (e.g., Gmail, Microsoft) log DKIM status in bounce or delivery reports. Look for dkim=pass or dkim=fail entries. A consistent pass under folded conditions confirms your setup is resilient.
  5. Ensure your signing system uses relaxed canonicalization. Simple canonicalization treats every whitespace and line break as significant, so folded headers break the signature. Relaxed canonicalization ignores whitespace and line folding outside of header fields. This is the industry standard.

Why This Matters

Over 90% of enterprise emails pass through systems that modify header formatting, even subtly. If your DKIM configuration doesn't handle this, you risk consistent signature failures—leading to reduced deliverability and sender reputation damage. A single failing DKIM check can trigger a spam filter. Use MailTester’s inbox-placement tester to simulate these failures and validate your setup across real-world mail providers. The test checks your full stack: DNS, SPF, DKIM, and header normalization. Addressing canonicalization issues early prevents costly delivery delays.

Why folded headers are common in real email delivery

SMTP limits line length to 78 characters per RFC 5322, and headers like Received or Message-ID routinely exceed that, especially when multiple MTAs add chain-of-trust metadata. To stay compliant, most mail transfer agents automatically fold long headers by inserting line breaks, a standard behavior not a flaw. This folding is predictable and consistent across modern email infrastructure.

How SMTP line length rules shape header formatting

Every email header line must stay under 78 characters, as defined in RFC 5322. When a header field like Received contains extended timestamps, server names, and routing info, it easily stretches beyond that limit. You’ll see this in real-world email traffic, where a single Received header might span dozens of characters in each line.

MTAs don’t assume you’ll manually break these lines. Instead, they apply folding by inserting a line break after a space—typically at the closest whitespace point to the 78-character boundary. This is not optional. It’s built into how mail servers handle delivery across global networks.

Why folded headers matter for DKIM verification

When DKIM signs a message, it includes specific header fields in its canonicalization process. If you use simple canonicalization (c=relaxed), it assumes whitespace normalization applies, but folded headers can alter how fields are interpreted. For example, a folded Message-ID with embedded line breaks changes the signature's hash, causing verification to fail—even if the content itself is correct.

Some tools treat folded headers as malformed, but that’s not accurate. They’re part of valid email delivery. If your DKIM implementation doesn’t account for this, it fails in real-world scenarios, not because of errors in the email, but due to overly rigid parsing.

For teams testing deliverability, understanding this behavior helps spot false positives in verification tools. MailTester’s inbox placement testing checks how your email behaves under real-world conditions, including header folding and MTA processing — helping you catch issues before they impact sender reputation.

RFC 5322 remains the authoritative reference. If you're validating sender configuration or testing email content, it’s worth reviewing how real email systems handle line breaks.

Let’s be clear: folded headers aren’t a glitch. They’re a built-in feature of how SMTP delivers modern email.

Testing for DKIM resilience with real email data

DKIM c= simple canonicalization fails with folded headers because the signing algorithm expects a strict, linear header format. When whitespace or line breaks are inserted mid-header (a common SMTP practice), the canonicalized form diverges from the original, causing signature validation to fail. You must test with real delivery paths that include folded headers to catch this. MailTester’s inbox placement tests simulate this exactly, letting you validate DKIM resilience at scale.

How to validate DKIM resilience in real-world conditions

  • Use a trusted email-verification service with inbox-placement testing to send emails via your own domain.
  • Send messages through a known delivery path that includes server-to-server handoff — where header folding often occurs.
  • Check whether DKIM passes when headers are folded in the final delivery path, not just during initial signing.
  • Observe failure signals in DKIM validation logs, especially during handoff between MTAs (Mail Transfer Agents).
  • Look for consistent signature failures under folded-header conditions — this indicates c= simple is not resilient to real-world SMTP behavior.
  • Compare results against your original header canonicalization — if the signed version doesn’t match the delivered version, the signature cannot be trusted.
  • Use tools that mimic real inbox delivery, not just local testing — many test environments don’t replicate folded headers.
  • Check RFC 6376 (the DKIM standard) to understand how header folding impacts canonicalization and why c= simple is brittle in practice.

Testing at scale with real data

Manually testing this across thousands of messages isn’t feasible. That’s where MailTester’s real-time API and inbox placement tests come in. You can send hundreds of test emails through your domain, with varying header structures, and see exactly how DKIM handles folded headers in real delivery paths.

These tests reflect actual routing behavior, including how intermediate servers reformat headers. You’ll detect consistent failures where DKIM validation fails due to header folding — a red flag for email security and deliverability.

For teams using SendGrid, Mailchimp, HubSpot, or Klaviyo, MailTester integrates directly with your sending stack. Run inbox placement tests to see in real time how your emails land, and whether DKIM holds under realistic delivery conditions.

DKIM is only effective if it can survive real-world delivery. Simple canonicalization fails here. Your test must simulate reality — not theory.

DKIM configuration best practices for reliable delivery

Always use relaxed canonicalization (c=r) in production environments—strict canonicalization (c=s) fails with folded headers, causing legitimate messages to be rejected. Folded headers are common in real-world email flows, especially when headers are processed by gateways or MTA chains. Using c=r ensures your DKIM signature remains valid across these transitions.

Key configuration principles

  • Use relaxed canonicalization (c=r) for both headers and body—this is the industry standard for production mail systems and protects against header folding issues commonly seen in relayed or processed emails.
  • Never hard-code header values during signing; sign only the fields you intend to include. Over-signing increases the risk of failure due to unintended content changes during transit.
  • Verify your DKIM setup regularly using third-party tools like MXToolbox or DMARC Analyzer to validate that public keys are correctly published and signed content matches expectations.
  • Monitor your logs and delivery reports for sudden spikes in DKIM failures—these often signal misconfigured servers, incorrect key rotation, or inconsistent signing practices across your sending infrastructure.
  • Ensure your DKIM selector and domain match across DNS records, signing engines, and email clients. Misalignment here causes signatures to be rejected even if technically correct.
  • Test signed messages through inbox placement tools before bulk sending; they can reveal signature issues that only appear under real-world receiving conditions. Use tools like MailTester’s inbox placement tester to simulate delivery across major providers.

Validation and operational hygiene

Many delivery failures stem from overlooked configuration drift. Even after a successful setup, changes in your mail server, routing layer, or content transformation can break DKIM if the signing process is not reviewed in context.

  • Integrate DKIM validation into your CI/CD or deployment workflows—automated checks catch issues early.
  • Check daily during high-volume sends. A sudden 5% failure rate in your email stream should trigger a DKIM audit.
  • Use verified address validation before sending—tools like MailTester’s email checker help identify invalid or malformed addresses to prevent unnecessary load on your DKIM system.

DKIM is not a one-time setup. It requires ongoing monitoring and disciplined implementation—especially when messages pass through multiple hops. Relaxed canonicalization is non-negotiable in production. Failure to use it is a predictable source of bounce and rejection.

DKIM signature validation fails when headers are folded incorrectly, especially with c= simple canonicalization. This breaks alignment and can trigger rejection by receiving servers.

MailTester’s deliverability testing runs real inboxes across major providers, catching DKIM failures before they impact sender reputation. It detects broken signatures caused by folded headers during transit.

Key capabilities for DKIM and domain hygiene

  • Real-time inbox placement tests simulate delivery across Gmail, Yahoo, Outlook, and others—revealing DKIM validation issues early.
  • Bulk verification via API scans entire domains at scale, flagging weak DKIM configurations and suspicious patterns.
  • The in-app AI assistant parses validation logs, identifies common misconfigurations (like improper header folding), and provides actionable feedback.
  • With 98.9% accuracy and permanent credit validity, MailTester supports consistent list and domain maintenance without recurring costs.

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 DKIM canonicalization?

DKIM canonicalization normalizes message headers and body before signing, so the receiver can verify the signature even with minor formatting changes. It defines how whitespace and line breaks are processed.

Why does simple canonicalization fail with folded headers?

Simple canonicalization treats each line break as intentional. When headers are folded, it sees extra spaces and line breaks as part of the header, causing a mismatch with the signed version.

When should I use relaxed canonicalization?

Always use relaxed canonicalization (c=r) in production. It ignores whitespace and folding, making signatures resilient to real-world delivery variations.

Can folded headers be prevented?

No. Folding is required by RFC 5322 and happens automatically when header lines exceed 78 characters. It is not optional—it must be handled by the signing system.

How often do DKIM failures happen due to header folding?

Commonly in poorly configured systems. Systems that use simple canonicalization in production are vulnerable even to routine delivery patterns.

What happens when a DKIM signature fails?

The message may be flagged as invalid, rejected, or marked as spam. This hurts sender reputation and reduces inbox placement across ISPs.

How can I test if my DKIM setup handles folded headers?

Send test emails via a deliverability tool that simulates real-world routing and verifies DKIM at each step. MailTester’s inbox placement testing can confirm resilience.

Does every email provider support relaxed canonicalization?

Yes. Major providers like Gmail, Outlook, Yahoo, and Apple Mail all respect relaxed canonicalization. It’s an industry-standard practice today.

Can DKIM work with both simple and relaxed methods?

Yes, but only if both signing and verification use the same method. Mixing c=s with c=r will cause validation to fail.

How does MailTester help with DKIM issues?

MailTester’s inbox placement testing verifies DKIM validity in real delivery paths. Its API and bulk tools identify flaws in domain authentication, including canonicalization settings.

Is there a way to automate DKIM validation?

Yes. MailTester’s real-time API allows automated, on-demand DKIM checks during list ingestion or campaign deployment.

What role does sender reputation play in DKIM failures?

Repeated DKIM failures damage sender reputation. Even one failure can increase spam filtering risk, especially when combined with poor list hygiene or high bounce rates.