What happens when DKIM c= simple can’t parse folded headers?

You sent a perfectly valid email. The content is clean, the sender is trusted, and the domain has strong reputation. But the recipient’s mail server rejects it—just because a header line was split across two lines with indentation. Why?

Because DKIM c= simple can’t handle folded headers in the body. It relies on a strict, unaltered header format during signature creation. When a header is folded—broken into multiple lines with whitespace—it breaks the canonicalization process. The result? A failed DKIM validation, even if the email is harmless and legitimate.

Key takeaways

  • Drafting tools that insert whitespace into headers can break DKIM c= simple signatures, even if the email content is correct.
  • DKIM c= simple canonicalization expects headers to be in a single line with no line breaks—any folding invalidates the signature.
  • Emails with folded headers may fail delivery even if the sender is reputable, due to strict canonicalization rules in c= simple.

Why does DKIM c= simple exist, and why is it flawed?

DKIM’s c=simple canonicalization was designed to simplify signing and verification by assuming all headers are single-line — no folding allowed. This reduced ambiguity in canonicalization, especially on older mail systems that lacked robust parsing. But in practice, many email clients and servers fold long headers like Received: or Content-Type: across multiple lines, breaking the assumption and causing DKIM verification to fail even when the message is valid.

The Technical Trade-Off: Simplicity vs. Reality

Let’s be clear: c=relaxed exists to handle folded headers by normalizing whitespace and line breaks. But c=simple doesn’t. It treats each header as one line — any line folding, no matter how minor, invalidates the signature. This was a pragmatic choice in the early 2000s when many systems couldn’t reliably parse multi-line headers.

Today, modern email infrastructure still processes header folding regularly. A single line break in a Received: header, often added by a relay or forwarding service, can break DKIM entirely — even if the content is unchanged. This means legitimate messages fail verification simply because of formatting that’s common across the internet.

Where This Breaks in Real Systems

You’ll see this issue when debugging deliverability problems. A message passes all checks, but DKIM fails — not because of tampering, but because a header was folded. This isn’t rare. It’s common in email chains with multiple relays, automated systems, or mobile clients that insert line breaks.

While RFC 6376 (the DKIM specification) acknowledges this issue, it also recognizes c=relaxed as the recommended canonicalization method for robustness. Using c=relaxed allows for more predictable results across real-world delivery chains. The persistence of c= simple in many tools reflects legacy design choices, not current best practice.

When you’re auditing your email infrastructure or checking sender reputation, ensuring correct DKIM setup is essential. Tools like MailTester’s email checker help verify whether addresses are valid and properly configured before sending, reducing the risk of delivery failure due to cryptographic mismatches.

How does header folding damage email deliverability?

When a header is folded—broken into multiple lines with a soft break—its content can change in ways that confuse DKIM's c= simple signature validation. Even if SPF and DMARC pass, a folded header can cause DKIM to fail because c= simple checks the exact byte sequence. This mismatch triggers spam filters, which treat inconsistent signatures as signs of spoofing, even when your domain is clean. The result? Your email gets rejected, delayed, or dumped into spam without a clear reason.

Why folded headers break DKIM’s c= simple verification

DKIM verifies the digital signature by comparing the signed header fields exactly as they appear in the message—no exceptions. When headers are folded with line breaks and whitespace, the canonicalized form differs from what the signature was created with. The c= simple canonicalization mode assumes a linear, unbroken header. Any deviation in line breaking or whitespace causes a verification failure, even if the content is identical.

For example, a Subject: line split across two lines with a soft break introduces extra spaces or carriage returns. The signature, generated from the original unbroken string, no longer matches. This isn’t a flaw in your email—it’s a protocol mismatch. Yet, filters see this as a red flag: intentional signature tampering is rare, but signature mismatches are common in phishing.

According to RFC 6376, canonicalization is central to DKIM’s integrity. Deviations from expected form, even minor formatting changes, invalidate the signature. This is why proper header formatting is non-negotiable.

How this impacts delivery and reputation

Even if your domain has strong sender reputation, a DKIM failure due to header folding can trigger rejection by receivers. Major ISPs like Gmail and Yahoo monitor signature consistency closely. One failure may not blacklist you, but repeated issues suggest a misconfigured sending system. This can lower inbox placement rates over time, especially if multiple emails in a batch fail DKIM validation.

Let’s be clear: this isn’t about being "blocked." It’s about being silently filtered. You may not see bounces, but your open rates will drop. Recipients never see your message, and there’s no feedback loop to tell you why.

Prevent this by validating your email structure before sending. Use tools like inbox placement testing to catch canonicalization issues before they affect deliverability. For large volumes, run a bulk verification to clean out invalid or malformed addresses early. With email verification, you’re not just checking addresses—you’re checking for deliverability readiness.

What happens to messages with folded headers in real-world systems?

When a message uses DKIM with c=simple, it relies on the exact format of headers as they were signed. If the receiving server folds long header lines—something common in real-world SMTP delivery—the signature validation fails, even if the content is otherwise correct. This is why identical messages can succeed in one inbox and fail in another, depending not on the sender’s setup, but on how intermediate servers handle line breaks during transit.

Why folding breaks DKIM with c=simple

DKIM's c= tag defines how signing and verification handle whitespace and line folding. With c=relaxed, both sender and receiver normalize whitespace, so folded headers don't break verification. But c= simple demands an exact match: same line breaks, same spacing. If the original header was sent on a single line but gets folded by an intermediate mail server like Gmail, Outlook, or AWS SES during delivery, the signature no longer matches the received content—validation fails.

Let’s say you sign a message with c= simple and send it through a mail relay that reformats long header lines. The server splits a 120-character header into two lines—common practice in RFC 5322-compliant systems. The signature was created assuming that line stayed intact. Now the verifier sees a different text, and DKIM refuses it. Even if the sender’s domain, SPF, and DMARC are correct, this one mismatch breaks the chain.

How this shows up in practice

You might notice this issue when testing emails across platforms. A mail sent via a test environment might work fine in a local simulator or a debug tool, but bounce or fail inbox placement when sent live. The problem isn’t in the signing setup—it’s in how real-world systems handle header formatting between the sender and final recipient.

This is why major email providers and cloud email services, including Amazon SES and Google’s infrastructure, always fold long headers as part of their message processing. The folded format is RFC-compliant and widely used. If you’re using c= simple, your message is at risk—unless every relay preserves line breaks exactly.

If you're not certain whether your DKIM setup is resilient to these changes, test the full end-to-end delivery path with tools that simulate real inbox behavior. MailTester’s inbox placement test checks how your message appears in real inboxes, including authentication status and header normalization risks.

Can you fix a DKIM c= simple failure caused by header folding?

No, you cannot fix a DKIM c= simple failure caused by folded headers without re-signing the message using the c= relaxed method. The original signature assumes headers are not folded, so any folding breaks the canonicalization match. The only reliable way to validate folded headers is with a relaxed signature method that ignores whitespace and folding during verification.

Why folding breaks c= simple

DKIM c= simple treats every character in a header exactly as it appears. When a header line is folded—split into multiple lines with a newline and whitespace—the signature is computed over the original, unfolded form. If the receiving server processes the folded version before validation, the hash no longer matches. The server sees a different text stream and rejects the signature.

Even small changes—like adding a space after a newline—alter the canonicalized content. So if your email system or relay folded headers after signing, that’s enough to invalidate the signature, regardless of how correct the original content was.

The solution: re-signing with relaxed header processing

Let’s be clear: once a message is signed with c= simple and later folded, the signature is effectively broken. You can’t retroactively "fix" it. The only way to handle folded headers correctly is to use c= relaxed for signing. This method normalizes whitespace and ignores line breaks during canonicalization, making the signature resilient to folding.

Only systems that support relaxed header processing can properly validate a c= relaxed signature. If your sending infrastructure or email service applies c= simple, it will fail on folded headers—even if the content is valid.

According to RFC 6376, Section 3.2, c= relaxed is specifically designed to handle real-world email delivery quirks like header folding and whitespace normalization. A system that skips this step isn't just being strict—it’s incompatible with how most email is delivered.

If you're seeing DKIM failures due to folding, the root issue is likely your signing method. You must re-sign messages using c= relaxed if folding is unavoidable. Tools that validate DKIM signatures—like the ones built into MailTester’s inbox placement tester—can help you detect this issue before sending.

How does mail verification catch this before it goes to senders?

MailTester’s bulk verification API doesn’t just check if an email format is valid—it tests whether your message will actually pass real-world delivery checks, including DKIM validation. It simulates the full delivery path and flags addresses where folded headers in the body will break DKIM signatures, even if the address itself is technically correct. This prevents you from sending to recipients who’ll reject your email due to a failed signature.

Simulating real delivery conditions

DKIM signatures are sensitive to whitespace and header folding. When a message body contains folded headers—especially if they’re malformed—some mail servers detect the change and reject the signature, even if the email address is clean. This isn’t a problem with the address; it’s a problem with the message structure.

MailTester runs your message through this exact test. It doesn’t just validate the address. It parses the full MIME structure, checks for header folding in the body, and validates the DKIM signature under the same conditions that real mail servers apply. If your message won’t pass DKIM in production, MailTester catches it before a single email is sent.

Why format matters, even when addresses are valid

Many tools stop at “valid email format.” But that’s only part of the story. A valid address can still receive your email—only to have it bounce due to a DKIM mismatch caused by folding in the message body.

We’ve seen cases where a mailing list passed basic validation but failed delivery at scale because of this issue. The problem isn’t the address. It’s the message. MailTester’s verification API detects these edge cases by reconstructing the message in a way that mimics actual sending environments.

It’s not just about syntax. It’s about delivering messages that will pass every stage of the inbox delivery pipeline—starting with DNS, SPF, DKIM, and content formatting. You can check individual addresses with our email checker or verify entire lists with our bulk verification tool, both of which include real-world test signals.

What’s the role of SPF, DKIM, and DMARC when header folding occurs?

SPF doesn’t care about headers at all—it only checks the sending IP. DKIM with c= simple fails when headers are folded because it validates the exact byte sequence. DMARC depends on both SPF and DKIM; a DKIM failure from folding can cause DMARC to reject the email. Since folded headers are common in real-world messages, using c= relaxed in DKIM is essential for reliable validation.

How each protocol handles folded headers

Let’s break down what happens when a header is split across multiple lines—common in email clients and some servers, but a known source of validation errors.

Protocol Checks Handles folded headers? Why it matters
SPF Source IP address Yes (ignores headers entirely) SPF only cares about where the email came from—headers don’t affect its check. It never fails due to folding.
DKIM (c= simple) Exact header content and body No Even a single line break where one wasn’t expected breaks the signature. This is why c= simple is unreliable in production mail flows.
DKIM (c= relaxed) Header field values with whitespace normalization Yes It treats folded lines the same as continuous ones, so folding doesn’t cause failure. This is the standard for real-world use.
DMARC SPF and DKIM results Indirectly depends on DKIM If DKIM fails due to folding, DMARC fails even if SPF passes. This can trigger rejection by receiving mail servers.

Because DKIM c= simple fails on folded headers, you'll see false positives in validation if you're testing against real-world messages. According to RFC 5322, line folding is legitimate and common—so any system that treats it as invalid is misconfigured.

How to ensure your emails pass validation

Use DKIM with c= relaxed — not c= simple. That’s mandatory for reliable sender reputation checks. You can test this by running a real email through a deliverability checker that validates signatures end-to-end. If your DKIM fails only on folded headers, you’re using the wrong canonicalization method.

Always verify your DNS records and signing setup with tools that simulate actual email processing. Use an email verification service like our API to catch issues before mass sends, especially when dealing with third-party mailers or legacy systems that modify headers.

How to avoid DKIM c= simple issues in your email infrastructure?

DKIM c= simple fails when headers are folded—common in modern email systems—because it checks the exact byte sequence. Always use c= relaxed for signatures sent through systems that may reformat headers, as it ignores whitespace and line breaks. This prevents false negatives in signature validation and ensures consistent alignment. You don’t need to switch all your signatures overnight—just correct the ones sent through services that fold content.

Use c= relaxed for DKIM signatures on folded systems

  • Set c= relaxed in your DKIM signature if your email platform, gateway, or SMTP relay modifies line breaks or folds headers during transit.
  • Many email clients and servers (including Microsoft Exchange, Gmail, and modern forwarders) fold headers, making c= simple unreliable.
  • Check your email provider’s documentation—some platforms default to c= simple, which can break verification if your message body uses folded lines.

Verify alignment before sending at scale

  • Test your DKIM configuration directly against real-world receivers using inbox placement tools to confirm alignment works across different mail providers.
  • Use real-time verification tools like MailTester’s inbox placement tester to validate how your message body, headers, and DKIM signature work together in practice.
  • Regularly audit your infrastructure for legacy DKIM setups that assume c= simple, especially when using third-party senders or shared platforms.
  • Validate that SPF, DKIM, and DMARC alignment is consistent across the full message structure—not just the headers—to avoid authentication failure.

Even if your DKIM signature is technically correct, folded headers can break c= simple validation. This is why RFC 6376 recommends c= relaxed when content might be reformatted. It's not a flaw in your setup—it's a design consideration for modern delivery networks.

“The relaxed canonicalization method is more resilient to changes in email formatting, making it ideal for production environments where headers are frequently edited or folded.” — RFC 6376, Section 3.4

What does MailTester do differently with DKIM checks?

Unlike tools that test DKIM signatures in isolation, MailTester validates DKIM under real-world conditions—checking headers exactly as they’re received, not as they were signed. This catches c= simple failures early, before they cause bounces or spam filtering. High-accuracy verification (98.9%) identifies deliverability risks before they impact your inbox placement.

Realistic Header Processing, Not Theory

DKIM’s c= simple tag assumes headers are unmodified after signing, but in practice, many servers fold long headers or add trailing whitespace. If you test DKIM in a vacuum, you might pass when you shouldn’t. MailTester evaluates the signature using the actual headers you’d see in a real message—preserving folds, line breaks, and even minor formatting changes.

This approach aligns with how receivers like Gmail, Outlook, and enterprise gateways actually process messages. As the IETF’s RFC 6376 notes, the canonicalization process must account for line folding and whitespace to ensure consistent validation across infrastructure. Testing in isolation misses what receivers actually see.

IETF RFC 6376 defines the canonicalization rules, but few tools follow them accurately during verification. MailTester does—because we test what matters, not just what's theoretically correct.

Finding Failures Before They Hurt Your Reputation

When a DKIM signature fails due to folded headers, even with a valid key, the message is often marked as suspicious or rejected. This hurts sender reputation and can trigger rate limiting or blacklisting. Catching this at verification time stops problems before they reach recipients.

Because we use real-world header processing, MailTester flags c= simple failures that others miss. This reduces hard bounces, improves inbox placement, and avoids the reputation damage caused by sending tainted messages.

By integrating with your workflow—via our verification API or bulk verification—you catch these issues at scale. Every address checked reflects real-world delivery conditions, not idealized tests.

Deliverability isn’t just about sending— it’s about sending correctly. MailTester’s DKIM checks are built with that in mind.

Can you test inbox placement with folded headers?

Yes — MailTester’s inbox-placement tests simulate real-world gateways like Gmail, Yahoo, and Outlook, which apply header folding during delivery. These systems replicate the exact conditions that expose DKIM failures when c= simple is used with folded headers, so you can verify whether your DKIM setup holds up under actual sending conditions.

Why folding matters for DKIM validation

Servers like Gmail and Outlook routinely fold header lines that exceed 78 characters, which is standard in RFC 5322. If your DKIM signature uses c= simple, it assumes header lines are intact. But when a line is folded, the signed content no longer matches the received message — causing validation to fail.

This isn’t just theoretical. Major ISPs apply content folding before delivery, making it essential to test DKIM under these real-world constraints. MailTester’s inbox testers emulate this behavior precisely, so you’re not relying on hypotheticals.

Test exactly how your emails will perform

Let’s say you’re sending a campaign with DKIM and c= simple. Without testing, you might assume it’s valid, but folded headers during transit can break the signature. MailTester’s inbox placement service checks your message as it would land in a real inbox — including header folding — giving you accurate insight before you send.

For example, your email might pass internal checks but fail at Gmail’s gateways when header folding occurs. MailTester catches that before it harms your sender reputation. This testing applies to all major inboxes, not just one provider.

Using MailTester, you can validate sender alignment, detect signature mismatches early, and ensure your emails consistently pass authentication. It’s not just a test — it’s a live simulation of how recipients see your message.

Run your sender setup through a real inbox tester and see how it behaves with folded headers. You can test individual messages or entire campaigns to ensure deliverability holds across all gateways.

Learn how to verify your sender setup and avoid inbox placement issues with MailTester’s inbox placement tool. Start with your first 100 free verifications to see real results in seconds.

Final take: don’t rely on c= simple for modern email delivery

Dkim c= simple was designed for a simpler time, when headers were rarely folded. Today’s email infrastructure routinely folds headers, especially in long or complex messages. Using c= simple ignores this reality and can cause valid signatures to fail silently.

Real-world testing reveals real issues

Modern email clients and filtering systems expect robust, flexible DKIM signing. c= simple fails to account for common formatting variations. This increases the risk of undetected signature failures, reducing inbox placement and harming sender reputation.

  • Test DKIM in production-like environments, not just theoretical alignment.
  • Use tools that validate signatures against actual message bodies with folded headers.
  • Prefer c= relaxed for production use—it handles real-world edge cases without breaking.

Sources

Keep reading

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

Frequently asked questions

Why does DKIM c= simple not work with folded headers?

Because c= simple expects headers to be unbroken and uses literal string comparison. Folded headers alter the line structure, invalidating the canonical form used in signing.

Can a message pass DKIM if the header is folded?

Only if the signing system uses c= relaxed. c= simple fails because it cannot reconstruct the header string as it was signed.

How common is header folding in modern email?

Very common. Most email services fold headers that exceed 78 characters, especially Received: and Content-Type: fields.

Does DMARC check for folded headers?

No—DMARC depends on SPF and DKIM results. If DKIM fails due to folding, DMARC will also fail.

What’s the difference between c= simple and c= relaxed in DKIM?

c= relaxed normalizes whitespace and folding during canonicalization; c= simple does not. c= relaxed handles real-world header formatting.

How does DKIM impact inbox placement?

A failed DKIM check increases the chance of spam filtering, low sender reputation, and delivery failure—even with a clean domain.

Can MailTester detect DKIM c= simple issues?

Yes—its real-time API and verification tests simulate delivery conditions, flagging c= simple failures caused by folding.

Is c= simple still used in 2026?

It persists in legacy systems, but new deployments should use c= relaxed to ensure compatibility with folded headers.

Can I test my DKIM setup with MailTester?

Yes—MailTester’s inbox-placement tests validate DKIM, SPF, and DMARC under real-world conditions across major inboxes.

Are there tools that verify DKIM behavior beyond syntax?

Yes—MailTester’s API and tests evaluate how DKIM signatures behave during delivery, not just whether they follow the format.

Why is sender reputation affected by DKIM failures?

Consistent DKIM failures signal misconfiguration or possible spoofing, leading to reputation degradation and reduced inbox placement.

Does folding only happen in headers?

No—folding occurs in any part of an email body or header that exceeds line length limits, but most critical issues arise in headers.