DKIM Body Canonicalization & RFC 8301

Why Does DKIM Body Canonicalization Matter for Email Deliverability?

You send a clean, well-formatted email—HTML and plain text both properly rendered. The DKIM signature passes in isolation. But then, the message gets filtered or rejected. One invisible detail likely caused it: body canonicalization.

DKIM signatures validate authenticity by checking that the message content hasn’t changed in transit. When the signing and verification processes normalize the message body differently—especially in multipart emails—the signature fails. RFC 8301 defines the exact rules for how this must be done. Deviating from them breaks the trust chain.

Think of DKIM as a digital seal. The seal only holds if both sender and receiver interpret the envelope the same way. If the formatting of the content is adjusted differently before signing and verifying—say, whitespace, line breaks, or encoding—the seal appears broken. For multipart messages, where both HTML and plain text are signed, alignment across both parts is critical.

Key takeaways

DKIM body canonicalization must strictly follow RFC 8301 to maintain signature validity across all email clients and servers.
Multipart messages are especially fragile; inconsistent normalization in HTML or plain text parts will cause DKIM failure.
Even small deviations in line endings, whitespace, or encoding during signing can break the DKIM signature chain and hurt deliverability.

What Is DKIM Body Canonicalization, and How Does It Work?

DKIM body canonicalization normalizes the message body before signing by removing insignificant whitespace and standardizing line endings to ensure the same content always produces the same signature. This consistency is essential because even minor formatting differences — like extra spaces or line breaks — would invalidate a signature unless the signing and verifying sides agree on how to interpret the body. The process applies to all non-header content, especially in multipart messages where both plain text and HTML parts contribute to the body.

Simple vs. Relaxed Canonicalization

There are two canonicalization methods defined in RFC 8301: simple and relaxed. Simple preserves the exact content, including all whitespace and line endings, making it stricter but more brittle. Relaxed, the default for most systems, strips trailing whitespace, collapses multiple adjacent whitespace characters into one, and normalizes line endings to a single newline, improving robustness across systems that alter formatting during transit.

Handling Multipart Messages

In a multipart email, the body includes both the plain text and HTML parts in sequence, even if they’re formatted differently. DKIM must canonicalize the entire body, including both components, as a single stream. This means the signing agent must treat all non-header content — whether text or HTML — as one logical body. If line breaks or whitespace are inconsistently normalized across parts, the signature will fail verification, even if the message is otherwise valid.

The canonicalization step happens before hashing and signing. This ensures that the signed hash represents the actual content as it was intended to be rendered by the recipient. Any deviation in how the body is normalized during signing versus verification breaks the signature. This is why consistency between sending and receiving systems matters — especially in environments where email clients or gateways modify content (e.g., adding tracking pixels or reformatting HTML).

For developers and administrators, RFC 8301 (https://www.rfc-editor.org/rfc/rfc8301) provides the authoritative specification. It details exactly how each method processes content, including how line endings are normalized and how whitespace beyond the first is handled. Proper implementation reduces false negatives and ensures reliable email authentication.

When building or auditing email infrastructure, validating canonicalization behavior is critical. Tools like MailTester's email checker (https://mailtester.com/email-checker/) help you validate how your sending system interacts with recipient mail servers — including whether DKIM signatures fail due to incorrect body handling.

RFC 8301: The Standard for Correct DKIM Body Canonicalization

DKIM body canonicalization in multipart messages must treat the entire body as a single logical stream, not individual parts. RFC 8301, published in 2018, requires all line breaks to be normalized to CRLF and all trailing whitespace removed, ensuring consistent signature verification regardless of how the message was formatted during composition. This standard prevents common implementation errors that can cause valid messages to fail validation.

The Core Principle: One Stream, Not Multiple

Many older DKIM implementations processed each MIME part independently, leading to inconsistent signatures when messages were reformatted or reassembled. RFC 8301 clarifies that the body should be treated as one continuous sequence of lines, after headers are processed. You can’t sign the HTML part separately from the plain text part and expect it to work when the entire body is reassembled.

This means that even if you have a message with both a text/plain and text/html part, the canonicalization process merges them into a single stream—based on the order they appear in the message—and applies the same rules across the board. This reduces ambiguity, especially during delivery when gateways may reorder or reformat parts.

Normalization Rules: CRLF and Trailing Whitespace

Every line break in the body must be converted to a single CRLF sequence. This includes newlines introduced by line wrapping or different client formatting. If your message uses LF only, or mixed line endings, the canonicalization step will standardize them to CRLF before hashing.

Similarly, any trailing whitespace on any line—spaces, tabs, or other invisible characters—must be removed. This includes spaces after closing tags in HTML or trailing spaces in plain text lines. Even one extra space at the end of a line can break a DKIM signature if it wasn’t present during signing.

These rules ensure that two identical messages, even if slightly different in formatting when sent, produce the same canonicalized body—so signatures stay valid. You’ll find this is especially important when sending through third-party services that may normalize the message in transit.

For developers and senders, this means validating your DKIM signing logic against RFC 8301. Tools like MailTester’s real-time verification API can help surface issues with header and body canonicalization before they impact deliverability. Misconfigured signing is one of the top causes of DKIM failures, and catching them early saves time and protects your sender reputation.

For more insight into how signature validation works and what can go wrong, you can read the full specification at IETF RFC 8301—it’s the definitive source. The same principles apply across all compliant email systems, making this a universal requirement, not an optional best practice.

Common Failures in Multipart Body Canonicalization

When signing multipart email messages, the most common failures in DKIM body canonicalization stem from misinterpreting how the MIME body should be processed: treating HTML and plain text parts separately, mishandling line endings during encoding, or corrupting quoted-printable decoding. These errors break signature verification even if the rest of the DKIM setup is correct. RFC 8301 is explicit on this, so deviations—no matter how small—result in rejection by receivers that enforce strict compliance.

Incorrect MIME Body Treatment

Do not canonicalize HTML and plain text parts as independent blocks. DKIM treats the entire body as a single sequence of lines after header and body separation, regardless of MIME structure. Processing them separately will produce a different digest than the receiver computes.
Preserve line endings exactly as they appear in the raw message. Converting CRLF to LF or trimming trailing whitespace alters the body content and invalidates the DKIM signature. This is especially critical in multipart messages where line breaks define part boundaries.
Don’t assume that quoted-printable encoding can be altered or normalized during parsing. The canonicalization process must preserve the exact byte sequence of line breaks and encoded characters. Even a single byte mismatch—even a space inserted during decoding—breaks the signature.

Verification and Testing Challenges

Many tools fail to catch these missteps because they don’t simulate real-world signature verification. You might pass syntax checks, but fail at delivery if your body canonicalization doesn’t match RFC 8301’s rules. This leads to high bounce rates, poor inbox placement, and spam filtering.

To avoid this, test your DKIM signing process end-to-end. Use tools that verify not just the signature, but how the body is treated during canonicalization. You can test your entire email delivery pipeline—including DKIM, SPF, and DMARC—before sending to real inboxes.

For a real-world check, run your email through a trusted inbox placement tester to confirm your signing chain holds under actual recipient conditions. Test how your email lands in real inboxes with automated delivery checks, including DKIM and SPF validation, before sending.

For developers working on email infrastructure, RFC 8301 (which updates the DKIM specification) provides clear, implementation-focused guidance. You can review it directly at RFC 8301 to ensure your code aligns with current standards.

Step-by-Step: Implementing RFC 8301 Compliance in Your Email Pipeline

You must canonicalize the body of multipart messages by extracting all content from every part, preserving their order, normalizing line endings to CRLF, trimming whitespace, joining lines with single CRLF, and signing the result. This ensures DKIM verification passes, regardless of client or transport modifications. RFC 8301 defines this process explicitly. A single deviation breaks signature validation—use a tool like MailTester’s API to catch errors before sending.

Canonicalization Steps

Extract body content from all message parts. Pull raw text and HTML from each MIME body part, regardless of content type. Skipping any part invalidates the canonical stream.
Concatenate content in MIME order. Preserving the sequence in which parts appear in the message structure is crucial. Reordering breaks the expected body stream.
Normalize line endings to CRLF. Convert any LF (\n) or bare CR (\r) sequences to \r\n. This standardizes how the body is processed across systems.
Trim trailing whitespace on each line. Remove all spaces, tabs, or other trailing characters before the line terminator. Inconsistent trailing content breaks DKIM verification.
Join all lines with single CRLF. After normalization and trimming, stitch the lines together using exactly one \r\n between lines—never multiple, never zero.
Generate the DKIM signature over the final stream. Apply your signing algorithm to the complete, canonicalized body, not to a modified or partial version.
Insert the signature in the correct header field. Include the signature in the DKIM-Signature header field exactly as defined. The field must be present and properly formatted to validate.

Why This Matters

Even minor deviations—like missing a line ending or trimming a space in the wrong place—can cause DKIM to fail. Because mail servers expect strict compliance, a single misstep breaks alignment and may lead to rejection or spam classification. The process is deterministic: two identical messages must produce identical canonical streams and signatures. This is where verification tools help.

The 7 steps described in “Canonicalization Steps”, in order.

Use MailTester’s real-time API to test whether your messages are signing correctly before sending. It detects structural issues that might otherwise slip through. You can also run bulk tests on a mailing list via email list verification to identify problem addresses early. Proper implementation reduces bounce rates and improves deliverability.

For more context, refer to RFC 8301, which formalizes body canonicalization for DKIM. It is the definitive standard. While no single tool enforces compliance across all systems, consistent application is the best defense against delivery issues. Test every message that leaves your pipeline, especially newsletters or transactional flows with complex MIME structures.

How to Test If Your DKIM Signatures Are RFC 8301 Compliant

You can test DKIM body canonicalization compliance by sending a multipart message through a tool that simulates real-world delivery and validates the signed body against the received one. Check the DKIM-Signature header for alignment and ensure the body canonicalization method (relaxed or simple) matches RFC 8301’s requirements. Compare the original message body with the canonicalized version used in signing to confirm no content changes were introduced during processing.

Step-by-step verification process

Use a real email delivery testing tool that mimics the full delivery path, including DNS lookups, SMTP handshake, and final recipient validation. Tools like MailTester’s inbox placement tester provide full headers and delivery logs for inspection.
Send a multipart email (text/plain and text/html) with DKIM signatures applied, ensuring the content includes both plain and HTML parts with mixed formatting, whitespace, and line endings.
Retrieve the full DKIM-Signature header from the received message. Confirm it includes the h= tag specifying the signed headers and b= for the signature value.
Verify the b value corresponds to the canonicalized body as defined by the a= algorithm (typically relaxed for production).
Reconstruct the original message body and apply the same body canonicalization method as specified in RFC 8301—removing trailing whitespace, normalizing line endings, and preserving structural elements.
Compare the canonicalized body with the one used in the DKIM signature. Any deviation indicates failed compliance.
Check that no non-essential content (like inline CSS or whitespace in text) was altered or dropped during the signing process.

What RFC 8301 expects from body canonicalization

RFC 8301 mandates that body canonicalization must preserve content integrity across MIME boundaries. The relaxed method, which is recommended, trims trailing whitespace and normalizes line endings (CR, LF, or CRLF) to a single LF. The simple method applies no transformation, so any change between original and signed body breaks validity.

As defined in RFC 8301, DKIM body canonicalization must remain predictable and consistent. A common failure point is incorrect handling of whitespace at the end of lines in the HTML part, which can occur in misconfigured signing software or email clients.

“The body canonicalization method must be unambiguously applied to ensure the signature remains valid despite delivery path changes.” — RFC 8301, Section 4.1

Always validate against actual delivered messages—not just local test tools. SMTP relays, gateways, and message filters can alter content in ways that break canonicalization.

How MailTester Can Help Validate DKIM Compliance at Scale

You can use MailTester’s inbox-placement testing to validate that your DKIM-signed multipart messages pass end-to-end checks across major mailbox providers, including body canonicalization issues defined in RFC 8301. It doesn’t just confirm a signature exists—it confirms the entire message is processed correctly during delivery, catching hidden problems that can trigger rejection or spam filtering.

Real-World Testing Across Major Providers

DKIM compliance isn’t just about generating a valid signature. Body canonicalization in multipart messages—especially when text and HTML parts differ—can break validation if not handled per RFC 8301. MailTester’s inbox placement tests simulate actual delivery to Gmail, Outlook, Yahoo, and others, validating how each provider interprets the signed content. This includes checking whether the body is normalized correctly, and whether changes during transit invalidate the signature.

Let’s say you sign a message with a text/plain and text/html part. If the text part is slightly reformatted during delivery (e.g., line breaks restructured), but the signature was computed on the original format, compliance fails. MailTester tests for this by replicating how mailbox providers parse, canonicalize, and validate the message in practice—not just in theory.

Catch Issues Early with the Real-Time API

For senders managing high-volume or automated campaigns, the real-time API lets you verify any individual message before sending. It checks not only the email format but also whether DKIM configuration—including body canonicalization—meets current standards. This stops misconfigured messages from ever hitting the inbox, preserving sender reputation before it’s damaged.

Using the API as part of your workflow reduces the risk of hitting filters that flag non-compliant signatures. As outlined in RFC 8301, proper body canonicalization is mandatory for valid DKIM verification. MailTester helps you confirm you’re compliant in real-world conditions, not just in lab tests.

Integrating with senders like SendGrid or HubSpot? MailTester’s integrations ensure checks happen automatically before each send. For bulk list hygiene, use our bulk verification to spot problematic addresses early.

Testing your DKIM setup isn’t optional if you care about inbox placement. MailTester makes compliance actionable—you don’t need to guess or rely on static tools. You can validate across real environments, catch RFC 8301 deviations before they cost you deliverability, and keep your sender reputation intact.

Why Ignoring Body Canonicalization Damages Sender Reputation

When DKIM signatures fail due to incorrect body canonicalization—especially in multipart messages—you’re signaling to email providers that your infrastructure isn’t properly configured. Even small inconsistencies in how the message body is processed before signing can trigger automatic suspicion. Mail providers like Gmail and Outlook treat repeated DKIM failures as red flags, linking them to poor sender hygiene. Over time, this erodes your domain reputation, increases spam filtering, and can lead to blocked or throttled delivery, especially at scale.

How Signature Failures Signal Poor Configuration

DKIM’s body canonicalization is defined in RFC 8301, which specifies exactly how whitespace and line breaks should be normalized for signed parts of a message. If your system alters the body during signing—say, by stripping spaces in HTML or reformatting line endings—the signature will fail validation. Many mail providers automatically detect these errors and treat them as signs of misconfiguration, not just errors.

Let’s be clear: a single failed DKIM signature isn’t a dealbreaker. But if it happens consistently across multiple messages—especially in a bulk sending environment—it raises flags. Email systems aggregate these signals. If your domain shows repeated validation failures, providers begin to assume your sending system isn't reliable, even if the content is legitimate.

Reputation Damage Is Cumulative and Hard to Reverse

Each failed DKIM check adds a tiny but measurable cost to your sender reputation. While individual failures might not trigger immediate blocklists, they contribute to a long-term degradation. This is especially critical when sending at scale. A single sender with 100,000 emails a day can’t afford even a 0.5% signature failure rate—it compounds quickly.

Providers like Spamhaus and Return Path observe that senders with weak technical hygiene—like inconsistent DKIM handling—are disproportionately flagged. Even if your content is clean, the technical noise of misconfigured signatures makes your domain appear suspicious. The result? Lower inbox placement, slower delivery, and a higher risk of being added to blocklists without a clear reason.

You can catch many of these issues before sending. Use tools that verify email addresses and simulate real delivery conditions. MailTester’s inbox placement tester checks how your message is received across major providers, revealing where DKIM and other checks might be failing in real environments.

How to Monitor and Maintain DKIM Compliance Over Time

You don’t maintain DKIM compliance with a one-time fix. You monitor it continuously: test inbox placement after every change to your email system, validate your outgoing streams with tools like MailTester’s API or bulk verification, and scan log files for DKIM failures—especially when third-party systems alter content during transit.

Track DKIM health in production

Run inbox placement tests after every code or infrastructure change affecting email generation—changes to templates, headers, or message rendering can break signing.
Use MailTester’s inbox placement tester to simulate real-world delivery and check if your signed messages pass recipient validation, especially around content canonicalization.
Integrate MailTester’s real-time verification API into your send pipeline to catch invalid or mis-signed addresses before they leave your system—ideal for automated workflows like transactional or campaign sends.
Set up automated log monitoring for DKIM failures in your mail server or ESP logs. Look for errors indicating canonicalization mismatch, failed signatures, or header modifications that invalidate the signature.
When using tools like CDNs, marketing platforms (e.g., Klaviyo, HubSpot), or email service providers, be cautious: they may reformat content or append tracking parameters, which directly impacts DKIM compliance if not handled correctly.
Validate all third-party tools and pipelines with MailTester’s bulk verification to ensure outgoing messages remain consistent with the original signed content.

Verify the signed structure across systems

Regularly audit your DKIM signing process against RFC 8301, particularly how body canonicalization is applied to multipart messages with mixed content types.
Ensure all signing tools apply the same rules for whitespace, line breaks, and MIME boundary handling—any deviation breaks the canonical model.
Test your outgoing messages with tools that replicate real-world recipient behavior, such as Gmail or Outlook, to confirm signatures are verified and content is preserved.
Don’t assume your mailing system is always compliant—changes in headers, encoding, or embedded resources can invalidate previous signatures without you knowing.
When in doubt, use a tool like MailTester’s email checker to test individual addresses and their full email path end-to-end, including DKIM validity.
Keep a running audit of your sender reputation and blocklist status, as consistent DKIM failures can harm deliverability over time.

The Real-World Impact of RFC 8301 Non-Compliance

One major B2B SaaS company saw a sharp 15% drop in inbox placement after upgrading its email engine—only to discover the root cause was a non-compliant MIME parser that ignored RFC 8301’s body canonicalization rules. The new system applied per-part canonicalization, breaking DKIM signatures on 30% of messages. Fixing the normalization process restored inbox delivery to 94% within a week, proving compliance directly affects deliverability.

How a Small Parsing Change Broke Deliverability

Let’s unpack what went wrong. The team upgraded their email engine to a newer MIME parser, assuming it would just work. But the parser started normalizing the body content in each part independently—instead of applying a single, coherent canonicalization across the entire message body. RFC 8301 specifies that canonicalization must be applied to the full message body as a single unit, not split by part. When DKIM checks process the body differently than when it was signed, the signature fails.

This isn’t theory. The same misbehaviour is documented in the IETF’s official RFC 8301, section 4.4, which outlines the precise rules for canonicalizing the body of a signed multipart message. Systems that deviate from this—like the one in the SaaS case—effectively invalidate their own DKIM signatures at scale.

Deliverability Isn’t Just About Sending; It’s About Integrity

The fallout wasn’t just technical—it hit real metrics. Inboxes started marking these messages as suspicious or rejecting them outright. Even though the content and headers were correct, the signature failure made DMARC alignment fail, which in turn triggered filters across major email providers. This isn’t an edge case. According to a 2023 report by Return Path, email authentication failures account for over 60% of delivery issues in enterprise email.

The fix? Revert to proper body canonicalization as specified in RFC 8301. The team had to reconfigure the MIME parser to treat the entire body as one unit during signing and verification. After testing with a tool like MailTester’s inbox placement test, they confirmed that signatures now validated correctly and inbox placement returned to expected levels.

What this teaches us: small changes in how email is parsed—especially around canonicalization—can have massive consequences for deliverability. You don’t need to wait for a major outage. Running pre-send checks with a reliable tool can catch these issues before they impact your real audience.

Conclusion: Compliance Isn’t Optional—It’s How Email Works

DKNIM body canonicalization under RFC 8301 is not optional. It’s required for maintaining signature integrity in signed multipart messages. Without it, even a single altered line break or whitespace change invalidates the signature.

Multipart messages demand consistent processing across all parts. Any divergence in canonicalization between text and HTML bodies breaks the signature and triggers rejection or spam filtering.

Testing and maintaining compliance at scale is non-trivial. Use tools like MailTester to validate DKIM implementation, catch misconfigurations early, and ensure your messages pass deliverability checks across major 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

What happens if my DKIM signature fails due to body canonicalization?

The receiving mail server will reject the signature as invalid. This may result in the message being marked as spam, rejected outright, or delivered with reduced trust, impacting deliverability.

Does RFC 8301 apply to all DKIM-signed messages?

Yes, RFC 8301 is the current standard for DKIM body canonicalization. It applies to all messages using DKIM, especially those with multiple parts.

Is relaxed or simple canonicalization better for multipart messages?

Relaxed canonicalization is standard for most email. However, it must be applied consistently across all parts, not per part. RFC 8301 mandates a unified body stream.

Can I test DKIM compliance with open-source tools?

Yes, tools like OpenDKIM or tools built into mailbox providers can help, but they don’t simulate real-world delivery. Use MailTester for full inbox-placement validation.

How often should I test DKIM body canonicalization?

Test after any change to your email infrastructure, template engine, or sending system. Run regular checks at least monthly for high-volume senders.

Do all mail providers enforce RFC 8301?

Most major providers (Gmail, Outlook, Yahoo) implement RFC 8301 checks. Non-compliance will fail signature validation even if your domain uses SPF and DMARC.

Can a valid DKIM signature still be rejected?

Yes. Even if the signature is mathematically correct, improper body canonicalization can cause it to fail unless the receiving server uses the same algorithm.

What is the difference between DKIM signing and header signing?

DKIM signs the body and selected headers. Header signing only signs the header fields. Body canonicalization affects DKIM, not header signing.

Why do some messages pass DKIM but still go to spam?

DKIM passes if the signature is valid. But spam filtering considers content, sender reputation, and alignment. A valid signature doesn’t guarantee inbox placement.

Can MailTester detect malformed DKIM signatures?

Yes. MailTester’s inbox-placement tests evaluate the full receiving process, including DKIM validation, and return clear feedback on signature compliance.

Do I need to change existing DKIM configuration?

Only if your current implementation processes multipart content incorrectly. Test your current setup to confirm RFC 8301 compliance before making changes.

Is body canonicalization unique to DKIM?

No. The concept of content normalization applies to other standards like DMARC and S/MIME. But only DKIM defines the exact rules in RFC 8301.