Why Does DKIM Body Canonicalization Fail with Multipart/Alternative Emails?

You send a clean, well-formatted email with both plain text and HTML versions. The DKIM signature looks valid on paper—but inbox providers reject it anyway. Why?

The issue lies in how DKIM canonicalizes the message body. When multipart/alternative content isn’t handled consistently across both parts, even tiny differences in line breaks or whitespace break the signature. The verifier expects a specific, normalized body. If it doesn’t match, DKIM fails—regardless of whether your email content is actually correct.

Key takeaways

  • DKIM body canonicalization requires identical line endings and whitespace across both HTML and plain text parts of multipart/alternative emails.
  • Even small encoding differences, like CRLF vs LF or extra spaces before a newline, can invalidate a DKIM signature.
  • Failure to canonicalize the body correctly results in DKIM validation failure, which harms sender reputation and increases inbox placement risk.

What Is Body Canonicalization in DKIM, and Why It Matters

DKIM body canonicalization standardizes the content of an email before signing, so receiving servers can verify the signature using the exact same body format. This prevents minor formatting differences—like whitespace or line breaks—from breaking the signature. Without proper canonicalization, even valid emails fail authentication, hurting deliverability and sender reputation.

How Canonicalization Works in Practice

DKIM defines two methods: simple (s) and relaxed (r). Relaxed is preferred for human-readable content because it normalizes whitespace and line endings in a way that mimics real user reading. For instance, multiple spaces become one, and line breaks are flattened. This makes email verification more robust across different clients and MTAs.

Why Multipart/Alternative Emails Often Fail

In multipart/alternative messages—with both text/plain and text/html parts—each part must be canonicalized independently. If one part is processed with relaxed canonicalization but the other isn’t, or if line endings are inconsistently handled, the signed body no longer matches the one received. Even a single mismatch fails the DKIM verification.

Let’s say you send a message with a clean HTML body and a slightly reformatted plain text version. If your signing process uses relaxed canonicalization on the HTML part but simple on the text part, the receiving server checks each part with the same algorithm and finds mismatched content. The result? A DKIM signature failure—even if the email content is correct.

This issue is common in automated systems where templates are processed differently across platforms. The DKIM standard (RFC 6376) explicitly requires the body to be normalized before signing, so consistency is mandatory. Even small changes in how you handle header and body whitespace during signing can make your email appear altered to the verifier.

Tools like MailTester's email checker detect these issues before you send by simulating how receiving servers parse and verify your message. It checks not just syntax, but how canonicalization affects signature validation—especially in complex multipart messages. You’ll catch body mismatches early, before they harm your inbox placement or reputation.

Fixing body canonicalization means ensuring both your signing algorithm and content generation pipeline apply relaxed rules consistently across all parts. If you use templates, validate their output with real email verification tools. Automated tools are better than guesswork—especially when you're sending at scale.

Common Triggers of DKIM Body Canonicalization Failures

You're seeing DKIM body canonicalization failures with multipart/alternative emails because small inconsistencies in line endings, whitespace, or content rendering break the signed body's expected form. Even if your headers are correct, the body must match exactly what was signed—any deviation between the signed version and the delivered one invalidates the signature. This is especially common when HTML and plain text parts are processed differently across platforms, or when dynamic content alters spacing or line breaks. Let’s look at the real culprits.

Line Ending Inconsistencies

  • Mixing \r\n and \n within the same part (e.g., one line ending in CRLF, another in LF) breaks canonicalization.
  • Some email processors normalize line endings during delivery, but DKIM expects the exact original format used at signing.
  • Use a consistent line ending standard (preferably CRLF on all platforms) before generating the signed body.

Whitespace and HTML Rendering Side Effects

  • Whitespace inside <pre> blocks or between HTML tags may be stripped or normalized during rendering, even if preserved in the source.
  • Dynamic content systems (like templating engines) often collapse redundant spaces or newlines, altering the body’s byte-for-byte form.
  • Test your template output with a tool that checks the final body structure—don’t assume what you see in code matches what arrives in inbox.

Reformatting by ESPs or Email Clients

  • Some ESPs (Email Service Providers) reformat HTML or rewrap long lines during delivery, which breaks DKIM’s exact match requirement.
  • Mobile clients and certain filters may also adjust whitespace or line breaks in ways that invalidate the signature.
  • For example, Gmail may re-wrap text or adjust paragraph spacing, even if the original message was sent with minimal formatting.
The canonical body in DKIM must match the one signed, exactly as it was at send time. No changes—no rewrapping, no normalization, no whitespace cleanup. Even one byte off invalidates the signature.

When you’re debugging these issues, it’s not enough to validate headers or DNS records. You must inspect the final delivered message body and compare it to the one signed. Use tools that simulate delivery and show the exact body sent—tools like inbox placement testing help confirm whether your DKIM signature holds up in real-world inboxes.

How to Verify DKIM Failures in Multipart/Alternative Emails

You can verify DKIM body canonicalization failures in multipart/alternative emails by checking the DKIM-Signature header for the c= parameter, comparing the canonicalized body on your server with what the receiving server processes, and testing individual messages using a real-time verification tool like MailTester. This reveals inconsistencies in whitespace, line length, or encoding between the HTML and plain-text parts.

  1. Test individual messages using MailTester’s real-time verification API. Send a sample message that includes both HTML and plain-text parts through the MailTester API. This checks whether the DKIM signature validates against actual receiving server behavior, including canonicalization rules, without relying on assumptions.
  2. Inspect the DKIM-Signature header for the c= parameter. The value of c= indicates the canonicalization method applied—typically relaxed/simple. If you're using relaxed body canonicalization (common), ensure your email client and server process line breaks and whitespace consistently across both text and HTML parts.
  3. Compare the canonicalized body on your server with what the receiver processes. The receiving server re-applies body canonicalization based on the c= value. If your server prepends newlines, alters CRLF to LF, or adds extra spacing in one part (like plain-text), the signature will fail even if the content is logically correct. This mismatch is common in multipart/alternative emails.
  4. Check for differences in whitespace, line length, and character encoding between parts. In multipart/alternative emails, each part must stand independently. If the plain-text version uses 100-character lines but the HTML version wraps at 78, or if there are extra spaces before a line in the plain-text version, the relaxed canonicalization will catch this. Use tools like RFC 6376 to understand how body canonicalization works.
  5. Validate all parts with a full header and body dump. Use a tool like MXToolbox or MailTester’s inbox placement test to receive full message headers and body output from a real email client. Compare the exact sequence of characters before and after canonicalization.

Why Multipart/Alternative Email Structure Triggers DKIM Failures

Different mail clients and servers apply body canonicalization rules slightly differently. The HTML part may be wrapped after 60 characters, while the plain-text version uses 78. If your server doesn’t normalize this consistently, the canonicalized body will differ from the receiver's version, breaking the DKIM signature. Even small changes—like adding a space before a bullet point in plain text—can cause failure.

Best Practices to Prevent Body Canonicalization Failures

You can prevent DKIM body canonicalization failures in multipart/alternative emails by using relaxed canonicalization for both headers and body, standardizing line endings to CRLF across all parts, normalizing whitespace in HTML before signing, signing before dynamic rendering, and validating the final signed message with a trusted tool like MxToolbox or MailTester’s inbox placement test.

Configure DKIM with Relaxed Canonicalization

  • Set your DKIM signature to use c=relaxed/relaxed for both header and body canonicalization. This aligns with industry standards and reduces sensitivity to minor formatting changes during transit.
  • Relaxed canonicalization ignores insignificant differences like line breaks and extra whitespace—critical when sending emails with dynamic content or varying multipart boundaries.

Standardize and Preprocess Content Before Signing

  • Ensure all parts of your multipart/alternative message use CRLF line endings (carriage return + line feed), not just LF. This is required by the DKIM specification (RFC 6376) and commonly overlooked.
  • Preprocess HTML content to remove or normalize excess whitespace, nested span tags, or auto-generated class attributes before signing. Even minor changes can break DKIM validation.
  • Never modify the content after DKIM signing—this includes dynamic rendering, template expansion, or server-side transformations. Sign first, deliver second.
  • Validate your final signed message using a trusted DKIM debugger. Tools like MxToolbox’s DKIM analyzer or MailTester’s inbox placement test check real-world delivery conditions and can reveal body canonicalization issues before they hit your inbox.

How MailTester Helps Catch DKIM Body Canonicalization Issues

You can catch DKIM body canonicalization failures in multipart/alternative emails before they hurt deliverability by testing your messages in real-world conditions. MailTester’s inbox-placement tests simulate actual recipient servers and validate DKIM signatures using fully RFC-compliant checks, including both header and body canonicalization. If your email’s body changes during delivery due to formatting or encoding mismatches, MailTester detects the signature failure and flags it as “failed” due to body mismatch — so you know exactly where to fix it.

Real-World Validation with RFC-Compliant Checks

DKIM signing relies on consistent body and header canonicalization. When a message contains both plain text and HTML (multipart/alternative), even small differences in whitespace or line endings can invalidate the signature. MailTester doesn’t just check if DKIM exists — it validates the entire signing process under realistic delivery rules. The system applies the same canonicalization algorithms that real mail servers use, including RFC 6376’s defined body canonicalization, which processes each part independently and ensures alignment.

Immediate Feedback via Real-Time API

When you use the MailTester verification API, you don’t have to wait for bounces. For every email, the API returns detailed signature status — including a clear “failed” if there’s a body mismatch. You get this feedback in real time, before sending. This means you’re not guessing why a message was rejected; you see the specific canonicalization error and can adjust your email template or rendering logic accordingly.

With 98.9% accuracy, MailTester identifies invalid or misconfigured DKIM signatures early. This isn’t about catching every edge case, but about catching the ones that matter — the ones that trigger rejection by Gmail, Yahoo, or enterprise gateways. Whether you're sending transactional copies or marketing campaigns, knowing your DKIM body canonicalization is sound reduces risk and protects sender reputation.

Let’s be clear: DKIM isn’t about encryption. It’s about authenticity. And that authenticity only holds if the message content remains unchanged during transit. MailTester helps you verify that, end to end.

Real-World Example: Fixing a Failed DKIM Signature

You can fix a DKIM body canonicalization failure in multipart/alternative emails by ensuring consistent line endings—specifically, using \r\n (CRLF) throughout both the plain text and HTML parts. Inconsistent line endings cause the DKIM signature to fail even if the content is otherwise valid. This is a common issue when email clients or tools normalize line breaks differently.

The Problem: Mixed Line Endings Break DKIM

Imagine you're sending a campaign via an ESP. The plain text part uses \n (LF), while the HTML part uses \r\n (CRLF). Even though both render correctly in most clients, DKIM's relaxed body canonicalization expects uniform line endings. The signing tool applies canonicalization using the first part’s format, but the second part doesn’t follow it—so the final body hash doesn’t match the signed digest.

How MailTester Reveals the Issue

When you test the email with MailTester’s inbox placement tool, it flags the DKIM signature as failed and identifies the root cause: body canonicalization mismatch. Unlike many tools that only report "DKIM failed" without context, MailTester shows you exactly which part of the email deviated from expected formatting. This saves hours of debugging.

  1. Inspect the raw email headers and body using a tool like RFC 6376 as reference to confirm how canonicalization should be applied.
  2. Ensure all parts use the same line ending format—preferably \r\n (CRLF)—in both plain text and HTML sections. This aligns with how most SMTP systems expect them to be formatted.
  3. Re-sign the email after standardization with a DKIM signer that respects relaxed body canonicalization. Make sure the signing process uses the same line ending behavior as the receiver’s verification step.
  4. Re-test using MailTester’s inbox placement service to confirm the DKIM signature now passes. This verifies the fix works end-to-end across major email providers.

After standardizing both parts to use \r\n, the same email that previously failed now passes DKIM verification. This is not a minor fix—it’s a necessary step for consistent deliverability. The same principle applies to bulk sends: if your email templates or CMS exports use mixed line endings, you’ll see random DKIM failures, especially with strict ISPs like Gmail or Outlook.

MailTester’s inbox placement test helps catch these issues before they impact your sender reputation. It checks not just DKIM, but the full stack: SPF, DMARC, content structure, and header compliance. Use it to verify any new email template before deployment.

When to Validate Your DKIM Signatures (And When Not To)

Validate every DKIM-signed message before sending to high-volume lists or mission-critical campaigns. Skipping this step risks message rejection due to signature mismatches—especially with multipart/alternative content where body canonicalization errors are common. Use real-time validation at scale, not just one-off checks, to catch issues that tools ignoring body normalization may miss.

When to Validate Before Sending

  • Always validate DKIM signatures before sending to lists with more than 1,000 recipients.
  • Test every message using a bulk verification tool, not just one or two addresses—single checks don’t reveal systemic issues.
  • Never trust tools that skip body canonicalization checks; even slight differences in line breaks or whitespace can invalidate a signed message.
  • Use MailTester’s real-time API to verify each message before delivery, especially when using custom templates or dynamic content.

When Not to Trust Your Tools

  • Avoid tools that only check domain or format validity—they won’t surface DKIM failures from canonicalization mismatches.
  • Don’t assume your ESP or email client handles body normalization correctly. It often doesn’t.
  • Use a service like MailTester’s verification API to test actual message rendering and signature validity across real mail servers.

DKIM body canonicalization failures commonly arise when the message body is altered between signing and delivery—especially in multipart/alternative messages where both plain text and HTML versions are present. The signature is generated on a specific canonical version of the body, and even a tiny difference in line endings or whitespace can cause a mismatch. This is why many tools fail silently: they check the signature itself but not the underlying body normalization process.

For example, RFC 6376 (the DKIM specification) defines strict rules for how the body must be processed before signing. If your email client or template engine alters line endings or removes trailing whitespace, the signed body no longer matches the delivered body, and the signature fails. A tool that doesn’t validate this step will mark the message as “valid” even though it will be rejected by receiving servers.

Real delivery testing is the only way to catch these issues. MailTester’s inbox placement feature simulates real inbox behavior across major providers, including Gmail, Outlook, and Yahoo, helping you confirm whether your message arrives and is properly authenticated. This is how you move beyond theoretical validation and into real-world deliverability.

The Role of Email Verification in DKIM and Deliverability Health

You can’t rely solely on DKIM passing to assume an email is deliverable. Invalid or malformed addresses might technically validate with DKIM but still harm your sender reputation, trigger bounces, and reduce inbox placement. Catch-all domains make this worse—DKIM can pass, but no real user exists to receive the message. That’s why verifying your list upfront prevents delivery failures before they happen. MailTester’s bulk verification catches these issues at scale, so you only send to addresses that are both valid and capable of receiving your emails.

Why DKIM Passes Aren’t a Guarantee of Delivery

DKIM signs the email’s content and headers, but it doesn’t verify whether the recipient address actually exists or is actively accepting mail. A malformed or typoed address might still have a valid DKIM signature, but it will bounce—or worse, land in spam traps or be marked as undeliverable. This adds to your sender reputation risk, especially if you're sending at scale. According to RFC 6376, DKIM’s purpose is to authenticate the message, not confirm the destination. That’s where email verification comes in.

How Bulk Verification Prevents Deliverability Risks

MailTester’s bulk verification scans your list for invalid, disposable, or catch-all addresses before you send. Catch-all domains accept all incoming mail but don’t respond to delivery failures, meaning DKIM can pass while your message disappears into a black hole. These addresses inflate bounce rates and hurt your long-term deliverability. By filtering them out early, you reduce false positives and maintain a healthy sender reputation. Over time, this leads to better inbox placement scores—because ISPs see consistent, low-bounce sending patterns.

Let’s say you’re sending a campaign to 10,000 emails. Without verification, even a few thousand bad addresses can trigger ISP filters. With MailTester, you identify and remove invalid entries first. You’ll see a measurable drop in bounce rates and a higher percentage of messages landing in inboxes. This isn’t speculation—it’s how deliverability systems work. The same principle applies whether you’re using bulk verification for marketing lists or validating individual addresses via the email checker before sending. Your list quality directly influences your inbox placement.

Final Checklist: Ensure Your Multipart Emails Pass DKIM

DKIM body canonicalization failures in multipart/alternative emails usually happen when the HTML and plain text parts differ in formatting, line breaks, or whitespace. To fix it, enforce relaxed canonicalization for headers and body, standardize line endings to LF, remove extra whitespace, and re-sign after normalization. Test the result using a real inbox placement tool to confirm the signature validates.

Canonicalization and Formatting

  • Ensure your DKIM signature uses relaxed canonicalization for both headers and body—this is required by RFC 6376 and is standard in most modern email systems.
  • Use consistent line endings: LF (Unix style) across all parts of the email. Avoid CRLF (Windows style) if not necessary, as mixed line endings can break canonicalization.
  • Remove redundant whitespace within the HTML and plain text bodies. Extra spaces, empty lines, or unnecessary indents can alter the canonicalized body and invalidate the signature.

Testing and Re-Signing

  • After normalizing content, re-sign the entire email using your signing tool or mail server. DKIM signatures are tied to the exact byte stream sent, so even small content changes require a new signature.
  • Test the result using MailTester’s inbox placement tool or the real-time verification API. Look for explicit “body canonicalization failure” in the output.
  • Compare the original and signed version using a tool like RFC 6376—the body must be identical after applying relaxed body canonicalization rules, including trimming extra spaces and normalizing line endings.
Even small formatting differences between the HTML and plain text versions can trigger a DKIM failure. The signature validates the exact content as sent—no exceptions.

DKIM Is Not Just About Signing—It’s About Consistency

A DKIM signature is valid only if the receiving server computes the same body hash from the message body as the sending server did during signing.

Canonicalization failures aren’t rare edge cases—they’re clear indicators that the message has been altered in transit or was preprocessed inconsistently.

Even small changes to whitespace, line endings, or content order in multipart/alternative emails can break the hash alignment. Automation and strict preprocessing rules are mandatory to prevent drift across sending systems.

Tools like MailTester help detect these issues early, verifying how your messages will be interpreted by receiving servers. Real-time testing and bulk list checks catch configuration drift before it harms deliverability.

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 is DKIM body canonicalization?

It’s the process of standardizing the body of an email before signing, ensuring receiving servers compute the same hash for verification. Different canonicalization methods can cause signature failures.

Why do multipart/alternative emails fail DKIM verification?

They contain multiple parts with different formatting. Inconsistent line endings, encoding, or whitespace between parts cause body mismatch during canonicalization.

Can DKIM fail even if the signature is present?

Yes. If the body canonicalization differs between sender and receiver, the signature fails—even if the key and header match.

How do I test for DKIM body canonicalization issues?

Use a tool like MailTester that validates both headers and body using real email delivery simulation. Check for 'failed' DKIM status with body-related diagnostics.

Does MailTester check DKIM body canonicalization?

Yes. MailTester’s inbox placement and real-time verification tools check DKIM integrity, including body canonicalization, using compliant validation processes.

How does relaxed canonicalization help fix DKIM issues?

Relaxed mode standardizes whitespace and line breaks, making signatures more resilient to minor formatting differences in delivery.

Can I fix DKIM failures after sending emails?

No. Once sent, you cannot fix a failed DKIM signature. Prevention via testing and pre-signing validation is essential.

What happens if DKIM fails frequently?

Sender reputation drops, emails are more likely to be marked as spam or blocked, and inbox placement deteriorates over time.

Why does a catch-all email fail DKIM validation?

Catch-all domains accept all addresses but may not deliver to specific mailboxes. DKIM can validate the signature, but delivery remains uncertain—leading to reputation issues.

Should I disable DKIM during testing?

No. Test with DKIM enabled to catch canonicalization issues early. Disabling it hides critical failure points in real deployment.

How accurate is MailTester at detecting DKIM issues?

MailTester reports a 98.9% accuracy on verification results, including detailed DKIM integrity checks during inbox placement testing.

Can I use MailTester with SendGrid or HubSpot?

Yes. MailTester integrates with Mailchimp, HubSpot, Klaviyo, and SendGrid to verify email lists and test deliverability before sending.