Multipart MIME & DKIM c=relaxed

Why does DKIM relaxed canonicalization matter for email deliverability in SaaS tools?

You send a transactional email from your SaaS platform—password reset, onboarding summary, invoice—and it bounces. Not because the address is invalid. Not because of spam filters. Because a single line break, a missing space, or a misordered MIME header broke the DKIM signature.

DKIM signatures trust the integrity of an email: they check if content has changed since signing. But relaxed canonicalization (c=relaxed) is meant to ignore minor, non-content changes—like whitespace or line breaks—so long as the core message remains unchanged. It’s the difference between rejecting a letter because a comma is slightly off and accepting it because the meaning is intact.

When multipart MIME headers are misconfigured, even small deviations can break relaxed canonicalization. That means valid emails—correctly sent, properly signed—are rejected. This is especially common in SaaS tools that auto-generate complex email content with dynamic content blocks. You’re not doing anything wrong. The system is.

Key takeaways

Relaxed canonicalization (c=relaxed) allows minor, non-content changes like line breaks to be ignored during DKIM verification, improving deliverability tolerance for automated email systems.
Misconfigured multipart MIME headers—such as incorrect Content-Type order or missing boundary delineation—can disrupt relaxed canonicalization, causing valid emails to fail DKIM checks.
Even with correct DKIM signing, misaligned MIME structure can lead to rejection if the canonicalized header sequence differs from the signed version, especially in SaaS tools with dynamic email generation.

How do multipart MIME headers influence DKIM's c=relaxed canonicalization?

DKIM’s c=relaxed canonicalization allows for minor formatting differences in headers and body content, but inconsistent formatting of multipart MIME headers—like Content-Type or Content-Transfer-Encoding—can cause the verifier to treat them as changes in content. This breaks relaxed canonicalization, leading to signature failures even when the actual message is unchanged. You’ll see this most often in SaaS tools that generate or relay emails dynamically.

Why relaxed mode doesn’t always survive multipart chaos

DKIM's relaxed canonicalization is designed to ignore whitespace, line breaks, and minor header order shifts. But when multipart MIME headers use inconsistent line breaks or encode fields across multiple lines without standard folding, the verifier may interpret that as a content deviation. This is especially common in tool-generated headers where newline handling varies between systems.

For example, a header like Content-Type: multipart/alternative; boundary=--nextpart with a line break after the semicolon can confuse a verifier if the folding is off. Even small formatting quirks—like missing whitespace after a colon or incorrect CRLF use—can trigger strict mode behavior, effectively invalidating the relaxed canonicalization process and causing a failed signature check.

What happens when headers misbehave

When the DKIM verifier sees non-standard MIME header formatting, it may treat the message body as altered, even if the actual content is identical. This is a known issue documented in RFC 6376, which defines DKIM’s canonicalization rules. The relaxed mode only applies when the content structure remains stable; malformed or inconsistent MIME headers disrupt this stability.

Tools using automated email generation—like SaaS platforms handling bulk campaigns or templated messages—are most at risk. Without proper validation of MIME header structure, you’re not just increasing failure rates; you’re undermining your sender reputation. Even if your message passes deliverability checks, a DKIM failure means inbox placement can still drop.

Let’s be clear: this isn’t about the message’s content—it’s about how it’s wrapped. Validating header formatting during email generation or before sending is as important as verifying the email address itself. With tools like MailTester’s email checker, you can catch issues like malformed email structure early, before sending to a list.

What happens when DKIM relaxed canonicalization fails due to MIME structure?

If a multipart MIME message has inconsistent or malformed headers—like mismatched Content-Type boundaries or improperly nested parts—DKIM's relaxed canonicalization can't reconcile the differences during signature verification. The receiving server sees a mismatch between the signed content and the received email, leading to a failed DKIM check. Even if your message is legitimate, this failure often results in the email being flagged as suspicious, rejected, or sent to spam, especially by Gmail, Apple Mail, and Yahoo, which strictly enforce signature alignment.

Why MIME structure matters for DKIM

DKIM uses relaxed canonicalization to ignore minor formatting differences—whitespace, line breaks, or minor header order changes—so long as the message content remains logically unchanged. But the canonicalization process requires the MIME parts to be structured in a way that preserves the intended message flow. If a part is misaligned, duplicated, or contains invalid headers, the digest calculation fails, and the signature verification fails.

For example, if a multipart/alternative message has an HTML part with a missing or malformed Content-Type header, the mail server may not be able to reconstruct the signed content the same way the sending server did. This breaks the integrity check, even if the text is otherwise correct. It’s not about the content itself—it’s about how the data is wrapped and structured.

Failures that go unnoticed

DKIM failures are often silent. If your system doesn't monitor failed signature checks or verify delivery logs, you may never realize the issue. The email appears to send successfully—your server says "sent"—but the receiving server rejects it during post-delivery validation. This leads to unexplained bounces or poor inbox placement, especially on major platforms where DKIM is a key signal in the authenticity chain.

Tools like inbox placement testing can help reveal this gap. By simulating real-world delivery to Gmail, Apple Mail, and Yahoo, you can see if your messages pass strict checks—even if they were sent without obvious errors.

For SaaS platforms that generate automated emails (like product alerts, onboarding messages, or notifications), inconsistent MIME structure can emerge from dynamic template engines. A minor change in how HTML and plain text parts are inserted can break the header alignment. This is why real-time verification and pre-send testing are critical. Bulk verification and API-based checks can spot invalid or malformed addresses, but only a full inbox placement test captures issues like DKIM failure due to MIME flaws.

As defined in RFC 6376, relaxed canonicalization is designed to support real-world email delivery. But when the underlying MIME structure violates expected standards, even correct content fails. This is not a rare edge case—it's a common cause of delivery issues in systems that generate complex emails at scale.

Common MIME formatting pitfalls that break relaxed canonicalization in SaaS systems

Relaxed canonicalization in DKIM relies on consistent, predictable MIME formatting. Even small errors—like inserting line breaks mid-Content-Type, using spaces instead of CRLF, or trailing whitespace after boundaries—can change the hash and cause DKIM verification to fail. These issues are especially common in SaaS email tools that auto-generate messages without careful formatting control. Let’s look at the real culprits.

Line folding and canonicalization sensitivity

Inserting line breaks in the middle of a Content-Type value—like breaking multipart/alternative; boundary="----=_NextPart_000_0001_01D5D239.4E5F3E20" mid-value—breaks relaxed canonicalization. DKIM only allows folding at specific points, and invalid breaks change the canonical form.
Using spaces instead of CRLF for line endings within headers means the message doesn’t conform to SMTP standards. RFC 5322 specifies that line breaks must be CRLF, not just \n or \r.
Trailing spaces or extra newlines after a multipart boundary (like ----=_NextPart_000_0001_01D5D239.4E5F3E20) alter the header's content. Even a single trailing space affects the canonicalized byte stream.

Encoded words and non-ASCII content

Breaking encoded words like =?UTF-8?Q?Subject_with_non-ASCII_characters?= across line boundaries without proper rejoining causes the decoder to fail. Encoded words must remain intact and are not meant to be split.
Using non-ASCII characters (like accented letters or emojis) directly in MIME headers without proper encoding (e.g., =?UTF-8?Q?Caf=C3=A9?=) results in malformed headers. This breaks parsing and can cause DKIM to reject the signature.
Incorrectly placing charset declarations or encoding in the wrong place (e.g., inside Content-Disposition without proper name* syntax) leads to parsing inconsistencies and canonicalization mismatches.

These aren’t just syntax nitpicks—they directly impact DKIM validation. Even small deviations in how headers are formatted can break signed messages in production, especially when sent through SaaS tools that abstract away low-level details. The best fix is to validate message output before sending.

Use an email checker before deploying high-volume campaigns. Test header consistency with tools that inspect raw MIME output. For teams using SaaS platforms, ensure you’re auditing the generated MIME structure—not just the visible content.

Verify individual addresses to catch format issues early. For bulk list validation, run a full verification to identify malformed or risky sends before they hit your email provider.

How SaaS email platforms typically handle MIME and DKIM canonicalization

Most SaaS email platforms auto-generate MIME structures during composition and apply DKIM relaxed canonicalization by default, which helps maintain signatures across minor header changes. However, this can break if custom templates or third-party integrations rewrite headers without preserving MIME integrity, especially when template engines inject malformed parts. A single misformatted MIME part can cause DKIM verification to fail, even if the email renders correctly in inboxes.

Auto-generated MIME and relaxed canonicalization

When you compose an email in tools like SendGrid, Mailchimp, or HubSpot, the platform builds the MIME structure automatically—splitting content into parts, setting content types, and managing boundaries. This is efficient but opaque: you rarely see the raw MIME structure, and modifications via code or templates can introduce subtle inconsistencies. DKIM, in turn, uses relaxed canonicalization for headers by default, which allows small variations in whitespace, capitalization, or ordering, making signatures more resilient across delivery hops.

While relaxed canonicalization helps with transit stability, it’s not a cure-all. If the underlying MIME structure is malformed—say, a missing boundary or incorrectly nested parts—the DKIM signature, even if computed correctly, will fail verification at the receiving end. This is a common failure point when using dynamic content systems that generate email parts without validating MIME correctness.

Where problems emerge: custom logic and integration quirks

Let’s say you’re using a template engine like Handlebars or Liquid to dynamically inject content into an email. These tools don’t enforce MIME rules—they just output strings. If you accidentally merge two parts into one, omit a required header, or use an invalid Content-Type, the resulting MIME becomes invalid. Even if the final email looks fine to a human, the DKIM signature will fail because the receiving server validates the canonicalized version against the expected structure.

Many SaaS platforms don’t validate MIME before signing. This means a signature can be applied to a malformed structure, rendering it useless. The issue isn’t always the signing tool—it’s the lack of pre-signature validation. This is especially problematic when integrating with third-party APIs that rewrite or inject content after the initial DKIM signature is applied.

It’s worth noting that the RFC 6376 section on DKIM canonicalization explicitly allows relaxed header handling but doesn't excuse malformed body structures. As such, a clean MIME structure is foundational—no matter how robust the canonicalization.

If you're building or managing email flows, validating MIME structure before signing is a critical step. Tools like MailTester’s email checker can help identify common issues, including malformed MIME patterns, before sending.

Step-by-step: How to verify if your SaaS email’s MIME structure is DKIM-safe

You can confirm your SaaS email’s MIME structure is DKIM-safe by exporting the raw message, verifying multipart boundaries are valid and unbroken, ensuring headers follow RFC 2046 with CRLF line endings, and testing the DKIM signature against your domain’s public key. If it fails, compare the canonicalized headers to isolate MIME-level issues. This ensures your email’s integrity survives transit and authentication.

Export and parse the raw email

Use your SaaS platform’s debug mode or delivery logs to export the full raw email — both headers and body. This includes all MIME structure, including the Content-Type header with its boundary token.
Look for the Content-Type: multipart/alternative; boundary="----=_NextPart_000_0123_ABCD" line. The boundary must be a single, unbroken string without line breaks, spaces, or special characters that could be misinterpreted during canonicalization.
Verify the boundary appears only once per part and is properly prefixed with ----= and suffixed with _. Malformed boundaries are common in SaaS tools that auto-generate content, especially when content includes raw HTML or nested attachments.

Validate MIME structure and test DKIM

Check that every MIME header — including Content-Type, Content-Transfer-Encoding, and Content-Disposition — follows RFC 2046 and uses CRLF (\r\n) line endings, not LF or inconsistent line breaks. Even a single LF can trigger canonicalization mismatches.
Use a trusted DKIM validator like MXToolbox’s DKIM check to input the full raw email and test it against your domain’s public key. This will reveal whether the signature passes or fails.
If the signature fails, compare the original headers to the canonicalized version the validator applied. The difference will often expose how a malformed boundary, missing CRLF, or invalid header format disrupted the relaxed header canonicalization process.
Once you’ve identified the issue — such as a line break inside the boundary token or missing \r\n — correct it in your SaaS’s email template or sending pipeline. Test again.

Even minor formatting errors in MIME headers can prevent DKIM from verifying, leading to reduced inbox placement or outright rejection. Tools like MailTester’s email checker can help identify malformed structures early by validating individual addresses and revealing common formatting red flags before you send.

The 3 steps described in “Export and parse the raw email”, in order.

You can’t catch DKIM signature failures caused by subtle MIME header issues—like incorrect header folding, invalid encoding, or inconsistent boundary markers—unless you test the actual email structure before sending. Tools like MailTester’s real-time verification API and inbox-placement testers scan the full MIME payload, flagging broken signatures early, even when sender-side logs remain silent. This prevents bounces, improves inbox placement, and reduces sender reputation risk before emails ever leave your system.

How MIME structure breaks DKIM in practice

Digital signatures in email rely on canonicalization—standardizing how content is processed before signing. DKIM uses c=relaxed, which tolerates minor formatting differences, but only up to a point. When header lines are folded incorrectly, or when MIME boundaries are malformed, even relaxed canonicalization fails to reconstruct the original signing digest.

For example, a single incorrect line break in a header field like Content-Type or Subject can alter the canonicalized body and break the DKIM signature. These are hard to detect manually, especially in bulk emails, because the same email may pass locally but fail in transit due to how different MTAs handle folding and whitespace.

MailTester catches what logs miss

MailTester doesn’t rely on your server’s logs or on sender-side assumptions. It validates the actual MIME structure as it would be delivered—testing both the header and body integrity across all layers.

Our system checks for known failure points: folded headers that don’t follow RFC 2822 section 2.2.3 rules, base64 or quoted-printable encoding mismatches, and boundary inconsistencies in multipart emails—common culprits in DKIM validation failures.

Using the real-time verification API or inbox placement testing, you can identify and fix these issues before sending. With 98.9% accuracy, MailTester detects invalid or inconsistent MIME headers early, helping reduce bounce rates and maintain sender reputation—especially when sending at scale through SaaS tools where email formatting is often automated.

Let’s say you generate a newsletter with a template. A small formatting glitch in a nested multipart MIME block might not matter for your internal preview, but it can cause DKIM to fail with ISPs like Gmail or Outlook. MailTester spots it before you send it to 100,000 recipients.

How to integrate MailTester to catch MIME and DKIM compatibility issues before deployment

Use the MailTester API to test email templates during staging, connect it to your SaaS platform via integrations with SendGrid, Mailchimp, Klaviyo, or HubSpot, and run inbox-placement tests to catch MIME-related DKIM validation failures before sending. A 'risky' verdict from MailTester often highlights malformed headers or signature mismatches due to relaxed canonicalization errors in MIME structures.

Start with verification during campaign staging

Use the MailTester API to validate individual addresses or bulk lists before campaign launch. This catches malformed MIME structures early—especially when headers like Content-Type or Subject are improperly encoded, which can break DKIM c=relaxed canonicalization.
Integrate MailTester directly into your SaaS workflow through native connections to SendGrid, Mailchimp, Klaviyo, or HubSpot. This automates pre-send checks on every template, ensuring that even minor MIME header inconsistencies—like line breaks in From: or To: fields—are flagged before they affect deliverability.
Run inbox-placement tests using MailTester’s inbox tester to simulate real-world delivery. If an email fails to land in the inbox due to DKIM signature rejection, it’s likely due to a MIME header not aligned with relaxed canonicalization standards. Check the report to see if headers were altered during transmission.
Review the verification verdicts in the response: valid (clean), invalid (format or domain error), catch-all (not useful for targeting), or risky. A risky result points directly to structural issues—such as inconsistent MIME encoding or improperly formatted headers—that trigger DKIM signature validation failures when c=relaxed is applied.
Correct the template or configuration based on the test output. For example, fix line folding in header fields, ensure consistent character encoding, or sanitize embedded content. Revalidate using the same API or integration to confirm the change resolved the issue.

Why MIME and canonicalization matter

MIME headers in SaaS emails are often auto-generated, but subtle differences in encoding or line breaks can affect DKIM’s relaxed canonicalization. The DKIM specification (RFC 6376) defines how headers are normalized before signing—small deviations cause signature mismatches. Tools like MailTester detect these at scale, preventing bounces or spam filtering.

For deeper context on how email header standards affect delivery, refer to the DKIM spec (RFC 6376) or industry analysis from platforms like Return Path, which note that malformed headers are among the top causes of signature validation failure in production email streams.

What each verification verdict means in the context of MIME and DKIM

You’re checking if an email address is deliverable, and the verdicts—Valid, Invalid, Catch-all, or Risky—tell you exactly how its MIME structure and DKIM relaxed canonicalization are behaving. A Valid result means both the email’s MIME is intact and DKIM passes under relaxed canonicalization. Invalid usually points to malformed headers or encoding issues that break DKIM. Catch-all means the domain accepts all addresses, but that doesn’t guarantee inbox delivery—especially if MIME is broken. Risky indicates near-threshold formatting issues, like inconsistent line folding, which can still trip up strict filtering. These verdicts aren't just labels—they’re diagnostics for deliverability.

MIME structure and DKIM relaxed canonicalization: how each verdict reflects real-world behavior

Let’s break down what each verdict really means when you're working with SaaS email tools and sending at scale.

Verdict	MIME & Header Status	Degree of DKIM Match (relaxed canonicalization)	Deliverability Implication
Valid	Proper MIME structure. Headers correctly formatted, encoding (like UTF-8) applied, and line length consistent. No malformed sections or missing boundary delimiters.	Certifies that the header and body signatures, after relaxed canonicalization, match the original signed data exactly.	Good signal. Likely to pass filtering and reach inbox, assuming sender reputation is clean. Use for high-intent campaigns.
Invalid	Malformed MIME: missing headers, incorrect Content-Type, broken base64 encoding, or invalid line folding. Often seen in automated or malformed user-generated content.	DKIM signature validation fails. Even under relaxed canonicalization, the transformed header or body diverges from signed content.	Rejects at the SMTP or filtering stage. These addresses should be removed from your list. You can test individual entries with MailTester’s email checker.
Catch-all	MIME may be valid, but the domain accepts all emails—no per-address validation. This is not an indication of deliverability.	DKIM can pass if the signature was created with valid data, but the domain’s handling often leads to rejection later.	High bounce risk. Many ESPs reject messages to catch-all domains or mark them as spam. Avoid sending to these without further validation.
Risky	Format is technically valid but near failure. Common causes: inconsistent line lengths, extra whitespace, or non-standard MIME line folds that deviate slightly from RFC 2822.	DKIM can pass under relaxed canonicalization, but only if the variations are minor. Larger deviations fail.	Subject to filtering. Some mail servers are stricter on formatting. Monitor performance through inbox placement testing before sending at scale.

Relaxed canonicalization in DKIM is designed to tolerate minor variations in whitespace and line breaks, but it’s not a fix for fundamentally broken MIME. For example, the DKIM specification defines relaxed canonicalization to normalize whitespace, but it cannot correct missing headers or malformed boundaries. That’s why you can’t rely solely on DKIM passing if the MIME structure is broken.

If you’re managing email sends at scale, validating both MIME integrity and DKIM alignment is essential. Tools like MailTester test for both—checking whether the MIME is structured properly and whether the DKIM signature remains valid after relaxed canonicalization. With bulk verification, you can process thousands of addresses quickly, filtering out Invalid and Risky entries before sending—reducing bounces and protecting sender reputation.

You can prevent DKIM signature failures caused by improper MIME formatting by ensuring line endings are CRLF, not LF; avoiding line breaks in Content-Type or boundary tokens; using proper MIME encoding for non-ASCII text; validating emails before sending with a real-time tool; and monitoring inbox placement and DKIM logs. These steps directly address the root of canonicalization mismatches in relaxed mode.

MIME Structure: What to Check Before Sending

Use CRLF (\r\n) exclusively for line endings in header fields — LF-only line endings are a common source of DKIM signature failures, especially in systems that process headers strictly.
Never break Content-Type or boundary tokens across lines. Even a single soft line break in these tokens during canonicalization can cause a DKIM validation mismatch.
Encode any non-ASCII characters using proper MIME encoding, such as =?UTF-8?Q?... for quoted-printable or =?UTF-8?B?... for base64. Unencoded Unicode in headers or bodies breaks MIME parsing and can disrupt DKIM canonicalization.
Run every email through a real-time verification tool like MailTester’s email checker before sending to catch formatting errors that might otherwise pass validation but fail delivery.

Delivery and Validation Post-Send

Monitor DKIM validation logs from your email provider or a third-party service. Many SaaS platforms log DKIM status per message — if you see “signature validation failed,” examine the MIME structure for non-compliance.
Use inbox placement testing to see how your email renders in real inboxes. Tools like MailTester’s inbox tester simulate delivery across multiple providers and expose rendering quirks that may otherwise be missed.
Verify that your SaaS system isn’t injecting unexpected whitespace or modifying headers during transmission. Even minor changes during forwarding or API processing can disrupt MIME integrity.
Reference RFC 2047 for how non-ASCII characters in headers should be encoded. This standard is the foundation for MIME-compatible text handling.
Check the behavior of RFC 6376 for relaxed canonicalization — it explicitly allows some whitespace normalization, but not when boundary tokens or content types are malformed.

DKIM signatures are only as strong as the consistency of the raw email data. Small MIME deviations break the validation chain — especially in relaxed mode where the verifier expects predictable line handling.

Conclusion: MIME accuracy is part of DKIM reliability in SaaS email systems

Even minor inconsistencies in multipart MIME headers—like incorrect boundary delimiters or misordered parts—can disrupt DKIM’s relaxed canonicalization process, causing signature validation to fail.

When DKIM fails, messages may be rejected, marked as spam, or deprioritized by inbox providers, all of which harm deliverability and erode sender reputation over time.

Tools like MailTester detect these subtle MIME-level issues early, using high-accuracy verification to prevent delivery problems before they impact your campaigns.

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

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 relaxed canonicalization?

Relaxed canonicalization allows minor, non-content changes—such as whitespace or line breaks—to be ignored during DKIM signature validation, ensuring emails remain valid despite standard MIME formatting tweaks.

Why does MIME header structure affect DKIM signing?

DKIM signs the canonicalized form of headers. If MIME headers are inconsistently formatted—like broken line folding—it changes the canonical form, causing signature failure.

Can a well-designed email still fail DKIM with relaxed canonicalization?

Yes. If MIME headers deviate from standard formats—e.g., improper boundary tokens—they may still break relaxed canonicalization, even if the message content is unchanged.

MailTester validates the raw MIME structure of emails and checks for canonicalization mismatches during verification, returning a 'risky' or 'invalid' verdict when issues are found.

Do all SaaS email tools handle MIME formatting correctly?

Most do by default, but issues arise with custom templates, integrations, or manual code injection that bypass built-in validation.

Is DKIM canonicalization affected by email content, not just headers?

Only if the content is modified during transit. But in relaxed mode, small content changes like whitespace or line breaks are ignored—unless headers are malformed.

How can I test if my email’s MIME structure is correct?

Export the raw email and validate it using tools like mxtoolbox.com/dkim or MailTester’s API. Check for correct line endings, header folding, and boundary formatting.

What happens when DKIM fails due to MIME structure?

The receiving server may reject the email or flag it as suspicious, leading to poor inbox placement or outright delivery failure.

Can relaxed canonicalization be disabled?

Yes, but it’s not recommended. Disabling relaxed mode increases the chance of valid emails failing due to minor formatting changes.

Why use MailTester instead of built-in SaaS tools?

Built-in tools may not expose subtle MIME or DKIM issues. MailTester offers independent, high-accuracy verification across real ISP environments.

Does MailTester support bulk testing for MIME and DKIM issues?

Yes—its bulk verification feature lets you test large email lists for structural issues, including inconsistent MIME formatting and DKIM validation failures.

How often should I verify emails using MailTester?

Before major campaigns, after template changes, or when deliverability drops. Even one test per month can prevent reputation damage.