Why Does DKIM c=simple Break When Line Endings Are Modified?

You sent a perfectly signed email. The DKIM header looks correct. The recipient’s mail server says the signature failed. And the reason? A single character — the line ending. DKIM doesn't care about your message content. It cares about the exact byte stream, including line endings. When a message passes through a system that normalizes line endings (like CRLF to LF), the signature created with c=simple fails to verify. No matter how correct the rest of the email is. This happens because c=simple is brittle. It expects the raw message body to match the format at signing time — down to every newline. Even minor changes during transit or processing break the cryptographic chain.

Key takeaways

  • DKIM c=simple fails when line endings are altered, even if content is unchanged.
  • SMTP systems commonly convert CRLF to LF during transit, breaking c=simple signatures.
  • Using c=relaxed canonicalization instead of c=simple prevents line-ending issues.

What Is DKIM c=simple Canonicalization?

DKIM c=simple is a canonicalization method defined in RFC 6376 that applies minimal changes to email headers and body during signature validation. It preserves original line endings in headers and only normalizes body line endings to CRLF if they’re different—making it simpler but fragile when message content is altered post-signature.

How c=simple Works in Practice

When you use c=simple, the signing server preserves the exact headers and only adjusts body line breaks to CRLF if needed. This works fine if the message isn't modified after signing. But if a relay, gateway, or mail server changes line endings—say, from CRLF to LF or vice versa—the canonicalized version no longer matches the original, and the signature fails.

Let’s say you send an email with CRLF line endings. The DKIM signature is created with that format. If a system in your email pipeline (like a content filter, proxy, or MTA) rewrites lines using LF, the signature becomes invalid—because c=simple doesn’t normalize body line endings after signing. The receiver sees a mismatch between the signed content and what was delivered.

Why This Matters for Email Deliverability

DKIM validation failures often go unnoticed until you see bounces, blocked messages, or poor inbox placement. The c=simple method is sensitive to these small changes—especially in systems that auto-format messages for internal processing.

You don’t want your emails to fail DKIM checks because a server altered line endings. The fix usually lies in either switching to c=relaxed (which normalizes all line endings) or ensuring your pipeline doesn’t touch the payload after signing. For example, Mailchimp and SendGrid handle this internally—but if you’re using a custom or in-house email engine, you need to verify your pipeline preserves the original format.

Testing is essential. Use a real-time verification API to catch invalid DKIM signatures before sending. You can test email headers and body consistency right before delivery with tools like MailTester’s inbox-place testing or API checks before your campaign goes live. It’s not enough to assume your stack is clean—many systems silently alter content.

RFC 6376 defines DKIM, including the c=simple and c=relaxed canonicalization mechanisms. The Spamhaus Project tracks common delivery issues including alignment and signature validation failures that affect sender reputation.

How Do Modified Line Endings Occur During Email Processing?

Line endings—specifically, the carriage return and line feed sequence (CRLF) used in email body text—can be altered during transmission when systems using different operating systems (like Unix, which uses LF only, versus Windows, which uses CRLF) process the message. Even when a DKIM signature is generated with the original line endings, downstream systems may normalize them, breaking the signature verification.

Server and System Differences Trigger Line Ending Changes

Many email servers and clients interpret CR/LF differently. A message sent from a Unix-based system may arrive on a Windows server where the line endings are normalized to CRLF without preserving the original format. This reformatting occurs during parsing, queuing, or relaying, especially when messages pass through legacy systems or older MTAs that default to canonicalizing line endings in their internal processing.

Mail Clients and Middleware Often Re-Format Text

Mail User Agents (MUAs) like Outlook or Gmail may reformat content when rendering previews or storing messages. MTAs or middleware handling message queues may also normalize line endings during storage or during routing through third-party services. These changes happen even if the original message is correctly formatted.

Content transformation tools—common in email marketing platforms such as Mailchimp or HubSpot—often apply automatic text normalization to improve readability or consistency. If these tools alter line endings without preserving the signature context, they break DKIM validation. This is especially common when HTML content is processed or when plain-text versions are generated from templates.

According to RFC 5322, which defines the Internet Message Format, line endings should be CRLF, but many systems process and relay messages with inconsistent handling of this rule. The Internet Message Format standard itself acknowledges that implementations vary, leading to real-world inconsistencies—particularly in environments that don’t strictly validate or preserve line ending integrity during relaying.

When DKIM uses canonicalization method c=simple, it expects the original line ending structure to remain unchanged. If a server or intermediary alters the line endings during transit—either by adding, removing, or merging them—the verifier will reject the signature, even though the message content is identical.

Let’s not overcomplicate this: the core problem is that systems don’t always keep line endings as they were when the signature was created. If email platforms or middleware reprocess messages without maintaining the original format, DKIM fails.

To avoid this, email senders should verify that their systems—including any third-party email tools—maintain the original line ending structure during message processing. Use tools that test delivery integrity and validate both content and signature alignment. Test inbox placement with real-world message paths to spot where line ending normalization happens.

How to Reproduce a c=simple Canonicalization Failure

You can reproduce a c=simple canonicalization failure by sending an email with a DKIM signature that uses CRLF line endings in the body, then modifying the message body to use LF-only line endings before delivery. Receiving servers validating DKIM with the c=simple algorithm will reject the signature because the body hash no longer matches the original—due to differing line ending normalization. This happens because c=simple does not account for line ending changes, unlike c=relaxed.

  1. Generate a valid DKIM-signed email with CRLF line endings. Use a tool like RFC 6376 as a reference to craft a message with proper DKIM-Signature headers, ensuring your body uses CRLF (carriage return + line feed) for line breaks. This mimics the format standard for email bodies.
  2. Modify the body to convert CRLF to LF. Use a script or editor (e.g., Python’s str.replace('\r\n', '\n')) to change all line endings in the message body to LF only. This change will not affect the DKIM signature itself, but it alters the canonicalized body.
  3. Resubmit the modified message via a receiver that validates DKIM with c=simple. Send it through a server that enforces strict DKIM verification, such as Gmail or Yahoo, using their standard submission paths. These systems validate signatures using the default c=simple canonicalization unless otherwise specified.
  4. Observe the DKIM signature failure. The receiving server will compute the body hash using LF-only normalization, while the DKIM signature was created using CRLF. This mismatch causes verification to fail, even though the message content is logically identical.

Why c=simple is sensitive to line endings

Unlike c=relaxed, which normalizes line endings before hashing, c=simple preserves the exact body layout. As defined in RFC 6376, Section 3.7, the body canonicalization process for c=simple applies only minimal formatting, meaning any change in line endings alters the hash. This is why tools that rewrite or filter email content must preserve the original line-ending structure when preserving DKIM integrity.

Tools that help prevent this issue

When building email workflows, always test DKIM signatures against resubmitted messages with line-ending changes. You can verify if your system preserves the original canonicalization layer using a delivery test that simulates real inbox conditions. Tools like MailTester's inbox placement testing help uncover these edge cases before they appear in production.

Key Differences in DKIM Canonicalization: simple vs relaxed

You’re seeing a DKIM signature failure with c=simple when your message has modified line endings because c=simple requires the exact original formatting—any change to line breaks (like LF to CRLF) breaks validation. In contrast, c=relaxed normalizes line endings to CRLF and ignores whitespace variations in headers, making it more forgiving. The trade-off: c=relaxed is widely used for bulk email, but c=simple is needed when strict message integrity is required—such as in transactional systems with tight compliance rules.

How Each Canonicalization Type Processes the Message

Let’s look at how each method handles the core components of a DKIM-signed message.

Factor c=simple c=relaxed
Line endings Preserves original line endings exactly. LF, CRLF, or CR all must match unchanged. Normalizes all line endings to CRLF before signing and verifying.
Whitespace handling in headers Treats any difference in whitespace (extra spaces, newlines) as a signing mismatch. Ignores excess or missing whitespace in header fields during canonicalization.
Use case Required by systems enforcing message integrity—common in financial, legal, or regulated transactional email. Standard for most marketing and bulk email where minor formatting variations are inevitable.
Failure tolerance Zero tolerance: one changed line ending causes failure. High tolerance: accepts variations that don’t affect semantic meaning.

Why You Should Know the Difference

If your email fails DKIM with c=simple after sending, the root cause is often non-identical line endings in the message body or headers. This can happen during transport, through email clients, or due to server-side rewriting. Tools like MailTester’s email checker can validate the signature’s expected behavior early—before sending—to avoid these issues. While c=relaxed is more common, c=simple remains critical for compliance-heavy environments. RFC 6376 (the DKIM standard) defines both methods, and their behaviors are consistent across implementations. For systems using strict policies, such as those in regulated industries, testing the exact signature canonicalization is essential—especially when modifying messages in transit.

How to Detect DKIM Signature Failures from Line Ending Issues

If your DKIM verification fails with dkim=permerror or dkim=fail after receiving a message, check the full Received headers for discrepancies between the original body and the received body—especially around line endings. If the message was rewritten during transit (e.g., CRLF to LF or vice versa), and the canonicalization is set to c=simple, the signature will likely fail. Use tools like MxToolbox or Spamhaus to validate DKIM alignment and verify whether the signature was invalidated at the point of receipt.

Check for Misaligned Line Endings in Header Data

  • Look for dkim=none, dkim=permerror, or dkim=fail in the Authentication-Results header.
  • Compare the raw body from the original message (as sent) with the body in the received headers—pay close attention to line endings (CRLF vs LF).
  • Confirm that the message was not reformatted during transit, especially if the sender uses c=simple canonicalization, which does not normalize line endings.
  • Use MxToolbox’s DKIM lookup to examine the record and see if the signature aligns with the received message body.
  • Check the receiving server’s logs to verify whether the message was altered in transit—such as when a gateway normalizes line endings.
  • Verify the DKIM signature using Spamhaus’ lookup tool to detect whether the signature was rejected based on body changes.

Validate Canonicalization Settings and Message Integrity

  • Ensure that the sender’s DKIM policy uses c=relaxed instead of c=simple if line endings are likely to change during transit.
  • Check the DKIM signature’s l (body length) and q (canonicalization method) values in the header to assess alignment.
  • Use a real-time email verification tool like the MailTester email checker to validate if the recipient's domain publishes a functioning DKIM record.
  • If you’re troubleshooting delivery issues, test inbox placement using the MailTester inbox tester to see how messages with altered line endings fare across real provider inboxes.

What Tools Can Help Verify and Fix DKIM Line Ending Problems?

MailTester’s real-time verification API lets you validate email addresses and test message signatures in a live environment, catching DKIM signature failures caused by modified line endings before they hit your inbox. You can send a sample message with your headers and body exactly as it will appear in production, and MailTester will reveal whether your DKIM signature is broken due to inconsistent line ending handling—specifically c=simple canonicalization issues.

Test Signatures in Real Conditions with Live Email Testing

DKIM’s c=simple canonicalization requires that all line endings be normalized to CRLF (Carriage Return + Line Feed), even if your email client or mail server uses LF or raw bytes. If your email is processed by a tool that alters line endings—such as a relay, gateway, or testing script—your DKIM signature can fail. MailTester’s inbox-placement testing simulates delivery through Gmail, Outlook, Apple Mail, and other major providers, exposing these issues in real time.

Unlike static validators, MailTester processes full headers and bodies through actual SMTP transactions, mirroring how real inboxes evaluate incoming messages. This means you catch problems that only appear when content is rewritten or normalized during transit. The test includes header checks, body hashing, and signature validation under real-world rules. For example, if your system converts LF to CRLF after signing, but you're using c=simple, the verification will fail.

Use the AI Assistant to Identify Encoding Inconsistencies

Let’s say your automated email sender is built on a stack that standardizes line endings differently than the receiving mail server expects. You can paste your raw email into MailTester’s in-app AI assistant, which analyzes the header structure and body formatting, flagging inconsistencies in how line endings are applied between signing and delivery. It highlights where a change in line ending format—like LF being kept instead of converted to CRLF—breaks the c=simple canonicalization rule.

This is especially useful when debugging issues in systems that log email content after the fact but not in real time. The AI assistant parses headers, detects non-CRLF line endings in the body, and suggests fixes. It’s not a magic fix, but it tells you exactly what to change: "Your message uses LF line endings in the body, but c=simple requires CRLF." You can then adjust your email generation pipeline accordingly.

For more details on how DKIM canonicalization works, refer to the standard at RFC 6376, specifically section 3.4 on header and body canonicalization. The same principle applies to email sanitizing tools and third-party email providers. Make sure your signing process aligns with the expected format—especially when using c=simple.

Test your entire workflow with MailTester’s inbox-placement tester to ensure your messages pass DKIM validation under real delivery conditions.

How to Fix Line Ending Issues Before DKIM Signing

DKIM signatures can fail when line endings change after signing, especially if the canonicalization mode is set to c=simple. To fix this, ensure your email pipeline uses consistent CRLF line endings throughout—especially during message construction and before signing. Any modification to line endings after the DKIM signature is generated will invalidate the signature, even if the content is otherwise correct.

Preserve Line Endings from Start to Sign

  • Use only CRLF (Carriage Return + Line Feed) for all outgoing email content; avoid mixing LF-only or inconsistent formats.
  • Configure your email building tools (e.g., SMTP clients, email templates, rendering engines) to preserve original line endings during message construction.
  • Verify that the message body and headers are transmitted with CRLF in the final payload used by the signing engine.
  • Never apply automatic line ending normalization unless it explicitly accounts for DKIM signature context and preserves the exact byte sequence used at signing time.

Handle Line Endings in the Email Pipeline

  • Validate that your MTA (Mail Transfer Agent) or relay does not rewrite line endings during processing—many do so by default, which breaks c=simple DKIM.
  • If you must normalize line endings, use c=relaxed canonicalization instead, which is tolerant to small formatting changes.
  • Test your entire email pipeline using a known-good test case with a signed message and verify the final output matches the signed version byte-for-byte.
  • Use tools that allow you to inspect the raw message before and after signing—RFC 6376 (Section 3.4) describes how DKIM signing works on the wire.
Even a single character change in the canonicalized body can break DKIM validation when using c=simple. The integrity of the signature depends entirely on byte-identical content.

You can prevent line-ending issues by treating the email body as a binary stream during signing. If you're using a service that handles message signing, confirm they offer control over canonicalization and preserve original line endings. For example, MailTester’s inbox placement tests include DKIM validation checks and help catch signature issues before your messages reach the inbox. Test your emails in real inboxes to verify signature integrity and delivery health. If you're processing large lists, use the bulk verification tool to filter out invalid or improperly formatted addresses early.

Best Practices to Prevent DKIM Breakage from Line Endings

If your DKIM signature fails due to modified line endings, you’re likely using c=simple and not accounting for how mail systems normalize line breaks. The fix is simple: standardize line endings in your message generator, prefer c=relaxed when possible, and test with tools that replicate real-world delivery behavior — including header/body reconstruction.

Control line endings at the source

  • When sending transactional emails via code, ensure your message generator uses consistent line endings — always CRLF (\r\n) — and never convert them downstream.
  • Let’s be clear: if your app or framework auto-converts line endings on output, the DKIM signature will break during verification. This is not a corner case; it’s a common root cause.
  • Use environment-level or library-level settings to lock down line ending behavior. For example, in Node.js, avoid relying on default fs.writeFile behavior; explicitly specify encoding: 'utf8' and use '\r\n' when writing message bodies.

Choose the right canonicalization for your needs

  • If your system must handle inconsistent line endings—say, from legacy clients or non-compliant SMTP agents—use c=relaxed instead of c=simple. This relaxes checks on line breaks and white space, reducing breakage from minor formatting changes.
  • Use c=simple only in environments where you fully control the message format and can guarantee consistent line endings. Otherwise, c=relaxed is more robust in practice.
  • When in doubt, test your DKIM signing with tools that simulate real-world delivery. Tools like RFC 6376 specify canonicalization behavior; verify you’re following it correctly.

One way to catch this early is to test DKIM verification against real delivery chains using inbox placement tools that reconstruct the message exactly as it arrives in the recipient’s server. For example, use MailTester’s inbox placement testing to see if your DKIM signature survives transport — including header and body normalization.

Why Email Verification Tools Like MailTester Are Key to Catching These Issues Early

You can’t fix DMARC or DKIM issues if you don’t know the email infrastructure is broken. Tools like MailTester catch problems like inconsistent line endings in outbound messages before they cause authentication fails, invalid DKIM signatures, or delivery drops — and they do it at scale, with 98.9% accuracy, so you’re not just cleaning up bad addresses, but validating the entire send environment.

Spotting Line Ending Issues in Bulk Data

When you send thousands of messages, even small formatting quirks—like inconsistent line endings (CRLF vs LF)—can break DKIM validation when the canonicalization mode is set to c=simple. That mode processes each line exactly as it appears, so any mismatch between what the sender sent and what the receiver expects results in a signature mismatch. MailTester’s bulk list verification checks not just if an address exists, but also whether the infrastructure likely supports the message format in use.

Let’s say your data comes from multiple sources: a CRM, a web form, and an imported CSV. Each may use different line-ending standards. MailTester identifies these inconsistencies before you send, helping you understand which addresses might fail not due to spam traps or invalid domains, but because of malformed or non-standard content.

Testing Before You Send, Everywhere You Send

Integrations with platforms like SendGrid, Mailchimp, and Klaviyo let you test real-world sending conditions. You can run a real inbox placement test with your exact template, subject line, and sending environment. If your email has mixed line endings and your DKIM is set to c=simple, this test will catch the failure early—before it hits your reputation.

According to RFC 6376, the c=simple canonicalization method does not normalize line endings, which makes it sensitive to formatting changes. If your message body uses inconsistent line endings, even a single line might break the signature. MailTester simulates this behavior across real mail servers, catching failures you might miss in a standard syntax check.

Using the bulk verification tool, you can clean your list and flag addresses that are likely to trigger authentication issues due to data-layer problems. The real value isn’t just in removing invalid emails—it’s in identifying the ones that won’t validate because of how they were crafted. That’s how you turn deliverability from a guess into a process.

Final Verdict: Fixing DKIM c=simple Requires Control Over the Entire Pipeline

DKIM with c=simple is sensitive to any change in message content, even seemingly trivial ones like line ending normalization. CR/LF to LF conversions during transit or processing can invalidate the signature.

The solution isn't adjusting the signature—it's maintaining message integrity from origin to delivery. You must control the full email pipeline to ensure no intermediate systems alter the content in ways that break verification.

Use tools like MailTester to validate sender readiness. It detects delivery risks early, including issues related to MIME formatting, encoding, and line ending handling—before they impact inbox placement or sender reputation.

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 does DKIM c=simple mean?

DKIM c=simple is a canonicalization method that preserves the original line endings in the message. Any deviation breaks the signature.

Why does DKIM fail when line endings change?

Because c=simple expects the exact line ending format used during signing. Modifying them alters the message digest, making verification fail.

Can c=relaxed fix c=simple issues?

Not directly — c=relaxed is a different algorithm. But switching to c=relaxed can reduce line-ending sensitivity in new deployments.

How can I test if my DKIM signature is valid?

Use header inspection tools like MxToolbox or MailTester’s inbox-placement test to validate DKIM at the receiving end.

Are line endings always CRLF in email?

No — some systems use LF, especially on Unix-based servers. But DKIM c=simple requires consistency with the signing time.

Can a mail client change line endings during rendering?

Yes — if the client reformats the message before displaying or forwarding, it can break DKIM if using c=simple.

How do I verify if an email is properly signed?

Check the Received-SPF, DKIM-Signature, and Authentication-Results headers for pass/fail status and any error codes.

Does MailTester help with DKIM validation?

Yes — MailTester’s inbox-placement testing simulates delivery and checks DKIM signature validity in real-world conditions.

What happens if DKIM fails on a transactional email?

The email may be flagged as untrusted, rejected by the recipient’s server, or marked as spam.

How can I prevent future DKIM failures?

Maintain consistent line endings from creation to delivery, avoid automatic formatting, and test with tools like MailTester.

Is c=simple still used in modern email systems?

Yes — especially in financial, government, or compliance-heavy environments where strict message integrity is required.

Do all email providers check DKIM signatures?

Most major providers check DKIM, but not all treat failures the same. Some allow delivery with a warning; others block.