Why does whitespace in email body canonicalization matter?

You send a clean, well-formatted email. The HTML version looks perfect in the preview. But when it lands in the inbox, line breaks are gone, spacing is off, and the text runs together. You check the source—everything looks right. The issue? Whitespace normalization during canonicalization in multipart/alternative messages.

Emails with both text/plain and text/html parts rely on receivers normalizing content before rendering. If whitespace isn’t handled consistently—trimming or preserving leading/trailing spaces, line breaks, or indenting—rendering breaks. This isn't just cosmetic. Misrendered content can trigger spam filters. Strict mail servers may reject messages that fail canonicalization checks.

Configuring email servers to handle body canonicalization whitespace correctly in multipart/alternative isn’t optional for reliable delivery. This guide explains how to do it, why it matters, and what happens when you skip it.

Key takeaways

  • Whitelist-only domains often misconfigure multipart/alternative processing, leading to inconsistent text/plain rendering.
  • SMTP servers that normalize line breaks without preserving semantic whitespace risk breaking content layout in plain-text fallbacks.
  • Strict mail servers reject messages with inconsistent whitespace handling in multipart/alternative bodies, even if HTML appears correct.

What is body canonicalization, and how does it affect email delivery?

Body canonicalization is the process of normalizing message content—especially whitespace—into a consistent, predictable form before signing, hashing, or validating. It ensures that minor formatting differences, like extra spaces or line breaks, don’t invalidate DKIM or DMARC checks. If your email server alters whitespace differently than the receiving server, even identical content can fail signature verification, leading to delivery failures or spam filtering.

Why whitespace matters in email signing

When you sign an email with DKIM, the signature is based on a standardized version of the message body. The receiving server applies the same canonicalization rules to verify the signature. If your server trims or reflows whitespace in a way that differs from the receiver’s parser—say, collapsing multiple newlines or removing trailing spaces—the hash won’t match, and the signature fails.

This isn’t about visual appearance. It’s about technical consistency. A single extra space or line break in a <body> tag, when processed differently, can break the signature. And because DMARC relies on both DKIM and SPF, a failed DKIM check often triggers rejection or quarantine.

Let’s be clear: this isn’t a defect in your setup. It’s a mismatch in how canonicalization is implemented. Some servers strip all whitespace; others preserve it. The IETF documents [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376) and [RFC 7672](https://www.rfc-editor.org/rfc/rfc7672) define the default canonicalization algorithms—both relaxed and simple—which your server must follow precisely. Deviating, even subtly, breaks the chain.

How to avoid delivery issues caused by canonicalization drift

Most problems happen during message processing: when HTML is rendered, when plain-text parts are auto-folded, or when content is manipulated by third-party tools. If your mailing system or content management platform rewrites line endings or trims whitespace before signing, the result won’t match what the receiver expects.

That’s why email verification matters—before you send, confirm that the email addresses you’re using are valid, properly formatted, and not caught in catch-all or role-based mailboxes that can silently drop messages or trigger reputation damage. You can test this with a real-time email checker like the one available at MailTester’s real-time email checker, which includes validation for common syntax and deliverability risks.

Always test your email flow end-to-end. Use inbox placement tools to simulate how your message appears to major domains. A tool like MailTester’s inbox tester can reveal if your canonicalization behavior is causing rejection at critical steps.

How is whitespace handled differently in text/plain vs text/html?

In text/plain, line breaks and spaces preserve formatting—newlines matter, and extra spaces aren’t collapsed. In text/html, email clients ignore most whitespace between elements, collapsing it during rendering. This difference means text/plain must retain line structure, but overzealous canonicalization can strip meaningful line breaks, breaking readability.

Why text/plain treats whitespace literally

You're sending plain text for a reason: because some users rely on it. In this format, every newline is a deliberate line break. A space between words isn't just filler—it's part of your message's layout. If your server strips trailing spaces or collapses multiple newlines into one, the content can become unreadable, especially in code snippets, addresses, or poetry.

Because the MIME type text/plain is meant to preserve raw structure, tools like email validators must check for structural issues—not just syntax. MailTester’s bulk verification can catch such problems early, ensuring your text/plain content won’t appear garbled or misaligned in recipients’ inboxes.

How HTML collapses whitespace during rendering

HTML clients, from Gmail to Apple Mail, follow rendering rules defined in the HTML specification. They normalize sequences of whitespace—spaces, tabs, newlines—into single spaces or no space at all, depending on context. A paragraph with multiple line breaks appears as one continuous block, with no visual distinction between line endings.

This behavior means that duplicating line breaks in HTML isn’t useful. Instead, structure is handled through HTML elements (like <br>, <div>, <pre>) or CSS. When your server auto-generates HTML from plain text, it must not assume every newline should become a <br>—or you'll create visual clutter.

Canonicalization tools that process mixed content need to know where whitespace is meaningful. For example, a line break in a quote or financial data should be preserved in plain text, but not in HTML. Tools like MailTester’s bulk verification can flag addresses that receive broken content due to bad canonicalization patterns.

When building or managing email servers, remember: treat text/plain like a monospace document, and HTML like a layout engine. The same content can look different depending on which part of multipart/alternative you’re reading. Letting tools handle whitespace inconsistently breaks user experience.

How to configure your email server for consistent body canonicalization

You must configure your MTA and DKIM signer to use consistent whitespace handling—specifically, 'relaxed' canonicalization for both headers and body—so receivers process your messages the same way every time. Without this, tiny formatting differences can break DKIM validation, even if the message content is correct. Let's walk through the setup steps.

Apply relaxed canonicalization across all message components

  1. Ensure your MTA (like Postfix or Exim) preserves line endings and whitespace uniformly during transfer, especially between SMTP sessions. Inconsistent handling during relay can break content comparison.
  2. Configure your DKIM signer (e.g., OpenDKIM) to use relaxed for both header and body canonicalization. This is the most widely accepted standard and aligns with how most receivers validate signatures.
  3. Set the signing policy in your DKIM configuration to apply relaxed body canonicalization explicitly. For example, in OpenDKIM’s opendkim.conf, use Canonicalization relaxed/simple for body.
  4. Test the effect by sending a message with intentional whitespace changes—like extra spaces or line breaks—and verify it still passes DKIM validation at receivers. Tools like RFC 6376 define how relaxed body canonicalization should treat embedded whitespace.

Validate alignment with real-world recipient behavior

  1. Use an inbox placement tester (like the one at MailTester’s inbox tester) to send a test message and check whether it lands in the inbox or spam. Real-world delivery reflects how receivers interpret your DKIM and canonicalization setup.
  2. Inspect the DKIM-Signature header in the received email. Confirm both a=relaxed and b=relaxed are set. If not, receivers may reject or flag the message.
  3. Review logs from your MTA to ensure no intermediate filters alter body whitespace before signing. Some security filters or content scanners can normalize line breaks in ways that break DKIM if not matched during signing.
  4. Regularly audit your email infrastructure using an API-based verification service (MailTester API) to detect issues in large mailing lists that might expose misconfigurations over time.

Relaxed canonicalization is not optional—it’s the de facto standard for maintainable, deliverable email. Ignoring it leads to intermittent DKIM failures even with correct signing keys. You’re not just signing a message; you’re signaling trust through predictable formatting.

Standard DKIM body canonicalization policies: what they do in practice

You need to understand how DKIM signs email bodies because email servers process whitespace differently. Most major providers use relaxed body canonicalization—normalizing line breaks and collapsing extra spaces. If your server uses simple mode, your signatures may fail to validate on receivers like Gmail or Outlook, even when content is functionally identical. This mismatch breaks authentication, risking delivery or marking messages as spam.

How major providers handle whitespace normalization

When DKIM signs an email, the body must be transformed (canonicalized) to a standard form before hashing. The two main policies—simple and relaxed—produce different results even for the same message.

Policy Whitespace handling Used by Result
Simple Preserves every newline, space, and tab exactly as sent. No normalization. Legacy systems, some internal or custom MTAs. High fidelity but fragile—tiny formatting changes (e.g. adding a blank line) break the signature, even if the content is identical.
Relaxed Normalizes line endings to CRLF, trims leading/trailing whitespace on each line, collapses multiple internal spaces into one. Gmail, Yahoo Mail, Outlook.com, Apple Mail, most major providers. Robust to minor formatting changes. Matches how users see content in practice.

Most modern email infrastructure, including the major providers, relies on relaxed. This means if your server uses simple mode, your DKIM signature will likely fail validation on the receiving end.

Why relaxed dominates in practice

Relaxed canonicalization mirrors how email clients render content. The web’s text display models collapse extra whitespace for readability—so do receivers validating DKIM. This reduces false negatives due to formatting artifacts.

The DKIM specification explicitly defines both policies but acknowledges relaxed is preferred in deployment. Tools like MXToolbox can help verify signature alignment when testing configurations.

Let’s be clear: you can’t assume your recipient will use the same canonicalization policy. If your mail server defaults to simple, you're asking for failed authentications. Always test your signatures in real-world conditions—especially if you're sending bulk or transactional mail.

To catch these issues early, verify your email infrastructure’s behavior with actual test mail. Use MailTester’s inbox placement tests to check how your messages land with major providers. It reveals delivery issues before they affect your reputation.

Common configuration errors in body canonicalization

You’re likely to trigger delivery failures or spam filtering if your email server uses strict whitespace handling while recipients expect relaxed normalization—especially in multipart/alternative bodies. This mismatch corrupts the canonical form used in DKIM signing, breaking message integrity. Make sure your server’s body canonicalization mode matches what receivers actually accept, or expect to see consistent behavior across all MIME parts.

Incorrect enforcement of whitespace rules

  • Using simple body canonicalization on servers that send to receivers expecting relaxed rules will invalidate DKIM signatures. This happens when line breaks, spaces, or indentation changes alter byte content after signing—common in HTML-to-plain text conversions.
  • Failing to normalize line endings and leading/trailing whitespace during HTML-to-plain conversion leads to unescaped newlines that alter the signature digest. Even a single misplaced space can cause verification failure.
  • Applying aggressive whitespace stripping in pre-signing filters—especially in MTA or gateway layers—can permanently change the message body, rendering previously valid signatures invalid. This breaks DKIM unless the same normalization is applied at verification time.

How to fix these issues

  • Use relaxed canonicalization for body when sending to most modern recipients. It’s the industry-standard expectation and aligns with how most mail servers verify DKIM.
  • Ensure that any HTML-to-plain text transformation tool (like Mail-Tester’s inbox placement check) preserves whitespace consistency and properly escapes line breaks, especially in pre or blockquote elements.
  • Apply whitespace normalization only once, and only after signing. If normalization happens before signature generation, it must be replicated at verification time—otherwise, the digest will differ.
  • Test your setup with real-world receivers. Tools like inbox placement testing can help expose signature issues caused by incorrect canonicalization.

When in doubt, run your messages through an email validation service that checks delivery behavior across real inboxes. Services like bulk email verification catch structural flaws before you send, including those tied to signing integrity.

How to verify your email server's body canonicalization behavior

You can verify your email server’s body canonicalization behavior by sending a test message with intentional whitespace (multiple spaces, line breaks, and mixed formatting), capturing the raw SMTP output before and after DKIM signing, and comparing the body content. If the body differs unexpectedly after signing, your server is applying inconsistent or incorrect canonicalization. This is critical when using third-party services or multiple relay points, where whitespace rules can break DKIM validation.

Step-by-step verification process

  1. Prepare a test message with known whitespace. Use a single paragraph containing multiple spaces, line breaks, and mixed indentation (e.g., extra spaces after punctuation, blank lines within text). This creates a clear baseline to detect canonicalization changes. The goal is to expose any silent removal or alteration of whitespace during processing.
  2. Send the message through your server stack. Deliver it through your own mail server, or via a trusted third-party relay (e.g., SendGrid, Amazon SES) if you’re testing a downstream configuration. Use a real, authorized domain to ensure DKIM can be properly checked later.
  3. Extract the raw message before DKIM signing. Capture the message just before it’s signed—ideally from a pre-DKIM logging point in your mail server (e.g., via a Milter, Postfix content filter, or a debug log). This gives you the "source" body as seen by the signing process.
  4. Extract the raw message after DKIM signing. Capture the final outgoing SMTP message, including headers, body, and the DKIM-Signature header. You can use tools like RFC 6376 (DKIM) to verify expected structure and canonicalization policy.
  5. Compare body content manually or with a tool. Use OpenDKIM's verifier or a DKIM validator service to parse the signed message. Compare the body content from step 3 (pre-signature) with step 4 (post-signature). Any difference in whitespace, line breaks, or paragraph formatting indicates inconsistent behavior.
  6. Check behavior across relay points. If you use multiple email services, repeat the test through each relay endpoint. Some services apply relaxed canonicalization (e.g., relaxed) by default, which may normalize whitespace. Your server must either respect this behavior or explicitly configure it to ensure consistency.

Common pitfalls and fixes

Many servers default to relaxed body canonicalization, which collapses whitespace and adjusts line endings. While this works for most messages, it can break DKIM if the signing process uses a strict standard. If your server alters the body unexpectedly, inspect your MTA (e.g., Exim, Postfix, Sendmail) configuration for body canonicalization options. Ensure consistent use of simple or relaxed policies across all relay points.

Let’s be clear: mismatched canonicalization is a silent killer of DKIM. It doesn’t cause immediate bounces, but it breaks authentication and damages sender reputation over time. Use the tools you have—debug logs, OpenDKIM, or a trusted validator—to spot inconsistency before delivery.

How MailTester helps you verify email infrastructure correctness

You don’t just send emails—you send rendered content. MailTester’s inbox-placement testing gives you real proof that your email server’s body canonicalization, whitespace handling, and multipart/alternative structure work as intended across actual inboxes like Gmail, Outlook, and Apple Mail. It checks whether your message appears correctly after processing, not just technically valid.

Test how your message renders in real user environments

Many deliverability issues start before the inbox: if your email server mismanages whitespace in multipart/alternative bodies—especially across different content-types like HTML and plain text—clients may render it poorly or reject it entirely. MailTester sends test messages to real inboxes and reports back on actual rendering outcomes, including whether whitespace is collapsed correctly, alternate parts display properly, and signatures survive transit.

This is not theoretical. The MIME standard (RFC 2046) specifies how multipart bodies should be structured and processed, but implementation varies. For example, some servers insert or strip whitespace between HTML and text parts in a way that breaks readability or triggers validation failures. MailTester’s in-app testing suite detects these flaws during rendering—not just on syntax alone.

Pinpoint root causes: canonicalization, missing parts, signature errors

Our inbox placement tests flag common but subtle issues: missing or malformed alternative parts, inconsistent formatting in plain text fallbacks, or incorrect header alignment due to improper body normalization. These aren’t always caught by basic syntax checks, but they impact user experience and can hurt sender reputation over time.

For teams relying on automated systems, this kind of verification is non-negotiable. You can spot problems before sending to a full list—whether you’re using our inbox placement tester or integrating with our real-time verification API. It’s how you ensure your message content remains consistent, usable, and trustworthy no matter the receiving end.

While tools like Spamhaus or MxToolbox help with reputation and DNS checks, they don’t render content. MailTester’s focus is on what happens after delivery: that your final message, after all processing and canonicalization, still means what you intended.

What happens if you ignore body canonicalization whitespace rules?

If you ignore body canonicalization whitespace rules in multipart/alternative email bodies, your DKIM signatures may fail, leading to authentication issues that hurt sender reputation and reduce inbox placement. Misaligned whitespace can cause rendering problems—text may wrap incorrectly, links break, or content collapses—lowering engagement and increasing bounce rates. Recipients or spam filters may flag repeated deviations as suspicious behavior, further harming deliverability.

DKIM failures from improper canonicalization

DKIM signs the body of an email after applying a specific canonicalization process. If your server alters whitespace inconsistently—adding, removing, or normalizing it differently than the signing server expects—the signature verification will fail. This appears as a "DKIM verification failed" error to receiving mail servers, which can result in rejection or automatic spam filtering.

According to RFC 6376, Section 3.5, canonicalization defines how line breaks and whitespace are normalized before signing. Skipping or misapplying this step means your message, even if content-wise correct, fails integrity checks. This isn't a minor quirk—it’s a core requirement for authentication to succeed.

Render issues and sender reputation risk

Even if DKIM passes, incorrect whitespace handling can still break email rendering. Some clients strip or collapse extraneous whitespace, turning carefully formatted text into a jumbled mess. A paragraph meant to be readable may instead render as a single, unbreakable line, or links may lose their structure.

Repeated rendering failures across multiple sends make your domain look unreliable. Spam filters don’t just scan content—they track patterns in delivery behavior. If your messages consistently arrive with formatting errors, especially in the body (which is part of the canonicalized data), they may be flagged as suspicious, even if they’re not malicious.

Using tools like MailTester’s email checker can help catch issues before sending by validating how your email content will be processed by standards-compliant servers.

Best practices for email server configuration and testing

You should use 'relaxed' body canonicalization by default unless you're working with a legacy system that requires strict enforcement. Always normalize whitespace in plain-text output—especially after converting HTML to plain text—and validate real-world inbox behavior with tools that simulate actual recipient filtering, not just syntax checkers. After any change, monitor deliverability metrics like bounce rates and inbox placement to ensure you haven’t introduced unintended side effects.

Configuration guidelines

  • Set body canonicalization to relaxed in your MTA (e.g., Postfix, Exim) unless you have a documented need for strict handling—this is widely recommended to preserve message integrity across routing hops.
  • Ensure your HTML-to-plain-text converter strips line breaks and excessive whitespace consistently, avoiding inconsistencies that can trigger spam filters or break readability.
  • Use RFC 5322 section 3.2.4 as a reference for proper line folding and whitespace handling in email bodies.
  • Never assume a validator that checks syntax alone captures inbox behavior—real-world filters apply rules beyond RFC compliance, especially for whitespace in body content.

Testing and monitoring

  • Test every change using tools that simulate actual inbox environments—use inbox placement testers like MailTester's inbox simulator to see how your emails land in Gmail, Outlook, and other major inboxes under real delivery conditions.
  • Monitor post-send metrics like bounce rate, open rate, and spam complaint volume after updating canonicalization rules—small changes can trigger unexpected filtering.
  • Check if your server logs show consistent handling of line endings and whitespace across all message parts, especially in multipart/alternative bodies.
  • Validate both inbound and outbound flows to catch inconsistencies early—misconfigured canonicalization can break both delivery and spam filtering.
  • If you’re processing large volumes, run periodic bulk verification tests with MailTester’s list verification to surface invalid or problematic addresses before sending.

Conclusion: Fixing whitespace handling is part of inbox delivery

Body canonicalization is not a minor detail—it affects signing, rendering, and spam filtering. Even small inconsistencies in whitespace processing can break DKIM signatures and trigger false positives in spam filters.

Consistent, predictable whitespace handling ensures reliable delivery across Gmail, Outlook, Apple Mail, and other major platforms. The difference between a delivered message and a bounced one often lies in how content is normalized during transmission.

Use tools like MailTester to validate your message structure end-to-end, not just at the SMTP layer. Real-time verification and inbox placement testing reveal hidden issues that syntax checks alone miss.

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 body canonicalization in email?

It is the process of normalizing message content—removing or standardizing non-significant whitespace—before signing or validating. This ensures consistent interpretation across email systems.

Why does whitespace matter in multipart/alternative emails?

Different email clients handle whitespace differently in text/plain vs. text/html. Inconsistencies can break rendering or invalidate DKIM signatures.

What DKIM canonicalization policy should I use?

Use 'relaxed' for both body and header. It is the industry standard and most widely supported by major email providers.

Can whitespace issues cause email rejection?

Not directly, but they can lead to DKIM failures, which can block delivery or harm sender reputation.

How do I test if my server handles whitespace correctly?

Use tools like MailTester to send test messages and check how they render in real inboxes. Look for formatting issues and signature validation results.

Does MailTester check DKIM signature validity?

Yes, MailTester includes DKIM signature validation in its inbox-placement tests, catching issues including incorrect canonicalization.

What is the difference between 'simple' and 'relaxed' body canonicalization?

'Simple' preserves all whitespace exactly as sent. 'Relaxed' normalizes line breaks and trims extra spaces—used by most email providers.

Can third-party email services cause canonicalization problems?

Yes, if their servers use different canonicalization policies than your own, it can break DKIM. Ensure alignment across your entire sending stack.

What is the impact of inconsistent body canonicalization on deliverability?

It can result in DKIM failures, reduced sender reputation, increased spam filtering, and lower inbox placement.

How do I fix failed DKIM signatures due to whitespace?

Verify your DKIM signing configuration uses 'relaxed' body canonicalization. Ensure your text/plain generation preserves intended structure without unnecessary whitespace.

Do all email providers use the same whitespace rules?

Most major providers use 'relaxed' body canonicalization, but differences in implementation can still cause validation mismatches.

Is body canonicalization only relevant for DKIM?

While most critical for DKIM and DMARC, consistent whitespace handling also affects how emails render across clients and improves overall reliability.