SMTP Header Folding & DKIM Testing

Why does SMTP header folding matter for DKIM verification?

You send a perfectly signed email. It passes SPF. It has a valid DKIM signature. Yet it lands in the spam folder — or worse, fails entirely. Why?

One overlooked culprit: how SMTP headers are folded during transmission. RFC 5322 mandates that SMTP headers be folded at 78 characters, but this seemingly small detail breaks DKIM verification if not handled correctly.

DKIM relies on exact string matching during canonicalization. Even a single space, line break, or folding point change alters the hash digest. If your mail server adds or removes a soft line break where the signature expects one, the signature fails — even if the message content is unchanged.

Key takeaways

Drafting tools that don’t preserve strict SMTP header folding can break DKIM signatures during transmission.
DKIM canonicalization treats whitespace and line breaks as part of the digest — even small folding differences invalidate the signature.
Mail servers that reformat headers during delivery (e.g., by re-folding or stripping whitespace) may inadvertently trigger DKIM verification failures on otherwise valid messages.

How does DKIM canonicalization depend on header formatting?

DKIM signature validation fails if the header formatting during signing and verification doesn’t match — even with relaxed canonicalization, inconsistent line breaks from SMTP header folding can break the match. The signing and verification processes must apply identical normalizations, including whitespace trimming and line break handling. If one side collapses folded lines differently, the canonicalized headers diverge, and the signature is rejected. This is why header formatting isn’t just a cosmetic detail — it’s a validation requirement.

Relaxed canonicalization isn’t a magic fix

DKIM supports two canonicalization methods: simple and relaxed. Relaxed allows minimal normalization, such as trimming whitespace and normalizing line breaks. But it doesn’t ignore folding entirely — it still expects consistent handling of line breaks, especially when multiple lines are folded in a single header field. If your email client or system introduces extra line breaks due to improper folding, the canonicalized header won’t match the signed version.

Let’s say you sign a message with a Subject: header that contains a long line folded across two lines, like this:

Subject: Re: Meeting tomorrow at 2 PM - please confirm your
attendance and bring the report

If the verifier treats the fold as a single line or inserts an extra newline, the digest produced during verification will differ. Even with relaxed canonicalization, that mismatch breaks the signature.

The RFC 6376 specification for DKIM (which you can review at RFC 6376) explicitly requires that all canonicalization processes — both signing and verifying — must follow precisely the same rules. This includes how folded lines are interpreted. Any deviation, intentional or accidental, leads to a failure.

Why this matters beyond theory

Header folding issues are often hidden in poorly written email clients, legacy systems, or automated pipelines that don’t properly follow SMTP line-length rules (max 998 characters per line). In real-world sending, where messages pass through multiple systems, these inconsistencies compound.

For example, a list of 10,000 email addresses may have only a few malformed headers, but those few can trigger widespread DKIM failures. This affects sender reputation, inbox placement, and deliverability — especially for bulk mailers relying on consistent authentication.

It’s not enough to just use DKIM. You must ensure your email generation pipeline — whether via API, templating engine, or marketing platform — applies consistent header formatting before signing. Tools like MailTester’s email checker can verify individual addresses for common format issues, including invalid structures that could affect authentication later.

What happens when header folding is inconsistent during DKIM signing and checking?

If a message is signed with one header folding pattern but the receiving server rewrites headers—common in relay services, gateways, or MTAs—DKIM’s canonicalized hash will change. Even with correct DNS records and valid keys, the signature fails verification. This breaks authentication, causing legitimate emails to be marked as spoofed or invalid, even when sent from a properly configured domain.

Why folding patterns matter in DKIM validation

DKIM relies on a strict canonicalization process. The signing domain must apply the same folding rules the recipient expects. But email systems vary in how they fold long header lines (typically at 78 characters). If the sender uses strict CRLF+space folding but the MTA inserts line breaks in the middle of words, the canonicalized header differs—invalidating the signature.

Mail servers and gateways that rewrite headers—especially those used for spam filtering, encryption, or routing—often apply their own folding logic. This rewrites the message before it reaches the validator, altering the body and header content that DKIM checked against. The result? A valid email fails verification, even without any malicious intent.

Common causes and real-world consequences

Relay services like Amazon SES, Microsoft 365, or third-party filters often normalize or modify headers in transit. This normalization breaks DKIM unless both ends agree on folding behavior. When the folding differs, the hash mismatch becomes the sole reason for failure—even with correct domain configuration.

According to RFC 5322, header folding should preserve content integrity, but implementations diverge in practice. The problem isn’t always about intent—it's about consistency. A message sent via a poorly configured gateway may pass initial checks but fail DKIM post-delivery due to folding changes. This leads to false positives, damaged sender reputation, and lost inbox placement.

While DKIM validation tools like MailTester’s inbox placement tester don’t directly fix folding issues, they can detect whether a signed message fails due to authentication problems. By sending test messages through your pipeline and observing DKIM results, you can catch folding drift early. Tools that simulate real delivery paths help expose these inconsistencies before they impact your mail volume.

Sending through well-documented intermediaries that document their behavior—like RFC-compliant MTA implementations—means fewer surprises. But when integrating with third-party services, test authentication end-to-end. Even small header changes during transit can break DKIM, no matter how solid your signing setup seems.

How can you verify if header folding is breaking your DKIM results?

When your DKIM signature fails, header folding might be the silent culprit. Use a tool like MailTester’s real-time verification API to send test messages through your actual sending workflow, then compare the raw headers from your original message against the delivered version. Even small changes—like extra spaces or shifted line breaks—can invalidate a DKIM signature because DKIM canonicalization treats whitespace and line breaks as meaningful. Catching these differences early prevents failed authentication and protects your sender reputation.

Step-by-step: Diagnose header folding issues

Send a test message through your real delivery path using MailTester’s real-time verification API. This ensures you're testing the actual headers your system generates, not a static template.
Extract the raw headers from the original message before it leaves your system. You can do this by inspecting the message source in your email client or using a protocol analyzer like Wireshark for outbound traffic.
Retrieve the raw headers from the delivered message using a delivery testing service or by checking the final receipt in a mail server log. Tools like DKIM RFC 6376 define canonicalization rules that expect strict formatting, so any deviation can break validation.
Compare both header sets side by side, focusing on each line’s start, line breaks, and spacing. Look for unintended fold points, extra spaces introduced during routing, or line continuation characters added by intermediaries.
Check for differences in canonicalized form—DKIM checks headers in a specific format (relaxed or simple canonicalization). Even small variations, like folding after a colon instead of after the header name, can cause rejection.

Fix and validate: Prove it works

Once you identify where folding changes occur, adjust your sending software to preserve canonical format. Some SMTP libraries or email clients auto-fold headers at 78 characters; ensure your system controls this behavior. Use MailTester’s inbox placement tester to revalidate your message after changes—this confirms whether corrected headers now pass DKIM and avoid spam filters. Remember: DKIM is sensitive to even minor formatting shifts. Testing with a real delivery path is the only way to catch these issues.

The role of mail servers in header reformatting and DKIM consistency

SMTP servers often reformat long headers during transit, but they may alter the original line breaks—especially older or non-compliant mail transfer agents (MTAs)—which breaks DKIM’s canonicalization process. DKIM expects headers to be normalized exactly as sent, so even minor changes in folding can cause signature validation failures. This isn’t a bug in DKIM; it’s a vulnerability in how some servers handle line length.

How header rewrapping undermines DKIM checks

Let’s say your email client sends a header like this:

Subject: Re: Important project update — please review before Friday

If the line exceeds 78 characters and gets rewrapped at a relay server, the new line breaks may not match the original. DKIM canonicalizes headers using strict rules: folding whitespace must be preserved. If the MTA adds a space after a soft line break or removes one, the resulting canonicalized header will differ from the signed version.

For example, if the original folded header has a soft break at position 78 with a single space, but the server inserts two spaces or removes the space entirely, the canonicalized form changes—and the signature fails. This is why RFC 5322 specifies that line breaks must not be altered without preserving original whitespace context.

Even reputable providers can introduce this issue. Not all MTAs implement the full specification, and some legacy systems re-wrap lines without considering header canonicalization requirements. This is especially common in high-volume relays or older mail platforms with limited testing.

Nearly every email service you rely on uses some form of MTA-based rewriting. The problem isn’t limited to spam or malware—it impacts legitimate marketing campaigns, transactional emails, and B2B communications. You can't control every server a message touches, but you can detect and fix issues early with tools designed for deep header validation.

Use a real-time verification API to detect canonicalization risks before sending. See how your headers are processed: test email headers at scale with our verification API.
Check deliverability using inbox placement testing to catch subtle signature issues not caught by basic validation: validate full message integrity across real inboxes.

For deeper insight into how headers are handled in transit, refer to the official specification: RFC 5322, Section 2.1.1 outlines formatting rules for email headers and the importance of preserving folding. This rule is foundational—yet frequently violated in practice.

DKIM is only as strong as the consistency of your message’s representation across the entire delivery path. If one MTA modifies line folding without compensating for the change in the signature’s canonical form, the entire email chain fails. That’s why testing your messages end-to-end—including header behavior under real relay conditions—is non-negotiable.

Can DKIM still pass if the header folding isn’t perfectly preserved?

Yes—DKIM can still pass if header folding isn’t perfectly preserved, but only if both the signing and verification processes use the same canonicalization method, specifically relaxed mode. Relaxed canonicalization is designed to tolerate minor variations in whitespace and line breaks, making it more resilient to transformations applied by older or non-strict email servers. However, over-aggressive folding or inconsistent handling during transit can still push the system beyond its tolerance threshold, causing a signature validation failure.

How relaxed canonicalization handles folding variations

DKIM defines two canonicalization modes: simple and relaxed. Relaxed mode ignores insignificant differences in line breaks and whitespace, so a folded header like this:

Received: from mx.example.com (mail.example.com) by smtp.example.org with ESMTP id ABC123; Thu, 1 Jan 2025 00:00:00 +0000

is treated the same as one folded differently, as long as the actual header field values haven’t changed. This allows DKIM to survive common email transport behaviors like header reshaping by MTAs that aren’t folding-strict.

But relaxed mode has limits. If the folding is so aggressive that it changes the structure—say, by moving parts of a header field value across multiple lines in a way that alters the intended content—then even relaxed canonicalization can’t recover. For example, a header field like From: [email protected] split incorrectly across lines, such as From: user@ on one line and example.com on the next, will break validation regardless of mode.

Why inconsistent handling causes real-world failures

Not all servers or email systems apply relaxed canonicalization the same way. Some older or misconfigured mail servers may reformat headers in ways that break DKIM even when the content is equivalent. This is especially common with legacy systems or poorly written email processing tools that don’t follow the RFC standards rigorously.

To reduce risk, ensure your email infrastructure uses relaxed canonicalization consistently. The RFC 6376 (which defines DKIM) specifies this behavior, but implementation isn’t always uniform. Testing is more reliable than assumption.

If you’re verifying sender setup or debugging delivery issues, you can check how your messages are being transformed during transit. Tools like inbox placement testing help identify whether signatures fail due to folding or other delivery path changes—even if your server config seems correct on paper.

Best practices for preventing DKIM failure due to header folding

DKIM can fail when header folding alters line breaks during transit, breaking canonicalization. Use relaxed canonicalization, validate messages before sending, and test end-to-end through your pipeline to catch folding issues early. This prevents signature mismatches and ensures your emails arrive as intended.

Use relaxed canonicalization by default

Always set DKIM canonicalization to relaxed in your signing configuration — it’s the standard for modern email systems and handles line breaks better than simple.
Relaxed canonicalization normalizes whitespace, ignores folding breaks, and aligns with how most MTAs treat headers in practice.
See RFC 6376, Section 3.7 for the formal definition of relaxed canonicalization in DKIM.

Validate and test before sending at scale

Pre-validate outgoing messages using tools that simulate real-world delivery conditions, including line folding and transport reformatting.
Test your full email pipeline — from your application to mail server to recipient MTA — to catch any header rewriting or folding that might break DKIM.
Use inbox placement testing to see how your message behaves across different providers and detect early signs of canonicalization issues.
For bulk sends, run small test batches through your full flow to uncover folding or reformatting quirks before a full campaign.
Check both individual addresses and full lists for structural problems before they hit the wire.

Even small changes in header formatting—like a newline after a colon or an accidental 78-character line break—can break DKIM if canonicalization isn’t set to relax. Let’s treat all headers as dynamic: they’ll change during transit. Your signing method should expect that.

DKIM’s reliability depends not just on your private key, but on your ability to replicate the exact header state seen by the verifier.

Don’t wait for bounces or blocklists to surface problems. Build validation into your process, and use tools that mirror real MTA behavior. That’s how you avoid silent DKIM failures due to subtle, invisible data reshaping.

How MailTester helps catch SMTP/DKIM issues before they reach inbox filters

You can catch SMTP header folding issues that break DKIM canonicalization before they hit inbox filters by validating your email’s wire format in real time. MailTester checks the exact header structure and line breaks used in transmission, ensuring DKIM signatures remain valid after canonicalization. This reduces the risk of rejection due to signature mismatches, even when headers are folded incorrectly.

Validating DKIM readiness in the real wire format

DKIM relies on a precise canonicalized version of your email headers. If an SMTP client folds a long header line at the wrong point—say, mid-field or inside a quoted string—it can corrupt the canonicalization process. MailTester simulates this exact flow by testing the raw format sent over SMTP, not just the parsed content. This exposes issues that tools ignoring wire-level structure would miss.

Let's say you're sending from Mailchimp or SendGrid. Even if the email looks good in the dashboard, an improperly folded header during transmission can invalidate DKIM. MailTester integrates with those platforms to verify your entire workflow—right from the sending endpoint to the wire format. This means you’re not blind to the actual data that reaches the receiving server.

Using the real-time API or bulk verification, you can test whether a given address would accept a message with your current header formatting. MailTester checks for common missteps: incorrect line breaks, folding inside token boundaries, or missing whitespace after colons. These are hard to debug without seeing the actual transmitted format.

For example, an RFC 5322-compliant header must fold only at whitespace and follow strict line continuation rules. Tools that analyze only the final parsed version won’t catch these subtleties. MailTester tests the exact sequence of bytes sent over SMTP, which aligns with RFC 5322’s section on line folding. This is how you ensure your DKIM signature remains valid in the wild.

Inbox placement testing under real-world conditions

Deliverability isn’t just about headers. MailTester’s inbox placement tests send real emails to major providers (Gmail, Outlook, Yahoo) and report back on placement, content filtering, and header validation. This includes checking whether your DKIM pass rate holds under actual reception conditions.

With MailTester, you can test a complete message flow: from header formatting, through SMTP transmission, to inbox delivery. This gives you visibility into issues that only surface in production. For instance, a message might pass internal validation but fail DKIM due to an invisible line break in a long header field. Catching that early saves time on troubleshooting later.

To test your list, send a sample batch through the bulk verification tool, or integrate the real-time API into your workflow. Every verification confirms both address validity and formatting integrity—making sure your DKIM setup won’t fail due to folding.

The relationship between deliverability and DKIM verification integrity

DKIM verification failures—often triggered by subtle header folding inconsistencies—can cause even valid emails to land in spam or be rejected, despite correct content and sender reputation. A broken DKIM signature erodes trust signals that inbox providers use to evaluate legitimacy, directly impacting deliverability. You don’t need a major flaw; a single misplaced line break in an email header can invalidate a DKIM signature. This isn’t just a technical edge case—it’s a deliverability necessity.

How DKIM works and why it matters

DKIM is one of three core email authentication standards, alongside SPF and DMARC. When properly implemented, it uses cryptographic signing to verify that an email’s content and headers haven’t been altered in transit. An inbox provider checks this signature before deciding whether to deliver the message. If the signature fails—even due to a small header folding issue—the message may be flagged as suspicious or outright rejected.

Let’s be clear: a properly formatted email from a trusted domain can still be blocked if the DKIM signature fails. For example, if your email client or mail server applies non-standard line breaks in headers (e.g., breaking a long header field at 78 characters instead of the RFC 5322 standard of 76), the resulting hash won’t match the signature. Even though the content is correct, DKIM canonicalization fails because the header representation during signing differs from the one during verification.

Header folding isn’t a nuance—it’s deliverability-critical

Header folding refers to how line breaks are inserted within email headers that exceed a certain length. The standard (RFC 5322, Section 2.2.3) specifies that headers must be folded at or before column 76. Misfolded headers—especially when folded differently during signing than during verification—cause DKIM canonicalization failure. This isn’t theoretical. It’s one of the most common causes of preventable DKIM failure among bulk senders.

You can’t rely on inbox providers to ignore these errors. Most major platforms—including Gmail, Outlook, and Yahoo—check DKIM rigorously. A failed signature reduces inbox placement, and repeated failures can harm your sender reputation over time. This is why consistent header folding is not an edge case but a core part of delivering reliably.

Use tools that catch these issues before sending. Tools like inbox placement testing simulate real-world delivery conditions, including DKIM validation. You can also use our email checker to validate addresses and detect common formatting risks that might interfere with authentication processes.

Think of DKIM not as a checkbox on a delivery checklist, but as a continuous trust signal. If it’s broken—even by a formatting detail—you lose credibility with providers who rely on it. Ensuring consistent header folding is one of the simplest yet most effective ways to keep your message trusted and seen.

What should you do if your DKIM signature keeps failing after fixing alignment?

If your DKIM signature keeps failing despite correct header alignment, the issue is likely in how your MTA or signing software handles SMTP header folding — specifically, whether it respects relaxed canonicalization during header normalization. Headers folded in transit can cause DKIM verification to fail even with proper alignment. Check that your systems apply consistent header normalization, not just line breaks. Use real-world inbox testing to confirm whether your messages pass delivery in practice, not just in theory.

Check for mismanaged header rewrapping in your MTA or email service

Many MTAs and email services automatically rewrap long headers without accounting for DKIM’s relaxed canonicalization rules. This can alter the order or structure of header fields, invalidating the signature even if alignment is correct. The problem often surfaces when lines are broken mid-field or when whitespace around colons is inconsistently preserved.

Look at your message before and after outbound processing. If you see fields like From: or Subject: split across lines with inconsistent spacing or trailing whitespace, the signature may fail despite correct alignment. Refer to RFC 6376 (Section 3.4) for how DKIM expects headers to be normalized.

Some services, especially older or non-DKIM-aware ones, perform header rewrapping without considering canonicalization. You can test this by sending a message with deliberately long headers and inspecting the delivered version against the signed one.

Verify your signing software applies relaxed canonicalization correctly

DKIM uses two canonicalization methods: relaxed and simple. Only relaxed is meant for human-readable headers. If your signing process uses simple canonicalization, your message will fail when validated by any standard MTA.

Ensure your signing software applies relaxed canonicalization and enforces consistent normalization — that is, it collapses consecutive whitespace, normalizes line endings, and preserves field ordering. This process must be applied consistently both at signing and during verification.

Many open-source tools and SDKs default to relaxed, but some misimplement the algorithm. If you're using a custom script or library, validate that it follows the canonicalization steps described in RFC 6376. Test against known good email samples using tools like the IETF’s DKIM specification.

Confirm your MTA or service doesn’t rewrap headers in transit without preserving DKIM-compatible formatting.
Verify your signing system uses relaxed canonicalization and applies consistent normalization to all header fields.
Replicate real-world delivery conditions with an inbox-placement test to observe whether DKIM survives on major providers.

The 3 steps described in “Verify your signing software applies relaxed canonicalizati…”, in order.

Use MailTester’s inbox placement testing to send a message through real mailboxes and verify whether DKIM and alignment pass in practice. This reveals whether header folding or normalization issues are blocking delivery — not just in theory, but in the wild.

Why consistent header handling matters for email reliability at scale

At scale, small inconsistencies in SMTP header folding can break DKIM canonicalization, leading to signature failures even when the message content is valid.

Without verification, these issues go undetected — making it impossible to distinguish between a legitimate failure and a formatting error, which harms sender reputation over time.

MailTester’s 98.9% accuracy catches these hidden problems during list hygiene and deliverability testing, ensuring headers are handled consistently and signatures remain valid.

Sources

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)
Benchmark testing of 15 major email service providers found about 10.5% of legitimate emails land in the spam folder and a further 6.4% go undelivered. — EmailTooltester deliverability benchmark (via WarmForge) (2026)

Keep reading

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

Frequently asked questions

Does SMTP header folding break DKIM authentication?

Yes, if the folding pattern changes between signing and verification — even slightly — it can cause DKIM signature mismatches, especially with strict canonicalization.

Can relaxed DKIM canonicalization fix folding issues?

Yes — relaxed canonicalization normalizes whitespace and line breaks, making it more resilient to minor folding differences during transit.

MailTester simulates real delivery and checks header structure during inbox-placement tests, identifying inconsistencies that could break DKIM.

What happens when DKIM fails due to header reformatting?

The email may be rejected or marked as unauthenticated, reducing inbox placement and harming sender reputation over time.

Is header folding required by SMTP standards?

Yes — RFC 5322 requires that lines in headers be no longer than 78 characters. Folding at 78 is standard practice.

Can email gateways cause DKIM failures through header changes?

Yes — some gateways reformat or re-wrap headers during transit without preserving the same canonicalization, leading to signature validation failure.

Should I use simple or relaxed canonicalization for DKIM?

Use relaxed canonicalization for better compatibility with modern email systems, especially when using non-strict MTAs or relays.

How can I test if my email client preserves DKIM header formatting?

Use real-time deliverability testing tools like MailTester to send test emails and inspect the final header structure in the receiving inbox.

Do all email providers check DKIM signatures the same way?

Most do, but variations in canonicalization handling can cause mismatches, especially when folding patterns change during transit.

Can header folding be automated correctly without breaking DKIM?

Yes — as long as folding is consistent and aligned with relaxed canonicalization rules, automated systems can preserve DKIM validity.

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

Relaxed allows whitespace stripping and line break normalization; simple requires exact string matching. Relaxed is more forgiving in real-world email flows.

How do I fix DKIM when testing shows a failure due to folding?

Audit your email pipeline for reformatting servers, ensure relaxed canonicalization is used, and test with a verified tool like MailTester before mass sending.