Why does DKIM fail silently when you use CRLF in non-UTF-8 content?

You sent a message that looked identical to the original — same text, same headers, same encoding — but DKIM verification failed. No bounce. No error. Just quiet rejection. Why?

Different character encodings treat the same CRLF sequence (0xD 0xA) differently. In UTF-8, it’s two distinct bytes. In ISO-8859-1 or Windows-1252, it can be misinterpreted during parsing — and DKIM’s relaxed body canonicalization relies on consistent interpretation across all steps. Even a single byte mismatch during hashing breaks signature validation.

When the server reassembles the body for hashing, inconsistent line ending handling changes the byte stream — even if content appears unchanged. The DKIM signature was computed on one version; the receiver hashes another. The check fails, silently.

Key takeaways

  • DKIM relaxed body canonicalization assumes uniform line ending handling, which breaks under legacy encodings like ISO-8859-1 and Windows-1252.
  • CRLF (0xD 0xA) is interpreted as two bytes in UTF-8 but may be misaligned or altered in non-UTF-8 encodings due to parsing quirks.
  • Even a single-byte difference during canonicalization causes DKIM hash mismatch — leading to silent rejection, despite message content being visually identical.

What happens when DKIM relaxed body canonicalization encounters CRLF in non-UTF-8 messages?

When DKIM uses relaxed body canonicalization on a message encoded in non-UTF-8 (like ISO-8859-1 or Windows-1252), converting CRLF line endings to LF-only can fail silently if the parser misinterprets byte sequences due to encoding errors. This creates a canonicalized body that doesn’t match the original used during signing, causing signature validation to fail even if the content is otherwise correct. The issue isn’t the CRLF itself, but how encoding confusion disrupts the recovery of the original message structure during canonicalization.

The role of encoding in body canonicalization

DKIM’s relaxed body canonicalization standardizes line endings by replacing all CRLF, CR, and LF with a single LF. That’s straightforward in UTF-8, where byte sequences are unambiguous. But in non-UTF-8 environments, a sequence like CRLF (bytes 0xD, 0xA) can be parsed differently depending on the assumed encoding. If the parser assumes ISO-8859-1 instead of UTF-8, it may interpret byte 0xD as a valid character (a carriage return) but misprocess the next byte, especially if it’s part of a multi-byte sequence in another encoding.

This misinterpretation means the original byte sequence—especially around line endings—is no longer recoverable. Even if the canonicalization process attempts to normalize the line endings, the transformed body ends up differing from the one the signature was created on. The signature then fails validation because the signed body and the received body don’t match, regardless of content validity.

Why this matters for email deliverability

DKIM signature failures are one of the most common causes of email rejection by receiving servers. When a message arrives with a failed DKIM check, it’s often treated as suspicious or even spam, even if the content is safe. This can happen silently—your email reaches the inbox but gets filtered, or worse, outright blocked.

Even if you’re using a modern ESP, issues like this can emerge if your email engine doesn’t enforce UTF-8 strictly during signing. Some legacy systems or third-party tools still default to non-UTF-8 encodings, especially when handling older content or non-English text. This makes it critical to verify that both signing and parsing environments handle encodings the same way—preferably always with UTF-8.

Let’s be clear: CRLF isn’t the core issue. It’s the misinterpretation of byte sequences in non-UTF-8 contexts that breaks the canonicalization process. The fix? Enforce UTF-8 consistently across your email pipeline—from generation to signing to delivery. Tools like MailTester’s bulk verification can help you identify and clean up invalid or misconfigured email lists before they cause delivery issues like this.

For deeper insight, refer to [RFC 6376](https://datatracker.ietf.org/doc/html/rfc6376), which defines DKIM’s body canonicalization rules. The standard assumes consistent encoding interpretation, but real-world implementation varies.

How does UTF-8 vs. legacy encoding affect DKIM signature integrity?

DKIM relies on consistent, predictable body canonicalization, but legacy encodings like ISO-8859-1 or Windows-1252 can disrupt this when line endings (CRLF vs. LF) are misinterpreted during processing. If a message claims UTF-8 encoding but uses non-UTF-8 line endings—especially when parsed through systems assuming UTF-8—canonicalization may differ from the original. This causes DKIM signatures to fail, even if the message content is unchanged. UTF-8 avoids this by standardizing line-ending handling across all compliant parsers.

Why UTF-8 matters for DKIM consistency

UTF-8 normalizes line endings consistently. Every parser that respects it treats CRLF and LF in a predictable way, based on the message’s actual content and the canonicalization rules defined in RFC 6376. This means a DKIM signature generated with correct body canonicalization in UTF-8 remains valid across systems, assuming all steps are followed strictly.

Legacy encodings introduce fragility

Legacy encodings like ISO-8859-1 or Windows-1252 were not designed with the same level of line-ending standardization. When a message uses CRLF but claims to be in UTF-8—or vice versa—systems that assume UTF-8 may strip or alter line endings during processing. This mismatch leads to a different canonicalized body, breaking the DKIM signature even if the content is identical. The difference is subtle, but fatal to verification.

For example, a message using CRLF but incorrectly marked as UTF-8 can be processed differently than the same message with correct encoding tags. This inconsistency is why RFC 6376 specifies that relaxed body canonicalization must preserve the original line-ending sequence—something only reliably achieved when encoding is correctly declared and consistently handled.

Let’s say you send a message that tests fine in one system but fails DKIM when delivered through another. Chances are the encoding was misdeclared or misparsed. A tool like MailTester’s bulk verification can scan your list for such issues, flagging potentially malformed or improperly encoded messages before you send them.

It’s not just about technical correctness—it’s about deliverability. A failed DKIM signature means your message may be rejected or marked as spam. Always verify your message encoding header, ensure your tools are UTF-8-aware, and use tools that test real-world deliverability scenarios, including how systems handle edge cases in encoding and line endings.

What does 'relaxed' body canonicalization actually mean in DKIM?

Relaxed body canonicalization in DKIM lets validators ignore minor formatting changes—like extra spaces or line endings—when checking a message's signature, as long as the core content hasn't been altered. It normalizes text by trimming whitespace, collapsing multiple spaces into one, and converting all line endings to LF (Line Feed). This helps prevent false fails due to innocent formatting tweaks, but it only works reliably when the message’s encoding is consistent, especially with non-UTF-8 content.

How relaxed body canonicalization works under the hood

According to RFC 6376, relaxed body canonicalization processes each line by removing leading and trailing whitespace, replacing sequences of whitespace characters with a single space, and standardizing line endings to LF (ASCII 0x0A). This ensures that minor changes—like how a client adds a newline or uses tabs—don’t invalidate a valid signed message.

But here’s the catch: this normalization assumes all data is interpreted using a consistent character encoding. When a message uses an encoding like ISO-8859-1 or Windows-1252 and contains CRLF line endings (carriage return + line feed, as used in older Windows systems), those CRLF sequences can be misinterpreted during canonicalization. The validator sees them as a single character sequence, but if the encoding isn't properly handled, the resulting byte stream diverges from what the signer expected.

Why CRLF breaks relaxed body canonicalization in non-UTF-8 messages

Even though relaxed body canonicalization is supposed to be forgiving, it relies on correct character-level interpretation. If the message uses an encoding where CRLF isn't treated as a single logical line break (as in UTF-8), the validator might misparse the line boundary. This leads to a mismatch between the signed content and the normalized version, causing the DKIM signature to fail—despite the message being functionally identical to the original.

This is especially common with legacy email systems or poorly configured MTA software that assume CRLF is always used, regardless of encoding. It’s not that DKIM is broken—it’s that the assumptions about character handling during canonicalization fail when the encoding isn’t UTF-8.

For senders relying on DKIM for authentication, this means you can’t assume that “tolerance” for formatting differences means automatic forgiveness. You must ensure your email pipeline respects the encoding of the message body and avoids inconsistent line ending practices in non-UTF-8 contexts. Proper testing across varied environments helps catch these edge cases before they impact deliverability.

To avoid such issues, always validate your messages before sending. Use a tool that checks both syntax and content interpretation. For example, our inbox placement tester simulates how real email clients process your messages, including handling of line endings and character encodings.

How do CRLF line endings cause DKIM failure in non-UTF-8 messages?

When a non-UTF-8 email body uses CRLF line endings, parsers may interpret the byte sequence as a malformed character or misaligned boundary, especially if the encoding differs between signing and delivery. This misalignment breaks DKIM’s relaxed body canonicalization, where the hash computed during signing no longer matches the one recalculated on receipt — resulting in a signature failure, even if the message content is otherwise intact.

Why encoding context matters

DKIM computes a hash over the message body after applying canonicalization rules. These rules expect consistent interpretation of line endings. If a message is signed in UTF-8 but delivered in an older encoding like ISO-8859-1 or Windows-1252, the CRLF bytes (0x0D 0x0A) may be read as a single character or split unexpectedly. This changes where the body sections are defined, leading to a different byte stream than the one signed.

Let’s say a tool generates a DKIM signature assuming UTF-8 encoding. But the mail server receives it through a legacy system that applies different decoding. The parser may treat a CRLF as a single byte (0x0D) or misalign the line starts. The resulting body hash is now different — even though the visible message looks the same. This causes DKIM validation to fail silently, often leading to the email being marked as spam or bounced.

How to prevent this issue

Proper encoding handling is non-negotiable for reliable signing. Always ensure that the body is processed in the same encoding context during signing and delivery. If you're using a mailing system, confirm it enforces UTF-8 for both content construction and DKIM hashing.

Use tools that validate the entire delivery path, including header and body integrity across different encodings. MailTester’s inbox placement tester simulates real-world delivery conditions, including encoding variations, to catch issues like this before you deploy campaigns. It verifies not just whether an address is valid, but whether it will reach the inbox cleanly — including DKIM integrity.

For developers and system admins, consulting the official guidelines helps. The DKIM specification (RFC 6376) details the relaxed body canonicalization process, emphasizing the need for consistent interpretation of line endings. Misalignment in non-UTF-8 contexts is a noted edge case that undermines cryptographic integrity.

How can you prevent DKIM failures due to CRLF in non-UTF-8 messages?

Always use UTF-8 encoding for all email content, regardless of legacy systems or old content. Non-UTF-8 charsets like ISO-8859-1 or Windows-1252 require strict CRLF normalization during DKIM relaxed body canonicalization — if your SMTP stack or MTA doesn’t preserve line endings consistently across encoding boundaries, DKIM signatures will fail. Validate the Content-Type header and ensure it’s only set to legacy charsets when necessary, with full handling of CRLF conversion.

Check your email pipeline’s UTF-8 enforcement

  • Set your email generation tool, MTA, and transport layer to explicitly use UTF-8 for all text processing — never assume default behavior.
  • Ensure no legacy middleware or email rendering stack converts UTF-8 to other encodings mid-stream without full, documented CRLF normalization.
  • Use tools like RFC 2822 and RFC 6376 as reference for canonicalization rules — especially where line endings are normalized before signature calculation.
  • Test your DKIM-signed messages with a header and body comparison tool, checking for hidden CRLF changes during transport or content rewriting.

Validate and audit legacy content

  • Review all legacy email content or templates that specify charset=iso-8859-1 or charset=windows-1252 — these require special handling of CRLF in DKIM relaxed body canonicalization.
  • Never assume that a content-type header like Content-Type: text/plain; charset=iso-8859-1 guarantees safe DKIM signing — confirm that the message body’s line endings are preserved exactly as sent.
  • Use MailTester’s email checker to validate whether a given email address can receive UTF-8 content without being rejected or altered during transport, especially if your system sends mixed-encoding messages.
  • For bulk sends, run your list through bulk verification to catch invalid or poorly formatted addresses that might fail during delivery due to encoding mismatches.
The key insight: DKIM relaxed body canonicalization normalizes CRLF to LF, but only after applying the message’s declared charset. If that charset doesn’t align with actual line-endings, the signature will fail silently.

Even if your system sends only UTF-8, a single misencoded message or misconfigured MTA can break DKIM for an entire campaign. Use automated checks and validation — especially when dealing with third-party integrations or legacy systems.

What role does MailTester play in catching these subtle deliverability issues?

You don’t need to guess why a DKIM signature fails. MailTester simulates real inbox placement across major providers and catches misconfigured DKIM setups—especially those caused by non-UTF-8 content with CRLF line endings that break relaxed body canonicalization. It flags encoding flaws that standard checks miss, ensuring your messages pass authentication even under strict validation rules. These subtle issues can sink deliverability, but MailTester surfaces them before you send.

How it works: Real-world testing reveals hidden problems

DKIM relies on consistent message formatting. When a message uses CRLF line endings (common in non-UTF-8 encodings) and isn’t properly normalized during relaxed body canonicalization, the signature no longer matches the received content. This causes rejection or spam filtering, even if the message looks fine in a debugger. MailTester replicates how Yahoo, Gmail, and Outlook process emails—including their interpretation of line endings and encoding—so you detect issues before they damage sender reputation.

What it catches: Beyond basic syntax

Standard email validators often overlook encoding-specific failures. MailTester’s inbox placement tests don’t just check if an address exists—they verify how the entire message is processed. If a message body contains non-UTF-8 characters and uses CRLF line endings, MailTester identifies the risk and returns a clear status: “DKIM failure due to body canonicalization variance.” This goes beyond syntax to expose flaws in how email systems actually interpret content.

Through its real-time verification API, you can test individual messages or automate checks in your workflow. It’s not just about catching typos or invalid addresses—it’s about ensuring the technical foundations of deliverability are sound. You can test a single email before sending via the email checker, or integrate it directly into your sending stack using the verification API. The tool doesn’t make assumptions; it runs actual test deliveries to major providers, so you see exactly how your message performs in production.

These problems are defined in RFC 6376, the standard for DKIM, which specifies how body canonicalization must handle line endings. When the sender’s encoding doesn’t align with the receiving system’s interpretation, the signature fails—even if the email content seems correct. Tools that don’t simulate real delivery often miss this. MailTester doesn’t just validate the address or syntax; it validates the full experience. This means fewer bounces, better inbox placement, and stronger sender reputation.

For deeper validation of entire lists, you can use bulk verification to run hundreds or thousands of checks. It catches not only invalid addresses but also formatting inconsistencies that degrade deliverability. If you’re sending transactional or marketing campaigns, these details matter. Every properly formatted message, every correctly canonicalized body, and every aligned line ending helps secure your deliverability.

Why do some DKIM signs pass on one server but fail on another?

DKIM signatures can pass on one mail server and fail on another because different systems interpret message encoding differently—specifically how CRLF line endings are handled during relaxed body canonicalization. A server using UTF-8 normalizes line endings consistently; one using ISO-8859-1 may not, leading to mismatched canonicalized bodies and signature validation failures even with the same message.

Encoding assumptions matter during signature validation

When a message is signed, DKIM uses relaxed body canonicalization to strip whitespace and normalize line breaks. But if the receiving server assumes a non-UTF-8 encoding—like ISO-8859-1—it might mishandle CRLF sequences during parsing, especially in messages with mixed or corrupted line ending formats.

For example, a message sent with CRLF line endings might be interpreted as a single line (or even as malformed text) on a server expecting Latin-1 encoding, whereas a UTF-8-aware server treats CRLF correctly. This inconsistency means the same message generates two different canonicalized body digests, and the DKIM signature—based on the original digest—fails to verify on the inconsistent server.

Delivery routes amplify the problem

Messages don’t always take the same path to the inbox. They can pass through multiple relays—each with its own default encoding configuration. One relay might use UTF-8, another ISO-8859-1, and each applies its own canonicalization rules.

What you send can be subtly altered in transit. A message with non-standard or mixed CRLF handling is especially vulnerable. The resulting digest mismatch causes DKIM validation to fail on some systems but not others, even if the message content is identical. This unpredictability impacts inbox placement, as many mail providers check DKIM.

This isn’t just theory. The RFC 6376 specification for DKIM, maintained by the IETF, defines how canonicalization should work in practice—but implementation details vary. You can review the standard at tools.ietf.org/html/rfc6376, especially Section 3.4 on relaxed body canonicalization.

To prevent such issues, ensure your email infrastructure consistently uses UTF-8 across all components—headers, body, and tools handling the signing process. You can test your sending setup with real inbox placement tools that simulate how your messages are handled by different receiving filters. Test inbox delivery with MailTester before campaign launches to catch DKIM issues early.

What’s the impact of DKIM failures on sender reputation?

Repeated DKIM signature failures—even from issues like incorrect CRLF line endings in non-UTF-8 messages—signal technical problems to receiving servers. These failures are logged and contribute to a declining sender reputation, especially when clustered across multiple emails. A low sender reputation directly reduces inbox placement and increases the risk of being flagged as spam or outright rejected.

How receiving servers interpret DKIM failures

When a server receives an email with a malformed DKIM signature, it doesn’t just silently discard it. The receiving system records the failure, especially if it repeats across multiple messages from the same sender. This pattern is a red flag that something is wrong with your email infrastructure or sending process.

DKIM relaxed body canonicalization is sensitive to character encoding and line ending inconsistencies. For example, using CR+LF (CRLF) line endings in a message with a non-UTF-8 charset can cause the canonicalized body to differ from the signed version, resulting in a signature mismatch. This is especially common in legacy systems or poorly configured email clients.

Even if the message content is otherwise legitimate, recurring DKIM failures are treated as a sign of poor sending hygiene. Major providers like Google, Microsoft, and Yahoo track these signals as part of their sender reputation scoring, which influences whether your message lands in the inbox or the junk folder.

Reputation degradation is not just a technical issue

Reputation isn’t static. It’s updated frequently based on real-time feedback. A single failed DKIM signature may not hurt, but hundreds of them in a short time—even for non-urgent messages like newsletters or transactional updates—can trigger filters or rate-limiting.

According to industry data from sources like Return Path and the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), consistent technical problems such as DKIM mismatches are strongly correlated with increased spam filtering and lower deliverability rates. The impact isn’t just about bounced messages—it’s about trust.

Let’s be clear: no matter how good your content is, if your emails keep failing DKIM checks due to encoding or line ending issues, your reputation will erode. Fixing these issues early—before they accumulate—is crucial.

Using a service like MailTester’s bulk email verification can help catch malformed addresses and sender setup flaws before they damage your reputation at scale. If you’re sending transactional emails, verify your headers and body formatting with inbox placement testing to ensure your DKIM implementation holds up under real-world conditions. For automated systems, our API can validate addresses and detect potential issues during integration.

How does MailTester’s inbox placement testing help detect these issues in practice?

You send a message with non-UTF-8 content and CRLF line endings—it fails DKIM because relaxed body canonicalization doesn’t handle character encoding quirks correctly. MailTester detects this by sending real test messages to actual inboxes across Gmail, Outlook, and Yahoo, checking DKIM results in real time. If the signature fails due to line ending or encoding issues, it flags the exact failure point during delivery testing.

Here’s how it works in practice

  1. Send a test message through MailTester’s inbox placement tool. The system routes your message to real mailboxes across major providers like Gmail, Outlook, and Yahoo, mimicking your actual sending environment. You’re not testing spam filters in isolation—you’re testing real delivery outcomes.
  2. Monitor delivery logs and authentication status as the message arrives. MailTester captures the full delivery path, including SMTP status codes, headers, and DKIM validation responses. This is where it catches failures caused by body canonicalization mismatches during DKIM alignment.
  3. Identify DKIM failures caused by CRLF line endings in non-UTF-8 messages. When a message uses CRLF line endings but is sent with a non-UTF-8 content charset (like ISO-8859-1), the relaxed body canonicalization in DKIM can produce different results than expected. MailTester logs this divergence and surfaces it during the report.
  4. Get the exact failure reason with diagnostic clarity. You don’t just see “DKIM failed”—you see why. The report shows whether the issue stemmed from line ending handling, encoding misalignment, or body normalization differences, helping you pinpoint the root cause.
  5. Fix and retest with confidence. Once you correct the message body encoding or standardize line endings to LF (as specified in RFC 5322), you can rerun the inbox placement test. The system validates the corrected version and confirms whether the DKIM issue is resolved.

Why this matters in real-world sending

DKIM relaxed body canonicalization is defined in RFC 6376 and assumes consistent line ending handling and character encoding. When messages mix CRLF with non-UTF-8 encodings, the body digest calculation diverges between sender and receiver—even if the content looks identical. This is a common failure mode in legacy systems or poorly configured senders.

MailTester’s inbox placement testing catches this because it doesn’t simulate the mail stream—it runs it. By sending actual messages to real mailboxes and checking the raw delivery logs, it exposes authentication issues that synthetic testing might miss. You’re not guessing whether DKIM passed—your system tells you.

If you're sending bulk emails and want to verify your messages before rollout, use the inbox placement tester to validate full delivery integrity, including DKIM alignment under real world conditions.

Prevention is better than detection — what should you do now?

UTF-8 is the only encoding that guarantees consistent and correct DKIM relaxed body canonicalization. Any non-UTF-8 message risks breakage during signature verification if CRLF line endings are not handled uniformly.

Review all templates, automation workflows, and custom code that generates email content. Ensure that all email systems, from rendering to SMTP transmission, use UTF-8 as the default encoding and normalize line endings to CRLF before signing.

Proactive validation steps

  • Scan all outgoing email templates for explicit encoding declarations or fallbacks that aren’t UTF-8.
  • Check API or SMTP clients for hardcoded encoding assumptions or improper handling of newline sequences.
  • Run deliverability tests using real-time tools to catch encoding-related signature failures before they reach inboxes.

Sources

  • DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
  • After Gmail began requiring authentication for large senders, the number of unauthenticated messages Gmail users received plummeted by 75%. — Google (The Keyword blog) (2023)

Keep reading

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

Frequently asked questions

Does DKIM fail only when using CRLF in messages?

No. CRLF itself isn't the root issue — it's the interaction between CRLF, legacy encodings, and inconsistent line ending handling during canonicalization that breaks DKIM.

Can UTF-8 messages still have DKIM issues with CRLF?

Yes, but reliably. UTF-8 ensures that CRLF is always interpreted as two bytes, making canonicalization consistent across systems.

Is it safe to use Windows-1252 to send emails?

Only if all parts of the mail pipeline explicitly handle the encoding correctly. It increases the risk of DKIM failure due to CRLF misinterpretation.

How do I know if my DKIM signature is failing due to encoding?

Check the DKIM-Signature header for validation results. Use inbox placement testing to see if emails from the same sender fail DKIM inconsistently.

What does 'relaxed' body canonicalization mean in practice?

It allows minor formatting changes like line endings and spacing to be ignored during signature validation, as long as the body content remains unchanged.

Why does my DKIM work in testing but fail in production?

Production environments may use different mail servers or parsing logic than test systems. Encoding mismatches or CRLF normalization bugs can surface only in production.

Can a message pass SPF but fail DKIM?

Yes. SPF checks sender IP alignment. DKIM checks message integrity and signature validation. One can pass while the other fails — especially due to encoding issues.

Is there a way to test DKIM failures before sending?

Yes. Use tools like MailTester’s inbox placement tests, which simulate real delivery and report authentication results and formatting anomalies.

Does CRLF affect other email headers or only the body?

CRLF can affect headers too, but DKIM’s header canonicalization normalizes line endings more robustly than body canonicalization. The body is more vulnerable in non-UTF-8 contexts.

What encoding should I use for all email content?

Always use UTF-8. It ensures consistent interpretation of line endings, special characters, and canonicalization across all systems.