Why Line Breaks Matter in DKIM c=simple Signing

You sent an email with a perfect DKIM signature—yet it failed validation. Not because of a typo or wrong key, but because a single newline was missing where it should’ve been.

DKIM isn’t checking just the content. It’s checking every character, including line breaks. In c=simple mode, the exact formatting of headers—CR/LF pairs, spacing, placement—must match exactly what the receiver expects. One missing line break and the signature fails, no matter how correct everything else is.

Configuring your SMTP server to maintain consistent line breaks for DKIM c=simple compliance isn’t a niche detail. It’s a fundamental requirement for inbox delivery. If your server strips or alters newlines during transmission, your legitimate emails may be rejected or marked as spam.

Key takeaways

  • DKIM c=simple requires exact header formatting, including CR/LF line breaks, to pass validation.
  • Even a single missing newline in the header section can invalidate the entire DKIM signature.
  • SMTP servers must preserve line break consistency during message transfer to ensure DKIM c=simple compliance.

What Is DKIM c=simple and Why Does It Care About Line Breaks?

DKIM c=simple is one of two canonicalization methods defined in RFC 6376. It preserves the exact whitespace and line breaks in the email headers as they exist when signing. Unlike c=relaxed, which normalizes line endings and collapses spaces, c=simple requires that your SMTP server deliver headers exactly as signed. If your server alters line breaks before signing, c=simple will fail.

How c=simple Works in Practice

When you use c=simple, the DKIM signature relies on the raw, unchanged form of header lines. This means every newline character and space must match exactly between the signed message and the one received. If your SMTP server converts \r\n to \n, strips trailing spaces, or reflows long headers, the signature will not verify — even if the content is correct.

Let's say you're sending an email with a header like:

Subject: Important Update

From: [email protected]

If your server collapses the two spaces in Subject: or changes the \r\n line ending before signing, you’ll get a signature mismatch. This is why c=simple is stricter than c=relaxed, and why you must ensure your SMTP stack preserves formatting exactly.

Why This Matters for Your Email Delivery

DKIM c=simple is often chosen by senders who need strict control over header formatting — such as enterprise or technical users. It doesn’t tolerate any post-signing modifications, making it ideal for environments where message integrity is critical.

But this strictness means configuration mistakes easily break DKIM. You must test your email flow end-to-end. Verify that headers stay unaltered from the moment they’re signed to when they’re delivered. Use tools like inbox placement tests to validate the full delivery chain, including signature validation.

For more precision, you can also verify individual domains or addresses before sending with MailTester’s email checker. It checks for valid syntax, known disposable domains, and common delivery issues — helping you catch problems before they affect your DKIM signature.

For details on how DKIM canonicalization works, consult the official specification: RFC 6376 – Section 3.5 covers the two canonicalization methods. You can also test how your server handles headers with tools like MXToolbox for real-time header analysis.

How SMTP Server Line Break Handling Affects DKIM Validity

DKIM signatures with c=simple are sensitive to exact header formatting — even minor changes like altering line endings from \r\n to \n or trimming whitespace break the signature validation. If your SMTP server rewrites line breaks during transmission, the signed headers no longer match the transmitted version, causing DKIM to fail. You must verify that your server preserves original formatting throughout the entire email lifecycle.

Line Endings Are Not Always Preserved in Transit

Many SMTP servers process messages and normalize line endings from \r\n to just \n, especially when handling messages through intermediary systems or API gateways. This normalization may seem harmless, but it directly violates the c=simple signing rule, which requires that the header sequence used in signing be unchanged when transmitted. Even if you signed with \r\n, if the server sends with \n, the verification fails.

Let’s be clear: DKIM validation checks the exact content of headers as sent across the wire, not as they were originally drafted. The signing process relies on cryptographic consistency across all stages. If your server adds, removes, or rewrites line breaks (or trims leading spaces), the signature becomes invalid. This is not a configuration error on your part — it's a common behavior that can slip under the radar until inbox placement drops and your reputation suffers.

Why c=simple Is So Fragile

The c=simple canonicalization method is designed to be straightforward: sign the headers as they appear, transmit them exactly as signed. But it doesn’t tolerate any transformation. Even collapsing multiple line breaks into one or removing trailing spaces in headers will invalidate the signature. This sensitivity is by design — it ensures message integrity. But it also makes DKIM failure more likely when line handling isn’t managed carefully during SMTP transmission.

For example, if your email client or API library prepends a space to a header field like Subject: before signing, and your SMTP server strips that space during delivery, DKIM will fail. The same applies to how line breaks are stored in the raw message. The DKIM specification (RFC 6376) explicitly states that the canonicalized header must match the transmitted one exactly.

If you’re unsure whether your sending infrastructure preserves header formatting, test your messages in a real-world inbox environment. Tools like MailTester’s inbox placement tester can expose delivery inconsistencies that aren’t visible in log analysis alone. Verify header integrity early — before your campaigns go live — to ensure DKIM stays valid across all delivery paths.

Step-by-step: Ensuring Line Break Retention in SMTP Output

Configure your SMTP server to emit headers with literal CRLF (\r\n) line breaks and disable any header normalization. Use raw inspection tools to verify output matches RFC 5322, ensuring DKIM signatures with c=simple remain valid. If your MTA strips or rewrites line breaks, signing fails or is rejected by receivers that enforce strict format checks.

Check SMTP Output Format at the Source

  1. Verify your MTA (Postfix, Exim, etc.) does not preprocess or rewrite headers before transmission. Many tools auto-normalize line endings to LF only, breaking DKIM with c=simple where exact formatting must be preserved.
  2. Ensure headers are written using CR/LF (\r\n), not just LF. The RFC 5322 standard requires CRLF as the line break sequence in email headers, and some DKIM validators enforce this strictly.
  3. Disable any canonicalization or normalization filters in your mail stack. These often sanitize whitespace and line endings, which violates the c=simple signing mode's requirement for exact header copying.
  4. Use debugging tools like smtpd -d or tcpdump to capture raw SMTP sessions. Inspect the actual bytes sent—look for \r\n after each header line, not just \n.
  5. Compare your output against a known valid DKIM-signed message from a trusted source. Tools like MXToolbox or Mail-Tester can show header formatting issues in practice.

Validate with Real-World Testing

Let’s test what works in production. Send a test message with known DKIM headers, including a c=simple signed body, and examine the raw envelope. If any line break is missing or altered, DKIM verification will fail—even with a correct signature.

Use a real-time verification API to pre-validate addresses before sending, helping avoid routing issues that stem from malformed headers. Verify your list at scale to catch invalid or improperly formatted senders early.

When in doubt, always inspect the raw SMTP stream. The difference between CR/LF and LF is small, but it’s what keeps DKIM c=simple compliant, prevents rejection by strict receivers, and maintains sender reputation.

Common SMTP Server Misconfigurations That Break c=simple

When you configure your SMTP server, auto-escaping headers, improper line-ending conversion, regex-based rewriting, or header folding can distort the canonical form of DKIM signatures. This breaks c=simple compliance because DKIM signing expects headers exactly as they appear in the raw message—no changes to whitespace, line breaks, or casing. Even small alterations during transport invalidate the signature.

Auto-escaping headers with tools like Milter or Content Filters

  • Some content filters or Milter tools automatically escape or quote special characters in headers, which modifies the raw header text. This breaks the canonical form required by c=simple and invalidates DKIM verification.
  • For example, a Subject: Hi =?UTF-8?B?VmlzaW5p?=?= header can get rewritten into Subject: Hi "VmlzaW5p", changing the signature value.
  • Ensure your filtering tools operate only on content-body, not on headers. Check your Milter config for header_filter or replace_headers directives.

Misuse of line-ending conversion tools or MTAs with automatic line folding

  • Using dos2unix or unix2dos on raw email headers can alter line breaks, especially if they affect the From:, To:, or Subject: fields. Even one extra space or CR-only line ending changes the canonical representation.
  • MTAs like Exim, Postfix, or Sendmail may default to folding long headers (e.g., splitting a 76-byte line into two 38-byte lines). This is a common source of failure in c=simple compliance because the signing process uses the raw, unfolded version.
  • Disabling header_folding or fold_length settings in your MTA config ensures headers remain unaltered during transport. Consult your MTA's documentation, e.g., RFC 5322, Section 2.2.3, on header structure and acceptable line length.
  • Regex-based rewriting rules that modify whitespace or strip trailing newlines in headers will break DKIM c=simple because they alter the message’s canonical form.
  • Even subtle rules like gsub(/\s+/, ' ') in a filter can reduce multiple spaces to one, which is not allowed during DKIM signing.
  • Verify that your email processing stack does not apply such transformations. Test with raw headers from a signed message before and after filtering.

Before sending, use tools that verify the exact header structure in the raw message. For example, mail testers can simulate how a message arrives at the receiving MTA. The inbox placement tester helps you check whether your signature remains intact after transit.

How to Validate Your SMTP Output Matches the DKIM Signature

You must verify that your SMTP server emits headers and body content exactly as signed by DKIM, with raw \r\n line breaks, no folding, and no whitespace changes between header names and values. Even minor alterations break the signature. Use tools like dkim-verify from OpenDKIM to compare the original message against the signed version and catch inconsistencies before they cause delivery failures.

Step-by-Step Validation Process

  1. Generate a test message with known headers and body text. Include specific line breaks and formatting you’re testing. Use an SMTP client that lets you control the raw output, such as OpenSSL or a custom script. This gives you a predictable baseline for comparison.
  2. Apply DKIM signing using your server or a test tool. Ensure your signing process uses c=simple canonicalization. This mode requires you to preserve the exact byte sequence of headers and body, including the original line breaks.
  3. Extract the raw signed message and run dkim-verify. The OpenDKIM suite includes a utility that parses the signature and checks it against the canonicalized version. Run it with the full message, not just headers. This tool will flag any mismatches in line breaks or whitespace.
  4. Compare the original message against the signed version byte-for-byte, excluding only the DKIM-Signature header. Use a hex diff tool or a script to verify that every line break is \r\n, not \n or \r\n\r\n. Folded lines in the header (where a long value wraps with a space) must not exist in the final signed output.
  5. Check header formatting: ensure no space or extra character exists between field name and colon. For example, Subject: Test is correct. Subject : Test or Subject: Test with a leading space is invalid under c=simple.

Common Pitfalls to Watch For

  • Some SMTP libraries automatically fold long header lines using space + newline. This is not compliant with c=simple. Disable auto-folding.
  • Editor or log formatting may normalize line endings to \n. Use hex output to confirm encoding.
  • Post-processing scripts may strip or rewrite whitespace. Validate at each stage of delivery.

DKIM c=simple is strict about content fidelity. A single extra space or line break alters the hash. Use MailTester’s email checker to validate that recipient addresses are valid before sending, ensuring your email infrastructure doesn’t break on delivery due to format issues.

The Role of MailTester in Verifying DKIM-Ready Email Output

You can use MailTester to confirm that your SMTP-sent emails maintain proper line breaks in DKIM headers, ensuring compliance with DKIM’s c=simple signing mode. Its inbox-placement tester analyzes actual header structure across real mail providers, checking whether your DKIM signature passes validation without being disrupted by malformed line breaks during transit.

Real-World Testing for DKIM Signature Integrity

DKIM relies on precise header formatting — each line must be terminated correctly with CRLF. Even small deviations break the signature. MailTester’s inbox-placement test sends your email to major providers like Gmail, Outlook, and Yahoo, then verifies whether the DKIM signature remains valid post-delivery. This reveals issues that static validators or local tests might miss.

Unlike tools that only check syntax, MailTester checks real delivery outcomes. A malformed header might pass a parser but fail in a live inbox. This is how you catch the difference between a “valid-looking” header and one that actually works.

Proactive Checks with API and Bulk Verification

Let’s say you're configuring an SMTP server and want to test before going live. Use the real-time verification API to validate individual addresses and simulate sending conditions. It returns structured feedback on header compliance, including line break issues that could break DKIM signing.

For larger campaigns, run bulk list verification to spot patterns. If multiple addresses fail with "header malformed" or "DKIM invalid," it’s likely a server-side misconfiguration — not a recipient issue. MailTester’s bulk test identifies these early, so you’re not sending to invalid or unstable destinations.

When you’re unsure why a header isn’t signing right, the in-app AI assistant can analyze an example message and flag formatting quirks like incorrect line breaks, extra whitespace, or improper header folding. It’s not just checking validity — it’s guiding you toward the fix.

Use the inbox-placement tester to send a real message through MailTester’s network and see exactly how it’s processed by major providers. You’ll get a clear report: DKIM pass, DKIM fail, or header corruption. No guesswork.

How DKIM c=simple Line Breaks Relate to Sender Reputation and Deliverability

Even small flaws in DKIM header formatting—like incorrect line breaks in c=simple signatures—can cause validation failure, leading to inbox placement drops or hard bounces. While SPF and DMARC might pass, a single DKIM failure invites spam filter scrutiny, erodes sender reputation, and triggers deliverability issues with Gmail and Outlook over time. Consistent, correct header alignment is part of maintaining a reliable sending pattern.

Why DKIM Failure Impacts Deliverability

DKIM signature validation is not optional—it's a gatekeeper. If a receiving server rejects the signature due to malformed line breaks in the c=simple canonicalization, the message is treated as unverified. This often means the email lands in spam or is rejected outright.

Even if your SPF and DMARC records are correctly set, a DKIM failure is a red flag. Providers like Gmail and Microsoft’s Exchange don’t rely on one check—they correlate behavior across multiple signals. Repeated failures, even from legitimate senders, signal instability. Once flagged, you’ll have a harder time getting past their filters, even with clean content and a known inbox.

Line Breaks Are Part of the Process, Not a Detail

DKIM c=simple uses a specific canonicalization process where line breaks must be preserved precisely as they appear in the original message headers. The standard requires CRLF (\r\n) at the end of each header line, not just LF (\n), and no extra spaces after the break. Missing or corrupt line breaks break the signing math—resulting in failure, even if everything else is technically correct.

Think of it like a digital signature on a document. If the document’s formatting changes in transit—say, line breaks shift—the signature is invalid, even if the contents look fine. The same applies here: a mismatch in header structure breaks the cryptographic integrity, and the email gets flagged.

For sending teams, this means consistency at the protocol level matters. Automated systems that generate headers (like transactional email engines or marketing platforms) must preserve line breaks exactly. Tools like MailTester's bulk verification can help identify lists with problematic addresses that may be silently failing due to alignment issues in past deliveries.

For developers and admins, validate your headers using tools that simulate real-world receiving behavior. Check RFC 6376 (the DKIM specification) for the canonicalization rules directly. The IETF’s DKIM RFC is definitive—no guessing, no shortcuts. Even small deviations hurt trust scores over time.

Best Practice: Test Your SMTP Line Break Behavior Before Going Live

You must verify that your SMTP server preserves line breaks exactly as required by DKIM’s c=simple canonicalization before sending to production. Even a single incorrect newline or whitespace change can break signature validation. Test in a staging environment with real DKIM signing, compare results across Gmail, Yahoo, and Microsoft, and inspect headers at every hop to ensure consistency.

Validate output through real-world testing

  • Set up a staging environment that mirrors your production setup, including the actual DKIM signer you’ll use in production.
  • Send test messages with known c=simple compliance: ensure headers are folded using LF (line feed) only, not CRLF, and that whitespace is preserved exactly as specified in RFC 6376.
  • Use a tool like RFC 6376 to reference the canonicalization rules and ensure your output matches the expected format.
  • Inspect the final DKIM-Signature header in the delivered message—don’t rely on local logs or pre-signature output only.

Test across multiple email providers

  • Send identical test messages to Gmail, Yahoo, and Microsoft (Outlook/Hotmail) using separate accounts.
  • Check how each provider parses and displays the headers after delivery. Some apply post-processing or normalize whitespace, which can affect header validation.
  • Compare header output from each inbox—pay close attention to the exact sequence of line breaks and whitespace in both the signed headers and the DKIM-Signature field.
  • Use a header inspection tool like MxToolbox or built-in email debugging tools in your client to verify the final canonicalized form.

Consistently log headers at every stage: from the MUA (user agent) through your MTA, through the DKIM signer, and again after the second MTA. This reveals where line breaks are altered—often silently—by filters, relay software, or SMTP gateways.

Let’s be clear: a single misplaced CR, extra whitespace, or auto-optimized line break can invalidate your DKIM signature—even if your public key is correct. This isn’t about opinion. It’s about compliance with the standard.

Pro tip: test your real list of senders with MailTester’s bulk verification to catch invalid or improperly formatted domains before they go live.

What to Do If Line Breaks Are Still Not Working

If your DKIM signature still fails c=simple validation despite line break preservation, check your entire email processing pipeline. Line breaks can be stripped by content filters, Milters, or header-normalization tools running before or after DKIM signing. The most common cause is signing after normalization, or using a library that auto-trims whitespace. You must sign with the original, unmodified header structure.

Check Your Email Flow for Interception Points

  • Review all Milters, antivirus scanners, or content filters between your SMTP server and DKIM signer—these often normalize headers and strip line breaks.
  • Look for any rule that normalizes whitespace, especially in the Subject, From, or To fields.
  • Test your message with a raw, unprocessed header to confirm if the line breaks survive end-to-end.
  • Use tools like MxToolbox or RFC 6376 to decode and debug DKIM signatures.

Verify Your DKIM Signing Pipeline

  • Confirm your DKIM signing process occurs before any header normalization or content filtering.
  • If you’re using OpenDKIM or a similar library, ensure it’s configured to preserve the original input format. Do not enable automatic cleanup.
  • Avoid any DKIM service or library that promises “automatic header cleanup” — these inherently break c=simple compliance.
  • Manually inspect the raw headers pre- and post-signing to verify line breaks are preserved exactly as sent.
  • Ensure your signing tool does not reformat or re-indent headers, even if they seem functionally identical.

Let’s be clear: DKIM c=simple is strict. It verifies the signature against the exact wire format. Even a single missing newline between headers can invalidate it. If you're unsure whether your setup is preserving structure, test your full pipeline with a known good test case—tools like MailTester’s inbox placement tester help simulate real conditions across inboxes and filters.

Summary: Line Break Preservation Is Non-Negotiable for c=simple

DKIM with c=simple requires exact message alignment from signing to verification. Any change to line endings — especially stripping or normalizing \r\n to \n — breaks the signature validation.

SMTP servers must preserve the original message structure end-to-end. Even invisible formatting changes during routing, parsing, or delivery can invalidate the signature, causing deliverability failures.

Verify Before You Send

  • Use MailTester’s real-time API to validate email formatting and DKIM compliance before sending.
  • Run inbox tests to confirm message integrity reaches the recipient’s client without modification.
  • Automate checks to catch misconfigured servers or routing tools that alter line breaks.

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 happens if my SMTP server changes line breaks in headers?

DKIM c=simple fails because the signed content no longer matches the transmitted version. This causes deliverability failure.

Does c=simple require CR/LF or just LF for line breaks?

c=simple requires the original line breaks, so CR/LF (\r\n) must be preserved. LF-only is not valid.

Can a content filter break DKIM c=simple?

Yes—even minor changes like trimming whitespace or folding long lines can break validation.

How do I know if my DKIM signing is using c=simple?

Check the DKIM-Signature header for the c=simple tag. It appears as "c=simple" in the signature.

Is c=simple more secure than c=relaxed?

Not inherently. c=simple is stricter and more prone to breakage, but it preserves exact content for integrity.

Why does DKIM fail if headers have line break issues?

DKIM verifies that the signed content exactly matches what the receiving server sees. Line breaks are part of the signature.

Can MailTester help me find line break issues in my email output?

Yes. MailTester's inbox-placement tests analyze headers and detect formatting issues that break DKIM.

Do all email providers enforce c=simple line break rules?

Yes. Providers like Gmail, Yahoo, and Microsoft validate DKIM signatures using the exact input, including line breaks.

Should I disable all header normalization in my SMTP server?

Yes, if you use c=simple. Disabling normalization preserves the original structure for DKIM validation.

Can I use c=simple with third-party email services?

Yes, but only if the service preserves header formatting. Some platforms normalize lines and break c=simple.

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

c=simple preserves whitespace and line breaks. c=relaxed normalizes them. c=relaxed is more forgiving but less strict.

How do I test if my DKIM c=simple is working correctly?

Sign a test message with c=simple, send it, and verify the signature using tools like dkim-verify or MailTester’s inbox tests.