DKIM Body Canonicalization Errors

Why does DKIM fail when sending HTML and plain text emails with different encodings?

You send a multilingual campaign with HTML and plain text parts. The preview looks correct. The sender reputation is solid. Yet the email fails DKIM validation—no warning, no error code, just a silent drop into the spam folder. Why? The most common culprit isn't a broken key or misconfigured DNS. It’s a mismatch in character encoding between the two parts. DKIM signs the email body using a canonicalization method that normalizes whitespace and line breaks. But when the HTML part uses UTF-8 and the plain text part uses ISO-8859-1 (or another encoding), the same content produces different byte sequences. The receiving server’s DKIM verifier sees this mismatch and rejects the signature—even if the human-readable content looks identical. It’s like sending two copies of the same letter: one in English, one in French, and claiming they’re the same. This issue is especially common in global campaigns where content is auto-generated across languages or when legacy templates don’t enforce consistent encoding. It’s one of the stealthiest reasons authenticated emails fail—often invisible until you see high bounce rates or low inbox placement.

Key takeaways

Different character encodings in HTML and plain text parts produce divergent byte streams, causing DKIM signature mismatches even with identical content.
DKIM canonicalization normalizes line breaks and whitespace, but it cannot reconcile differences arising from encoding mismatches during verification.
Ensuring both email parts use the same encoding—preferably UTF-8—prevents silent DKIM failures that otherwise appear as delivery or spam filter issues.

What is DKIM body canonicalization, and why does it matter?

DKIM body canonicalization normalizes an email’s body before signing, so the receiving server can verify it wasn’t tampered with. If the HTML and plain text parts use different character encodings—like UTF-8 for HTML and ISO-8859-1 for plain text—the relaxed canonicalization method can’t reconcile the differences, causing signature validation to fail. This breaks deliverability even if the message content is correct.

How DKIM canonicalization works

When DKIM signs an email, it applies canonicalization to the body to standardize formatting. Most mail servers use relaxed canonicalization, which treats line endings uniformly (converting them to CRLF) and ignores insignificant whitespace, like extra spaces or tabs. But it does not touch character encoding—so if your HTML part is UTF-8 and your plain text part is Latin-1, the server sees them as different, even though they’re meant to be equivalent.

This mismatch becomes critical during validation. The receiving server re-canonicalizes the body using the same rules, then compares it to the signed version. If the body content differs—even slightly due to encoding differences—the signature fails. You might see errors like "body canonicalization error" or "DKIM verification failed," even if the email was sent correctly.

Why encoding differences break DKIM

Let’s say you send a multipart email: one part in HTML (UTF-8), the other in plain text (ISO-8859-1). The relaxed canonicalization standard (defined in RFC 6376) allows some flexibility, but it doesn’t normalize character encoding. So, when the receiver processes the body, it sees two distinct content streams. The digital signature, based on the original, can't match the re-canonicalized version.

Even small discrepancies—like a single character encoded differently—can invalidate the signature. This is why sending tools must ensure that both parts of a multipart message use the same encoding. Tools that don’t handle this automatically can trigger delivery issues, especially with aggressive filters or DMARC enforcement.

Use a real-time verification API before sending at scale to catch such issues early. With MailTester’s email checker, you can validate individual addresses and test message structure, including encoding alignment, before sending to your list. For bulk sends, use bulk verification to find problematic addresses and prevent delivery failures due to signing issues.

How does encoding mismatch cause delivery failures in practice?

You send an email with HTML content in UTF-8 and plain text in ISO-8859-1. The DKIM signing server canonicalizes both parts using UTF-8, but the receiving server re-encodes the plain text part from ISO-8859-1 to UTF-8 during validation. This mismatch changes the byte stream, so the DKIM digest no longer matches. The email appears unsigned, gets rejected by strict filters, or triggers spam detection.

Step-by-step: how a mismatch breaks DKIM

Send HTML part in UTF-8, plain text in ISO-8859-1
You configure your email client or ESP to send the plain text version with ISO-8859-1 encoding (common in older systems), while the HTML part uses UTF-8 for emoji and non-Latin characters. This looks harmless until DKIM validation.
Signing server canonicalizes both parts in UTF-8
During DKIM signing, the server normalizes text, removing whitespace and folding lines, using UTF-8 for both parts regardless of original encoding. The digest is computed on this unified UTF-8 byte stream.
Receiving server parses and re-encodes the plain text part
The receiving server sees the plain text as ISO-8859-1. It re-decodes that part to UTF-8 for internal processing. This step changes the byte sequence, especially for characters outside the ASCII range (like accented letters or symbols).
DKIM validation computes a different digest
When validating, the receiving server recomputes the digest using its own view of the plaintext—UTF-8 converted from ISO-8859-1. The resulting digest differs from the one in the DKIM signature.
Validation fails: no signature match
Because the digests don’t match, DKIM validation fails. The email is treated as unsigned, especially on systems that enforce strict DKIM policies. Some providers will drop the email entirely.

Why this matters in real-world delivery

Even small encoding differences cause irreversible validation failure. This isn't just theory—RFC 6376 (the DKIM standard) explicitly defines canonicalization as a core part of the signature process. If the received body doesn’t match the canonicalized version used at signing, the email is rejected, often without notification.

The 5 steps described in “Step-by-step: how a mismatch breaks DKIM”, in order.

Major providers like Gmail and Outlook use DKIM fail rates as a signal in their spam scoring. A consistent failure can degrade sender reputation. You might send 100,000 emails, only 90% land in inbox—even if content is clean, misencoded plain text can be the hidden culprit.

MailTester’s email checker can help catch invalid or malformed addresses early, reducing the risk of sending to addresses that may trigger edge cases in delivery systems. For teams sending at scale, bulk verification ensures your list is clean before you even hit send.

How to detect DKIM body canonicalization errors in your email infrastructure?

You can detect DKIM body canonicalization errors by checking the DKIM-Signature header for inconsistent b= values across deliveries, especially when emails contain both HTML and plain text parts with different character encodings. If you see repeated dkim=permerror or dkim=fail results across multiple recipients and domains, it’s likely a canonicalization issue caused by encoding mismatches in the body. Use tools like MxToolbox or MailTester’s inbox-placement test to validate authenticity at scale and isolate encoding-related failures.

Check the DKIM-Signature header for body inconsistencies

Look for the DKIM-Signature field in the raw email header after delivery.
Compare the value of the b= parameter across multiple sends—especially when content varies between HTML and plain text parts.
If the b= value changes unexpectedly despite unchanged content, it’s a sign that body canonicalization failed during signing.
Pay close attention when using UTF-8 in one part and ISO-8859-1 in another—this mismatch commonly breaks DKIM validation.

Use automated tools to test at scale

Run an inbox-placement test using MailTester’s inbox-placement tester to validate how your emails are handled across real inboxes and spam filters.
Review the DKIM validation results in the test output—look for persistent dkim=permerror or dkim=fail entries across multiple domains.
Use MxToolbox’s SuperTool to trace headers and inspect DKIM results across different mail providers.
Check whether the failure occurs only with certain recipients or across a broad range—widespread failure suggests a systemic issue, not a single bounce.
If you're managing large email lists, run bulk validation with MailTester’s bulk verification to catch encoding-related issues before sending.

DKIM canonicalization must preserve the logical content of the email body, regardless of encoding. A mismatch in how whitespace or line breaks are normalized can cause signature verification to fail—even with identical content.

Encoding inconsistencies typically arise when HTML and plain text parts use different character sets without proper normalization during signing. This can occur if your email engine doesn’t apply consistent body canonicalization prior to signing. The DKIM specification requires that the body be processed with strict rules for line endings and whitespace, even when the content is encoded differently. Ignoring this leads to failed authentication, even if the message is otherwise valid.

How do you fix DKIM body canonicalization errors with mixed encodings?

If your emails include both HTML and plain text parts with different character encodings, DKIM verification may fail because the canonicalization process expects consistent byte-level output. The fix is to ensure both parts use the same encoding—preferably UTF-8—before signing. This prevents differences in line endings, whitespace, or character rendering that break the digital signature check.

Use a consistent encoding across all email content

Set the character encoding to UTF-8 for both the HTML and plain text parts of your email.
Configure your email template engine to apply UTF-8 globally, not per-part.
Ensure that mail merge fields, dynamic content, and variable substitutions preserve UTF-8 throughout the rendering pipeline.

Validate the final MIME body before DKIM signing

Before applying DKIM, simulate the final output across delivery channels and confirm the byte stream is identical.
Use a debug tool to inspect the raw MIME body and verify that all line breaks, spacing, and encoding artifacts match exactly.
Many email platforms apply their own normalization—test your output with real-world deliverability tools like RFC 6376’s canonicalization rules to ensure compliance.
Run your message through a real inbox placement test to observe how actual servers handle your signed email.

Let’s be clear: a single misencoded part can invalidate your DKIM signature—even if the rest of the message is correct. This is why consistent encoding isn’t a suggestion. It’s a requirement for reliable authentication. The DKIM specification explicitly defines body canonicalization based on byte-level consistency. When encodings differ, the canonicalized body diverges. That’s why you must validate not just the source, but the final rendered output.

It’s easy to overlook encoding mismatches when working with legacy systems or third-party templates. A common issue is when a plain text part, auto-generated from an HTML version, inherits ISO-8859-1 instead of UTF-8. You can catch these silently failing issues by testing every combination of content, template, and merge data.

What tools can help you detect and audit encoding mismatches in email content?

You can detect and audit encoding mismatches in emails with HTML and plain text parts using different character encodings by testing the full message workflow. MailTester’s inbox-placement tester sends real emails through major providers and returns a full header analysis, including DKIM, SPF, and DMARC results, so you can spot how encoding inconsistencies impact delivery and signature validation. This real-world simulation shows where problems like DKIM body canonicalization errors occur, even when your messages look correct in isolation.

Test full delivery flows with real headers

DKIM body canonicalization errors often appear only when an email is sent and processed by a real server. They happen because the message body is normalized differently during signing and verification—especially when you use UTF-8 in HTML and ISO-8859-1 (Latin-1) in plain text. The difference in how line breaks, whitespace, and encoding are parsed can break the DKIM signature, even if your content looks fine in a test client.

MailTester’s inbox-placement test sends your email through providers like Gmail, Outlook, and Yahoo, then returns the full raw headers. You get to see how the receiving server interpreted the body, including any canonicalization adjustments that may have invalidated the DKIM signature. This isn’t simulation—this is real, authenticated delivery with full transparency.

Use the AI assistant to decode and fix header issues

When you get a DKIM failure, the raw headers can be overwhelming. That’s where MailTester’s in-app AI assistant comes in. Paste the full header output, and it will identify the exact reason for the failure—whether it’s an encoding mismatch, a missing DKIM key, or a mismatched body hash. It doesn't just tell you there’s an error—it tells you why. For example, it can flag that the plain-text part used different line ending normalization than the HTML part, which broke the canonicalization process.

While the RFC 6376 standard defines how DKIM body canonicalization should work, real-world implementations vary. A mismatch in how line endings are stripped or how characters are interpreted can silently cause failures. Tools like MxToolbox or Spamhaus provide reputation and blocklist checks, but they don't validate content encoding during signature verification. Only a system that sends and analyzes actual messages—like MailTester’s inbox tester—can reveal this.

For ongoing verification, integrate MailTester’s real-time API into your send workflow to catch encoding issues before your campaign launches. Test each address in real time, and ensure your template output is consistent across both content parts. This keeps your sender reputation intact and your inbox placement high—especially when sending to global audiences with mixed encoding needs.

Does using UTF-8 for both parts solve all DKIM canonicalization issues?

Using UTF-8 for both HTML and plain text parts significantly reduces the risk of DKIM body canonicalization errors by eliminating encoding mismatches. But it doesn’t guarantee success—DKIM still requires byte-level consistency, so issues like inconsistent line breaks or extra whitespace can break the signature even when encodings align. You must treat the entire message body as a single, uniform stream of bytes, not just text.

Why UTF-8 helps, but isn’t the full fix

When the HTML and plain text parts use different character encodings—say, UTF-8 for one and ISO-8859-1 for the other—DKIM’s canonicalization process sees different byte sequences, even if the text appears identical. This mismatch invalidates the signature. By standardizing on UTF-8 for both, you remove that source of failure. This is a best practice recommended in RFC 6376, the foundational standard for DKIM.

But encoding uniformity isn’t enough. DKIM body canonicalization specifies that line breaks must be normalized to CRLF (Carriage Return + Line Feed), and whitespace beyond what’s required in the message structure must be trimmed. Even with UTF-8, inconsistent line endings—like mixing CR-only, LF-only, or mixed—can cause the canonicalized body to diverge from the signed version.

Byte-level consistency is non-negotiable

Let’s be clear: DKIM signs the body as a byte stream, not a rendered message. A single extra space, a missing newline, or an unintended character inserted by a poorly configured email client can break the signature—even if both parts are UTF-8. That’s why some developers assume UTF-8 is a silver bullet, only to find emails still failing DKIM checks.

Proper validation requires end-to-end consistency. Tools like inbox placement testing can catch delivery issues before they affect your reputation, including DKIM failures that result from subtle body differences. If your automation generates emails via templates, ensure the final output is canonicalized identically to how the server processes it.

Even with the right encoding, it’s easy to introduce inconsistencies in preprocessing steps—HTML minification, text conversion, or header injection. These all alter the byte stream. Use a tool like bulk email verification to test messages in real-world conditions, especially before sending to large audiences.

How to prevent encoding issues when integrating with Mailchimp, Klaviyo, or SendGrid?

Use UTF-8 consistently across all email components—HTML and plain text parts, templates, and content—unless you have a specific, documented reason to do otherwise. Most modern email platforms default to UTF-8, and switching encodings mid-template creates a high risk of DKIM body canonicalization errors, especially when headers or body content differ between versions. Prevent issues early by validating email addresses and testing deliverability before sending.

Keep encoding consistent in templates

Ensure your email template editor (in Mailchimp, Klaviyo, or SendGrid) uses UTF-8—this is the default and should remain unchanged.
Avoid manually setting character encodings like ISO-8859-1 or Windows-1252 in any part of the message, especially if one section uses UTF-8 and another doesn’t.
Test both HTML and plain text versions of your email using the same encoding. Mismatched encodings break DKIM’s canonicalization rules, which require predictable, consistent body parsing.
Review how your ESP handles content encoding during delivery. Some systems reprocess or normalize content, which can introduce mismatches if the original content wasn’t properly encoded.

Preempt delivery failures with verification and testing

Use the MailTester bulk verification service to check your full list before sending. This catches invalid addresses, catch-all domains, and issues like encoding mismatches that could derail deliveries.
Run inbox-placement tests via MailTester’s inbox tester to simulate how your email lands across providers. This identifies DKIM or content canonicalization problems before you send to real users.
Verify each transactional or campaign email via the MailTester email verification API to catch encoding-related delivery risks in real time, especially when scaling.
Check your DKIM and SPF settings using tools like MXToolbox or refer to the canonical DKIM specification (RFC 6376) to ensure proper alignment and signature generation.

DKIM body canonicalization requires that the message body be processed in a predictable way—any variation in whitespace, encoding, or line breaks can invalidate the signature. Consistency is not optional.

Why is DKIM failure often mistaken for spam filter rejection?

DKIM failures are frequently mistaken for spam filter rejections because both result in emails landing in junk folders or being blocked—but the cause is technical, not content-based. A DKIM signature mismatch means the receiving server can’t verify the email's origin, even if the message is perfectly clean. This cryptographic failure triggers filtering, but it’s not because of spammy words, poor sender reputation, or message content.

DKIM isn't about content—it's about integrity

When a DKIM signature fails, it’s not because the email said something wrong. It’s because the body of the message received didn’t match the body the sender signed. Even tiny changes—like whitespace, line breaks, or character encoding differences—can break the signature. This is especially common when emails contain both HTML and plain text parts using different encodings, such as UTF-8 in the HTML section and ISO-8859-1 in the plain text part.

These mismatches often happen during email transport, especially when a message is reformatted or transcoded by gateways, proxies, or older mail servers. The receiving server checks the DKIM signature against the actual body it received. If the body differs from what was signed—due to canonicalization errors like those seen in mixed-encoding emails—the verification fails, regardless of the content’s legitimacy.

Spam filters look at many signals: sender reputation, engagement rates, list hygiene, and message content. But DKIM failure is a separate, lower-level check. It doesn’t affect the spam score directly—it just means the message wasn’t authenticated. Many receivers treat unauthenticated messages as higher risk and filter them accordingly, which can look like a spam rejection, even when the email is clean.

What actually breaks DKIM: canonicalization errors

Canonicalization is the process of normalizing the message body before signing. Different systems apply different rules—some normalize line endings, others ignore whitespace. When the signing and verification processes don’t agree on how to interpret these changes, the signature fails. This is a common issue with emails that have both HTML and plain text parts using different character encodings.

For example, an HTML part encoded in UTF-8 might have a UTF-8 character (like é) that appears differently when the plain text part is interpreted in ISO-8859-1. If the signing process doesn’t account for this, the signed body and the received body will diverge, breaking DKIM. The email still sends, but the signature won’t verify.

As outlined in RFC 6376, the DKIM standard specifies exact rules for body canonicalization. When systems deviate—either in signing or validating—the signature fails. You can't fix this with better content; you need to ensure consistent handling of encoding, line breaks, and whitespace at every stage of sending. Tools like MailTester’s email checker can test whether your messages are technically sound before sending, including catching encoding-related issues that could lead to DKIM failure.

How does MailTester help prevent DKIM body canonicalization errors?

You can catch DKIM body canonicalization errors early by testing your email templates with MailTester’s real-time verification API and inbox-placement tests. These tools check how your message will be delivered across actual provider environments, including DKIM signature validation, before you send. This helps identify encoding mismatches between HTML and plain text parts that break DKIM alignment.

Testing at the delivery layer

DKIM body canonicalization is sensitive to character encoding differences—especially when your HTML part uses UTF-8 and the plain text part uses ISO-8859-1. Even small mismatches can cause the signature to fail during delivery. MailTester’s inbox-placement test sends your email to real inboxes across Gmail, Outlook, Yahoo, and others, returning full headers with DKIM status. You can then see if the signature is valid or broken in real-world conditions.

MailTester’s real-time verification API doesn’t just check syntax—it validates content under actual delivery rules. When you send a message with mixed encoding, the API simulates the canonicalization process that ISPs apply during DKIM verification. This reveals issues that internal testing or basic syntax checks would miss. Let’s say your template includes a plain text fallback with unescaped HTML entities; MailTester flags that before it becomes a delivery failure.

Accuracy and early detection

With 98.9% verification accuracy, MailTester helps identify flawed templates before they hit your audience. It catches not just formatting issues, but the root causes of failed DKIM signatures—like inconsistent line breaks or encoding mismatches between parts. This reduces bounce rates and improves inbox placement over time.

For teams using tools like SendGrid, HubSpot, or Klaviyo, MailTester integrates seamlessly via its API or bulk verification tool. You can check entire lists or individual addresses, and the service highlights problematic emails with clear reasons—like “DKIM body canonicalization mismatch.” This transparency lets you fix templates, not guess. For example, if an email fails due to encoding, the header shows the exact point of mismatch.

DKIM alignment rules are defined in RFC 6376, and even minor deviations can result in signature failure. You can read more about the mechanics of canonicalization in the official specification at RFC 6376. Tools like MailTester help you stay compliant without requiring deep protocol expertise.

Use the inbox-placement test to run live delivery checks on your campaign. Or integrate the real-time verification API into your send workflow to catch errors before each campaign goes out. The goal isn’t perfection—it’s consistency. And consistent delivery means better results.

The bottom line: what every email deliverability team should do now

DKIM body canonicalization errors often stem from mixing character encodings in multipart emails. The fix is simple: use UTF-8 for both HTML and plain text parts. This eliminates the risk of signature mismatches during verification.

Immediate steps to ensure reliable delivery

Review all active email templates. Confirm both HTML and text parts use UTF-8 encoding consistently.
Run inbox-placement tests on high-volume campaigns via MailTester to detect signing failures before they impact sender reputation.
Integrate the MailTester real-time API during development and deployment to catch encoding issues early in the workflow.

Even small deviations in encoding can trigger DKIM failures, leading to blocked or flagged messages. Proactive validation is the only reliable defense.

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)
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)

Keep reading

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

Frequently asked questions

Can DKIM fail even if the email reaches the inbox?

Yes. A DKIM failure doesn’t always block delivery. The email may arrive, but be flagged as unauthenticated, reducing trust and increasing risk of spam filtering.

Is UTF-8 the only safe encoding for email content?

UTF-8 is the standard and recommended encoding for modern email. It supports all languages and avoids most interoperability issues, including DKIM canonicalization breakdowns.

Do all email providers validate DKIM signatures the same way?

Most do, but variations exist. Some enforce strict canonicalization; others tolerate minor discrepancies. Still, consistent encoding is required to ensure broad compatibility.

How can I check if my email template has mixed encoding?

Inspect the raw email headers and content. Look at the 'Content-Type' field in both parts. Ensure both have charset=UTF-8. Use an email testing tool like MailTester to simulate and analyze delivery.

Does DKIM body canonicalization affect SPF or DMARC?

No. DKIM body canonicalization only affects DKIM. SPF validates the sending server; DMARC governs policy enforcement across SPF and DKIM. But DKIM failure can weaken DMARC alignment.

Can a role account cause DKIM body canonicalization errors?

No. Role addresses (e.g. admin@, support@) do not interfere with canonicalization. The issue arises from email content encoding, not the recipient address type.

Is it safe to use ISO-8859-1 in plain text emails?

It’s outdated and limits language support. While it won’t automatically break DKIM, mixing it with UTF-8 HTML increases the risk of canonicalization errors. Avoid it in favor of UTF-8.

How often should I test for DKIM canonicalization errors?

Test every time you update an email template, integrate with a new platform, or add dynamic content. Use MailTester’s API for automated checks in development pipelines.

What’s the difference between DKIM body and header canonicalization?

Body canonicalization normalizes the message content, removing extraneous whitespace and fixing line breaks. Header canonicalization processes the message headers. Both must be consistent for the signature to pass.

Can disposable email addresses cause DKIM failures?

No. Disposable domains do not affect DKIM signatures. They may be flagged for other reasons, such as low reputation, but not due to encoding mismatch in signed content.