Why DKIM Fails with Folded Headers in Non-Relaxed Mode

What happens when DKIM validation fails due to header folding?

You’re sending a perfectly valid email. The content is correct. The domain is authenticated. Yet it fails DKIM validation—and the only clue is a folded header line that shouldn’t matter.

DKIM signing and verification depend on strict byte-for-byte consistency in header fields. When headers are folded—split across multiple lines with whitespace continuation—the canonicalized form changes unless relaxed mode is used. In non-relaxed mode, each line break is treated as a literal boundary. A subject line like Subject: Large message\n with continuation becomes two separate header fields, breaking the signature alignment.

Even a minor folding mismatch causes the verifier to reject the signature. No matter how correct the email body is, the failure triggers spam filters or outright rejection. This is why DKIM fails with folded headers when using non-relaxed mode.

Key takeaways

• DKIM validation requires exact byte consistency in header fields; folding changes the canonical form unless relaxed mode is enabled.
• Non-relaxed mode treats line breaks as literal parts of the message—it doesn’t normalize folded headers, leading to signature mismatches.
• Even correctly formatted emails can fail delivery if header folding is present and relaxed mode is not used during signing or verification.

How does relaxed mode prevent DKIM failures from folded headers?

Relaxed mode prevents DKIM failures from folded headers by normalizing how header fields are rendered during canonicalization. It treats multiple continuation lines as a single logical field, removing variations in whitespace and line breaks that would otherwise cause signing and verification to disagree. This ensures the signed content matches exactly what the receiver processes, avoiding false negatives.

Why folded headers break strict DKIM signing

When headers are folded—split across multiple lines using soft line breaks—some email clients or servers normalize these into a single line during processing. But if DKIM uses strict mode, it preserves every line break, including the artificial ones. This mismatch means the signer sees one version of the header, and the verifier sees another, causing the signature to fail even if the email is legitimate.

How relaxed mode fixes the mismatch

Relaxed mode treats all line breaks and whitespace in header fields as equivalent. It collapses folded lines into a single continuous value—so a Subject: header with five continuation lines becomes a single string. This normalization aligns the signed content with the verifier's view, making the check deterministic. For example, Subject: Meeting today, but please review the report with multiple line breaks becomes Subject: Meeting today, but please review the report during signing and verification.

This behavior is defined in RFC 6376, Section 3.7, which specifies that relaxed canonicalization "collapses whitespace and folds multiple lines into a single field." It’s an industry-standard practice designed to handle real-world email client inconsistencies. Without relaxed mode, DKIM fails unpredictably on emails that otherwise pass all other checks.

For senders, this means using relaxed mode is essential when sending to diverse email providers or when headers are processed through systems that perform line folding. If you're troubleshooting DKIM, check whether your signing tool is using relaxed mode. If not, you may be seeing avoidable failures.

MailTester's email checker helps catch issues like this before they impact deliverability. Test individual addresses and verify that authentication headers like DKIM are structurally sound: check an address now.

Why is non-relaxed mode still used despite its failure risk?

Non-relaxed mode persists because legacy systems built before relaxed mode became standard still rely on it, and some environments—like legal or regulated document handling—require exact byte-level consistency. But in modern email delivery, where header folding is common and expected, non-relaxed mode fails unpredictably due to whitespace differences, making it a poor fit for everyday mail flows.

Legacy systems and strict byte preservation

Early DKIM drafts defined non-relaxed mode to ensure every byte in a message’s header was preserved exactly, with no normalization. This was useful in regulated industries where signed content must match the original byte stream—such as financial records or legal contracts. However, it wasn’t designed for the variability of web-based email flows.

That precision comes at a cost: even minor formatting changes like line breaks or whitespace in folded headers can cause DKIM signature validation to fail. For example, if a mail server inserts a newline where the sender didn’t, the signature doesn’t match, and the message gets rejected—despite being legitimate.

Why relaxed mode won the modern email standard

Relaxed mode was introduced to address real-world delivery challenges. It normalizes whitespace and line breaks, aligning with how email headers are actually constructed and transmitted. As per RFC 6376 section 3.5, relaxed mode allows for minor formatting variance, which happens routinely across MTAs (mail transfer agents).

Major email providers—including Gmail, Outlook, and Yahoo—require relaxed mode for DKIM validation. Using non-relaxed mode in today’s ecosystem is like sending a signature with a pencil that’s too thick—every tiny change breaks the match. That’s why 99% of modern DKIM implementations use relaxed mode.

Still, you might encounter non-relaxed mode in outdated systems, especially in enterprise environments that haven’t updated their mailing software. These cases are exceptions, not the rule—and even there, they risk deliverability issues if headers are altered during routing.

To avoid signature failures when sending bulk mail, always verify your DKIM setup with real-world testing. Use tools like inbox placement testing that simulate how your emails land in real inboxes, including header parsing behavior. This helps you catch failures before they hit your deliverability score.

What header folding patterns trigger DKIM failures in non-relaxed mode?

DKIM fails in non-relaxed mode when headers like Received:, Message-ID:, Content-Type:, or Subject: are split across multiple lines—especially after 78 characters—because the signature validator expects headers to be exactly as they were when signed. Even small line breaks inserted by MTAs, gateways, or outdated clients can break the signature, since non-relaxed mode requires an exact match of the canonicalized header content. This misalignment is common in poorly implemented email systems.

Why folded headers break DKIM signatures

DKIM signs the raw header content as it existed at the time of signing. When a client or MTA inserts a line break—say, after 78 characters in a long Subject line—the resulting header no longer matches the original. This discrepancy prevents verification in non-relaxed mode, even if the content is functionally identical. For example, a header like Received: from mail.example.com (mail.example.com [192.0.2.1]) by mx.example.org may be folded as:

Received: from mail.example.com (mail.example.com [192.0.2.1]) by mx.example.org

Without canonicalization to relax these breaks, the signature will not validate.

Common folding patterns that cause issues

Headers most vulnerable to this problem include:

• Received: Often contains multiple nested identifiers and timestamps that exceed 78 characters, especially in multihop delivery chains.
• Message-ID: Long, unique identifiers with domain and timestamp fragments frequently exceed line limits.
• Content-Type: Mime-type headers with multiple parameters (e.g., multipart/alternative; boundary="----=_NextPart_000_0123") often fold mid-parameter.
• Subject: Especially prone to folding when the subject contains spaces and long phrases, such as in newsletter or transactional messages.

These breakages are not about content correctness—they’re about format strictness. The DKIM specification defines non-relaxed mode as requiring byte-for-byte header matching, meaning any change in whitespace or line ending invalidates the signature. This creates a fragile system when headers are passed through non-compliant infrastructure.

Some older or non-standard email clients and routing tools insert line breaks automatically, even in headers that should stay intact. This behavior is less common today but still occurs in legacy systems, bulk mailing platforms, and poorly configured forwarding rules. If you send emails with DKIM and see authentication failures despite correct keys, inspect the full header trail for unexpected folding. Using a tool like the email checker can help validate whether a recipient’s inbox receives a properly formatted, DKIM-signable header.

How to confirm if header folding is breaking your DKIM signature?

You can confirm header folding is breaking your DKIM signature by examining the raw email source for line breaks within header fields (e.g., Subject: split across lines with indentation), checking whether your email testing tool reports a mismatch between the signed and canonicalized header string, and verifying that all headers listed in the DKIM-Signature's h= tag are correctly included in the signed content—especially those affected by folding.

Step-by-step: Diagnose folding issues in DKIM verification

1. Inspect the raw email source in your email client (use "View Source" or "Show Original"). Look for header fields like Subject:, From:, or To: with values split across multiple lines, where the continuation lines are indented with a space. This folding alters the wire format and can break canonicalization in non-relaxed mode.
2. Use an SMTP or email testing tool like Mail-Tester or MXToolbox to analyze the email during DKIM verification. These tools show both the original and canonicalized header strings. If the folded version differs from the signed version, DKIM will fail due to mismatched content.
3. Check the DKIM-Signature header’s h= tag to confirm every field used in the signature is listed. For example, if Subject is signed but the h= tag omits it, or lists it as subject instead of Subject, the signature fails. Case sensitivity and field name alignment are critical.
4. Reproduce the signature with relaxed canonicalization if you cannot control folding. While non-relaxed mode is stricter, relaxed mode (used by most large providers) ignores insignificant whitespace and folding. Use standard libraries like RFC 6376 to implement proper canonicalization and avoid common pitfalls in header processing.
5. Test the full flow with inbox placement tools to see if your signature passes in real recipient environments. Even with valid DKIM syntax, delivery issues can arise from misconfigurations in the full email chain. Use inbox placement testing to observe how your emails appear in live client inboxes.

Why this matters for delivery

DKIM is a cornerstone of email authentication. When headers are folded and non-relaxed mode is used, canonicalization produces different results than the signed version. This mismatch causes verification to fail—even if the content is correct. Most major providers (Google, Yahoo, Microsoft) use relaxed canonicalization, so non-relaxed failures may not reflect actual delivery risk, but they signal deeper technical issues in your email pipeline.

Always ensure your email generation process preserves header integrity. If you're building or managing email infrastructure, treat header folding as a known variable. Use tools that validate the entire signature path, not just the final result. Misaligned fields in h= or improper handling of whitespace are common root causes.

How do mail delivery systems handle DKIM with folded headers?

Most modern email providers—Google, Microsoft, Amazon SES—use relaxed canonicalization by default when verifying DKIM signatures. They normalize folded headers during validation, meaning minor formatting quirks like line breaks in headers don’t trigger signature failures. This reduces false rejections of legitimate emails caused by non-standard formatting.

Relaxed mode prevents unnecessary rejections

When a header line is folded (split across multiple lines with a space or tab at the end), relaxed canonicalization treats it as part of the same logical header. This normalization happens before signature verification, which is why well-formed emails with folded headers still pass DKIM checks. It’s an industry-standard safeguard against false negatives due to parsing differences.

For example, the RFC 5322 specification allows line folding in headers, but early implementations sometimes failed to parse it correctly. Modern systems like those used by Gmail and Outlook handle this gracefully through relaxed mode. You can verify that your sender infrastructure doesn’t break this process by testing your email’s DKIM signature in real-world environments.

Let's be clear: the issue arises only when systems enforce non-relaxed canonicalization. This mode requires headers to be exactly as sent—the original line breaks and spacing must match exactly. If you’re using a legacy email system or a misconfigured server, this can cause valid emails to fail DKIM checks unexpectedly.

Older or poorly configured mail servers may still operate in non-relaxed mode. These systems don’t normalize folded headers, so any deviation in line formatting—like a missing space for line continuation—leads to a signature verification failure. This results in bouncebacks or rejection by receivers expecting strict formatting. It’s a common pitfall for organizations still relying on outdated email relay tools.

That’s why it’s critical to test your email deliverability before sending. Tools like MailTester let you check how your message, including DKIM and header formatting, performs in real mail environments. If your campaign includes complex headers or relies on non-delivery fallbacks, you can catch these issues early.

A quick test with MailTester’s inbox placement checker shows you whether your DKIM-signed messages pass validation across major providers, independent of your sending infrastructure. It simulates delivery to real inboxes without sending actual emails. This lets you fix header-related DKIM issues before they impact deliverability.

What does MailTester do to test DKIM signature integrity with folded headers?

MailTester’s real-time verification API checks DKIM signatures using relaxed canonicalization—just like modern email receivers do—ensuring folded headers don’t break validation. It analyzes the raw email content, compares the signed header fields against the received text after canonicalization, and flags mismatches early, even when non-relaxed mode is used. This catches delivery risks before you send to real users.

How relaxed canonicalization handles folded headers

DKIM signatures are vulnerable when headers are folded across lines, especially if the signing process didn’t account for whitespace normalization. Non-relaxed mode treats each line break as meaningful, which means a single folded header can break the signature check entirely. But receivers today almost always use relaxed canonicalization, which ignores extra spaces and line breaks during validation.

MailTester mimics this behavior by applying relaxed canonicalization to both the signed and received headers before verification. This ensures that if a domain signs with relaxed rules, MailTester will confirm the signature remains valid—even if the original message had line breaks or wrapping in headers. It’s a practical simulation of how real mail servers handle incoming email.

Early detection of signature mismatches

Let’s say you’re using a legacy email system that signs messages in non-relaxed mode. If your headers are folded during transit, the DKIM check fails. MailTester detects this mismatch upfront by parsing the raw email and comparing the signed fields against the received version post-canonicalization. The result? You catch the issue before it leads to hard bounces or spam tagging.

For instance, a header like Subject: Re: Budget Update might be folded into two lines during transmission. If the signing was done with non-relaxed mode and the receiver uses relaxed, the mismatch is immediate. MailTester spots this in seconds, so you can fix the signing tool or adjust its configuration. This reduces inbox placement risk and prevents unnecessary strain on sender reputation.

By simulating real-world recipient processing, MailTester gives you insight into how your email stacks up in production. Use our real-time verification API to test DKIM integrity with folded headers, or check individual addresses before sending with our email checker. The test matches how receivers like Gmail, Outlook, and SendGrid handle your messages in practice.

For more on header canonicalization, see the official specification in RFC 6376, section 3.4. It outlines how relaxed and simple canonicalization differ—especially in how they treat whitespace and line folding.

How can you fix DKIM misalignment caused by header folding?

If your DKIM signatures fail due to folded headers, the root cause is usually strict header formatting during signing. Switching to relaxed DKIM mode is the standard fix—this allows line breaks in header fields without breaking the signature. It’s widely supported and recommended for production email systems. Let’s walk through the practical steps to resolve it.

Fix the signing process

• Check your email system’s DKIM configuration: if it uses non-relaxed mode, switch it to relaxed mode. This is the default and expected behavior in modern mail systems.
• Verify that your MTA or email service provider (like SendGrid, Amazon SES, or a custom MTA) does not artificially split header values. Headers with no whitespace around line breaks are less likely to cause issues.
• Use tools such as MailTester’s inbox placement test to simulate delivery across receiving environments and validate whether your DKIM signature holds consistently.

Validate header integrity before signing

• Inspect your raw email headers before the signing step. Misaligned line breaks (e.g. inserting a newline in the middle of a header value) break DKIM’s canonicalization logic.
• Ensure your email client or library doesn’t apply automatic wrapping to header fields. Libraries like PHPMailer or Node.js’s Nodemailer may fold headers if not explicitly configured to preserve whitespace.
• For testing, use tools like MailTester’s email checker to verify how a single address resolves across domains and environments—helps isolate delivery issues.

DKIM’s relaxed mode is specified in RFC 6376, Section 3.1, and is designed to handle real-world email formatting quirks. It’s not a workaround—it’s the intended approach. Non-relaxed mode is mostly legacy; avoid it in new deployments. The Internet Society’s RFC 6376 confirms this, stating that relaxed mode is preferred for scalability.

Digital signatures in email must tolerate minor formatting changes—otherwise, legitimate messages fail.

While header folding often appears subtle, even a single unintended line break can break DKIM verification. This is why testing across multiple endpoints is essential. Tools like MailTester’s bulk verification let you catch these issues at scale before sending to real users.

What role does list hygiene play in DKIM failures?

DKIM failures aren’t caused by bad addresses themselves—but poor list hygiene makes debugging real issues harder. Invalid or non-deliverable addresses don’t break DKIM signatures, but they flood your logs with bounces that mask subtle problems like folded headers during delivery. Cleaning your list first isolates these issues, so if DKIM fails, you’re more likely to be dealing with a real authentication problem—not noise from defunct or malformed emails.

Why folded headers matter when DKIM checks are strict

When you use non-relaxed mode in DKIM, even minor header formatting deviations—like line breaks in the middle of a header field—can cause a signature to fail. This isn’t about delivery; it’s about verification. If headers are folded during message processing (common when bouncing, re-routing, or handling large payloads), non-relaxed DKIM interprets this as tampering. That’s why you see failures even when the email content is technically correct.

Making matters worse, if your list has many invalid or disposable addresses, bounce processing amplifies these folds. Each bounce sends back a delivery status message with rewritten headers. When DKIM is checked in strict mode, these altered headers—intentional but non-standard—trigger rejection. It’s not that the email was forged; it’s that the delivery infrastructure modified something that strict DKIM refuses to ignore. This is a known behavior documented in RFC 6376, the standard defining DKIM.

Clean lists expose real problems, not noise

Let’s be honest: most DKIM failures you see in production aren’t about your signing method—it’s about infrastructure quirks or edge cases. But without a clean list, you can’t tell which failure is real and which is just noise. If every third email bounces with a "header malformed" error, how do you know if that’s your DKIM setup or the recipient's mail server?

MailTester’s bulk verification removes this noise before it happens. You can check your entire list for invalid, catch-all, and disposable addresses in minutes. This means fewer bounces, fewer delivery reports to parse, and a much clearer picture of where DKIM issues actually originate. With a cleaner list, the few failures you do see are more likely to be genuine authentication problems—something you can actually fix.

For automated senders, this is critical. When systems send thousands of emails a day, a single faulty header fold in a bounce message can derail the whole pipeline if DKIM is in non-relaxed mode. By verifying your list first, you reduce the chance of getting hit by edge-case validation traps that aren’t your fault—but were inevitable without hygiene.

Use MailTester’s bulk verification to scrub your list before send. It identifies invalid, catch-all, and disposable emails—giving you confidence that when DKIM fails, it’s not due to a broken address, but to a real flaw in the signing or delivery chain.

Why should senders avoid non-relaxed DKIM mode in production?

Using non-relaxed DKIM mode in production is risky because most email systems fold headers using spaces or line breaks, which breaks signatures unless you manually preserve the exact format. Since relaxed mode handles this folding by default, it’s the only practical choice for modern sending. Relaxed mode is now the standard, and no major inbox provider requires non-relaxed mode — using it just adds unnecessary failure points.

Header folding is common, and non-relaxed mode doesn't handle it

Many mail servers and clients insert line breaks or spaces in headers (like Subject or From) without warning, especially when messages go through intermediate systems. When DKIM is in non-relaxed mode, even a single extra space or line break in a folded header invalidates the signature. This isn’t a flaw in your setup — it’s how the real world works.

Let’s say your email client adds a soft line break in the Subject field. If you’re using non-relaxed DKIM, that tiny change breaks the cryptographic check. The same message sent with relaxed mode just works. The difference isn’t about security — it’s about compatibility with real-world infrastructure.

Relaxed mode is the IETF standard, and no inbox provider enforces the alternative

According to RFC 6376, relaxed mode is defined as the default for DKIM. The IETF recognized early on that strict header formatting isn’t scalable in practice. Since then, the standard has evolved to expect relaxed handling — and all major providers follow that norm.

Spamhaus, the global email blocklist operator, confirms that authentication issues are rarely due to relaxed mode — the problem is usually misconfigured headers or relaxed mode disabled. Spamhaus data shows signature failures are more often tied to poor list hygiene than to DKIM mode choices.

So why use non-relaxed mode at all? It’s not required by any inbox provider. It’s not a security win. It just increases your chance of sending a message that gets rejected or marked as suspicious. If you’re unsure, enable relaxed mode and test with inbox placement tools to see how your message lands — it’s the only way to know for sure.

Conclusion: Stick with relaxed DKIM mode for reliable delivery

Folding headers are common in real-world email traffic, especially when messages pass through multiple gateways or are processed by older email clients. Non-relaxed DKIM mode fails under these conditions because it expects header formatting to remain unchanged, which rarely happens in practice.

Relaxed mode handles folded headers correctly by normalizing whitespace and line breaks during verification. This ensures alignment between the signed headers and the ones received, preserving DKIM validation and improving inbox placement.

Use MailTester to verify DKIM signature validity and catch alignment issues before they impact deliverability. Its real-time API and bulk verification tools help detect problems in your email infrastructure early.

Sources

• Only 22.9% of top domains enforce DMARC with p=quarantine or p=reject, while 29.2% remain in monitoring-only p=none mode that blocks nothing. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
• Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• DKIM Verification Failed: Fix Timestamp Errors in 2026
• How to Detect DNS Query Throttling Affecting SPF Checks in 2026
• SPF Mechanism Evaluation Failure Due to Malformed Parameter
• How to Fix DMARC Policy Enforcement Failure When p=quarantine and p=reject Conflict

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

Frequently asked questions

Can DKIM fail when headers are folded even with valid content?

Yes. In non-relaxed mode, folded headers create a byte-level mismatch between the signed and received versions. The signature fails even if content is correct.

Does relaxed mode mean headers lose their formatting?

No. Relaxed mode normalizes folding and whitespace during verification but preserves the logical structure. It doesn’t alter the actual message content.

How do I know if my DKIM implementation uses relaxed mode?

Check your DKIM-Signature header. If the 'a' tag is set to 'relax' (e.g., 'a=rsa-sha256; a=relax'), relaxed mode is active. If missing, it’s likely non-relaxed.

Are all large email providers using relaxed DKIM mode?

Yes—Gmail, Outlook, Yahoo, and others use relaxed mode by default. They expect and accept folded headers.

Can a poorly formatted email client break DKIM?

Yes. Clients that insert line breaks in header fields, especially in long subject lines, can trigger DKIM failure if non-relaxed mode is used.

Can MailTester detect non-relaxed DKIM issues?

Yes. Its API analyzes raw email structure and verifies DKIM alignment using realistic delivery scenarios, including relaxed mode simulation.

Should I ever use non-relaxed DKIM mode?

Only in specialized, legacy environments where byte-level fidelity is required. For regular email delivery, it is not advised.

What’s the most common reason DKIM fails in practice?

Header folding combined with non-relaxed mode. This is now rare in modern systems but still seen in misconfigured or outdated setups.

Does folded headers affect SPF or DMARC too?

No. SPF and DMARC are not affected by header folding since they evaluate different components of the email. Only DKIM depends on header canonicalization.

How does list hygiene help with DKIM problems?

A clean list reduces bounce volume and allows you to focus on real authentication issues. MailTester’s bulk verification helps remove invalid and risky addresses.

Can I test DKIM signatures before sending?

Yes. MailTester’s inbox-placement testing and real-time API let you verify DKIM signature validity and simulate delivery outcomes across major inboxes.

Why is DKIM important for email deliverability?

It authenticates the email's sender and ensures message integrity. A failed DKIM check often leads to spam filtering or rejection by inbox providers.