Fix DKIM Failures from Mixed Encoding

Why does DKIM fail when your multipart/alternative message uses mixed encoding?

You send a clean, well-structured email — plain text and HTML versions both look right. The DKIM signature passes on your test server, but the recipient’s inbox rejects it. Why?

It’s not the content. It’s not the domain. The issue often hides in the small details: line breaks, character encoding, and how the message body is canonicalized before signing.

DKIM signatures are calculated on a standardized version of your message body — not the raw transmission. If the plain-text part uses LF line endings and the HTML part uses CRLF, or if one is UTF-8 and the other ISO-8859-1, the canonicalized body diverges from the real one. Even tiny differences break the signature match.

The result? A valid message fails authentication. Your sender reputation suffers. Email delivery drops — silently, without clear warning.

This isn’t a problem with your domain, your DNS, or your email service. It’s a systemic issue in how multipart/alternative messages are built. Fixing it requires understanding how DKIM canonicalizes content—and how encoding inconsistencies cause signature failure.

Key takeaways

DKIM signatures depend on a standardized body representation, not the transmitted content directly.
Mixing line-ending styles (CRLF vs LF) or character encodings (UTF-8 vs ISO-8859-1) between plain-text and HTML parts causes canonicalization mismatches.
Even identical content with inconsistent formatting can result in signature verification failure, lowering deliverability.

What happens when DKIM fails due to encoding inconsistency?

When a DKIM signature fails because of mixed encoding in multipart/alternative emails, the message is treated as unauthenticated by receiving servers, undermining trust and increasing the likelihood of being filtered into junk folders or outright blocked. This failure isn’t just cosmetic—it can trigger long-term reputational penalties, especially if the same issue repeats across many emails or domains, making your sending IP appear inconsistent or compromised.

Impact on deliverability and sender reputation

Receiving servers use DKIM validation as part of their authentication stack. When the signature fails due to inconsistent encoding—like having one part in UTF-8 and another in ISO-8859-1—the cryptographic hash generated during signing no longer matches the one computed on the receiving end. This mismatch is flagged as a violation, even if the message content is legitimate.

Over time, repeated DKIM failures, especially across multiple domains or IPs, can lead to reputational damage. ISPs and filtering services may interpret this as a sign of poor sender hygiene or even malicious intent. Some use statistical models to assess sender behavior: a consistent drop in authentication success rates correlates with higher spam risk, even if the content is clean.

Why it might be mistaken for spoofing or policy abuse

If your DKIM failures are inconsistent—happening only on certain email types (e.g., multipart/alternative messages with mixed encodings) but not others—it might raise suspicion that your infrastructure is compromised. Attackers often exploit encoding inconsistencies to bypass filters or hide malicious payloads.

Additionally, if DKIM failures occur across multiple domains or IPs without a clear root cause, some email gateways may apply blanket filters or throttle delivery. This is especially true in high-volume sending environments where pattern recognition tools flag anomalies. A single misconfigured email client or automated system sending out messages with inconsistent encoding can trigger automated responses that are hard to reverse without deep analysis.

Even minor encoding mismatches in multipart/alternative messages—such as using quoted-printable in one part and base64 in another—can break DKIM if not handled consistently during signing. The DMARC policy relies on successful SPF, DKIM, and alignment checks; failures in any one of these can lead to rejection or quarantine.

It’s worth noting that this isn’t unique to any single provider—it’s a known challenge in SMTP and MIME standards, as highlighted in RFC 822 and later updates like RFC 2045, which define content transfer encoding rules. Ensuring consistent encoding across both HTML and plain-text parts is a basic requirement for reliable authentication.

If you’re sending email at scale, validating both the technical structure and the authentication setup of your messages is essential. You can check for encoding inconsistencies and other deliverability red flags across your list using a tool like MailTester’s bulk email verification, which includes checks for technical issues that impact authentication.

How does multipart/alternative work under the hood?

When you send an email with both plain-text and HTML versions, your mail client packages them as a multipart/alternative message. Each version is wrapped as a separate part, each with its own Content-Type header specifying the subtype, and the full body is reassembled in order during delivery. Crucially, the entire message—including both parts—is canonicalized (normalized) before DKIM signing, so any encoding inconsistency, including mixed character encoding or improper line endings, breaks the signature.

Why character encoding matters in DKIM signing

Even if both parts of your multipart/alternative message claim to use charset=UTF-8, subtle differences in how the content is encoded—especially during line wrapping or character normalization—can change the final byte stream. Since DKIM signs the exact byte sequence, any deviation between what was signed and what arrived at the receiving server results in a signature failure.

For example, a line break encoded as CRLF (\r\n) in one part and LF (\n) in another may seem minor, but it alters the canonicalized body. Similarly, if one part uses a Unicode character with a precomposed form and another uses a decomposed form, the resulting hash differs, invalidating the signature. The DKIM specification mandates strict normalization, so all such variations must be avoided.

How MailTester helps catch these issues early

When you verify a list of email addresses using MailTester’s bulk verification, it doesn’t just check syntax or inbox health—it evaluates the full composition of your message, including MIME structure and encoding consistency. This helps uncover hidden issues like mixed line endings or inconsistent charset handling before you send, reducing the risk of DKIM failures.

If you're integrating with tools like SendGrid, Klaviyo, or HubSpot, MailTester’s integrations can validate your outgoing message templates directly in your workflow. The service checks whether your multipart/alternative bodies are properly structured and canonicalized. For real-time checks, use the email verification API to test one address at a time, seeing not just deliverability signals but structural integrity down to the MIME level.

What encoding mismatches commonly break DKIM signatures?

DKIM signatures rely on consistent, predictable message structure. Even small inconsistencies in line endings, character encoding, or transfer encoding across HTML and plain-text parts can alter the canonical form used for signing, causing verification to fail. You must ensure uniformity in how the message is serialized, especially across multipart/alternative boundaries.

Common encoding mismatches that break DKIM

Using CRLF (Windows-style) in one part and LF (Unix-style) in another — DKIM canonicalization treats these differently, leading to signature mismatches.
Mixing character encodings like UTF-8 in the HTML part and Latin1 (ISO-8859-1) in the plain-text part. The same non-ASCII character may decode differently, breaking the signature’s consistency.
Placing non-ASCII characters in one part (like an accent in the plain-text body) without proper escaping or declaring the same charset in the other part. This alters the byte stream seen by the DKIM verifier.
Applying different Content-Transfer-Encoding values — e.g., quoted-printable in HTML and base64 in plain text. If the signing process isn't aware of the difference, the canonicalized body will change unexpectedly.
Inconsistently handling whitespace or newlines within body content, especially when using quoted-printable encoding, where line folding rules vary.

Why this matters for deliverability

DKIM is a cornerstone of sender reputation. A failed signature doesn’t always mean spam — it often means a technical mismatch in your message build process. Even if the email reaches the inbox, a signature failure can trigger filters that lower your sender score over time.

According to the DKIM specification, the canonicalization process must reproduce the same output every time. Inconsistent encoding breaks this, leading to unpredictable signature results.

Let’s say you use a modern email platform with automated templating. If one part uses UTF-8 and another uses a legacy encoding, even with proper headers, the signature won’t match. Tools like MailTester's bulk verification can help catch problematic email addresses before they go out — including those from domains that might be more sensitive to such issues.

Use consistent settings across all message parts. Always specify the same charset and transfer encoding in headers, and validate the final message structure before sending. This is not about theory: it’s about making sure every byte matches the canonical form that was signed.

How to verify your multipart/alternative messages don't break DKIM

DKIM signatures fail when your multipart/alternative email uses mixed character encodings or inconsistent line endings—even small differences in how text is formatted can break the cryptographic hash. To prevent this, validate that all parts of your email use the same encoding (prefer UTF-8), consistent line endings (CRLF), and test the final message structure with a real-time email verification tool that supports full message parsing. This catches encoding mismatch errors before they trigger rejection.

Test your message before sending

Use a real-time email verification service like MailTester’s bulk verification to inspect full message structure—including encoding and line ending consistency—before sending to large lists.
Ensure every part of your multipart/alternative message (HTML and plain text) uses the same character encoding; UTF-8 is the industry standard and minimizes parsing errors.
Confirm all line endings are consistent: SMTP requires CRLF, but even when sent correctly, mixed line endings (e.g., LF in one part, CRLF in another) can break DKIM.
Extract the raw message (including headers and body) and validate it with a known DKIM validation tool like MXToolbox’s DKIM debugger—this simulates how receiving servers process your email.

Verify the rendered output

Always test the final rendered message—what gets sent—not just the source code. DKIM signs the entire message body as sent, so inconsistencies only appear in the delivery context.
Check for encoding corruption by comparing the raw message output against a known valid email with similar content, especially when transforming from one format to another (e.g., HTML to plain text).
When using email templates, avoid inline encoding differences; ensure your templating engine emits consistent CRLF and UTF-8 across all outputs.
Use MailTester’s API in your pipeline to catch encoding and structure issues in real time when sending single or small batches.

DKIM is sensitive to any change in the message body. Even a single misencoded character or line ending deviation can invalidate the signature.

Remember: DKIM doesn’t care about the content—only the exact byte sequence. If the server receiving your message sees something different than the sender signed, the signature fails. Testing the final product, not the draft, is the only reliable way to avoid failure.

What does MailTester do to catch DKIM failures before they happen?

You can catch DKIM signature failures caused by mixed encoding in multipart/alternative messages before they happen by testing the raw structure of your email. MailTester parses the full message, checks for inconsistent encoding across parts, and simulates real-world server processing—including body canonicalization—to spot mismatches that break authentication. This prevents bounces and spam folder placement issues before you send.

Full message parsing catches encoding issues early

When you send an email with both HTML and plain-text versions, each part must use consistent encoding. If one uses UTF-8 and the other uses ISO-8859-1, the DKIM signature can fail during verification—even if the content looks correct to humans. MailTester’s inbox-placement testing includes full message parsing to detect these inconsistencies before they cause real-world delivery problems.

It doesn’t just look at the headers. It examines how each part is encoded, whether line breaks are standardized, and if whitespace or encoding translations alter the body content. A mismatch here breaks DKIM because the receiving server computes a different hash than the one sent. This is why the DKIM RFC specifies strict rules about canonicalization.

Real-time checks prevent authentication failures in production

Using the real-time email verification API, you can validate messages before sending—especially when integrating with bulk email or transactional systems. The API checks for improper body canonicalization, detects mixed encoding in multipart/alternative payloads, and flags potential DKIM failures based on real server behavior.

MailTester doesn’t just say “valid” or “invalid”—it simulates how Gmail, Outlook, and Yahoo process the same message, comparing the expected hash against the signed one. If the canonicalized body differs between your signing process and their processing, it flags the message as a candidate for failure.

With 98.9% accuracy in real-world testing across major providers, MailTester identifies issues that would otherwise go unnoticed until after sending. This isn’t just about avoiding bounces—it’s about maintaining sender reputation and inbox placement. You’re not just checking an address. You’re verifying the entire delivery chain.

A step-by-step process to fix mixed encoding in multipart/alternative messages

You fix DKIM signature failures from mixed encoding by extracting the raw message, ensuring every part uses UTF-8, standardizing line endings to CRLF, rebuilding with consistent boundaries, and validating the result with a DKIM canonicalization tool or a public verifier like dkimvalidator.com. This ensures the signature aligns with what the receiving server expects.

Identify and extract the raw message

Use a debugging tool like swaks or your email service’s API output to retrieve the raw message, including headers and body.
Ensure you capture the full MIME structure, as multipart/alternative messages contain separate parts for text/plain and text/html.

Inspect and standardize encoding across parts

Open each part of the message and check the Content-Type header for charset declarations. Look for inconsistencies like charset=iso-8859-1 alongside charset=utf-8.
Convert all parts to UTF-8. This is the industry-standard encoding and reduces the risk of misinterpretation during DKIM canonicalization.
Verify that all line endings are CRLF (\r\n), even in headers—this is required by RFC 5322 and commonly overlooked in script-generated emails.
Ensure both text/plain and text/html parts use the same encoding. Mixed encodings cause DKIM to fail because the canonicalized body doesn’t match the signed version.

Rebuild and validate the message

Reconstruct the message using a consistent boundary separator (e.g., ----=_Part_12345_67890) that doesn’t appear in the content. Avoid default boundaries that vary by tool or library.
Before sending, validate the structure using a DKIM canonicalization tool. The DKIM specification (RFC 6376) defines how headers and body are standardized—use a tool to simulate this step.
Test the rebuilt message by sending it through MailTester’s inbox placement test to confirm DKIM passes and the message lands in the inbox.
Alternatively, validate the final DKIM signature using dkimvalidator.com with the full raw message and public key.

Even small inconsistencies in line endings or character encoding can cause DKIM to fail, even if the rest of the message is correct. A single \n instead of \r\n in a header can invalidate the signature during canonicalization.

How MailTester’s in-app AI assistant helps debug DKIM issues

You can’t fix a DKIM signature failure if you don’t know the root cause — and mixed encoding in multipart/alternative messages is a common but hard-to-spot trigger. MailTester’s in-app AI assistant analyzes your raw message, detects discrepancies in line endings or character encoding across parts, and flags the exact spots where the signature breaks. It doesn’t just detect the problem — it tells you how to fix it, with context and precision.

Spotting encoding mismatches that break DKIM

DKIM signing relies on a consistent, predictable format. When one part of a multipart/alternative email uses UTF-8 with Unix line endings (LF) and another uses ISO-8859-1 with Windows line endings (CRLF), the signed body hash doesn’t match the received content. The AI assistant scans the full message body, compares the encoding and line endings across each part, and highlights the mismatch in real time. You’ll see exactly which section deviates from the norm.

This level of detail matters because even minor inconsistencies can invalidate the signature. RFC 5322 defines the structure of email messages, and compliance with its formatting rules is essential. Tools like MxToolbox or Spamhaus validate delivery, but only a deep inspection reveals encoding-level issues that break DKIM. The AI assistant helps you stay aligned with these standards without requiring deep protocol expertise.

Real-time fixes and integration support

Once it identifies the issue, the AI assistant suggests specific corrections. For example, it may recommend converting all line breaks to CRLF and ensuring every part uses UTF-8 encoding. These are not generic tips — they’re tailored to your message’s exact structure and content.

You can apply these fixes directly in the tool and retest the signature before sending. If you're building campaigns in SendGrid, Mailchimp, or HubSpot, the assistant can guide you to apply the changes in the platform’s editor or template builder. This is especially useful when automating messages — catching these errors before they reach users avoids costly bounces and inbox placement drops.

With MailTester’s in-app AI, you’re not just checking for validity — you’re debugging the underlying cause of delivery failure. It’s like having a protocol-savvy teammate reviewing every email before it leaves your system. You can explore how it works with your list: verify bulk lists with AI-powered insights.

Why relying solely on SPF and DMARC won't prevent DKIM failures

You can pass SPF and DMARC checks while still failing DKIM — because SPF validates sender IP legitimacy and DMARC enforces policy when either SPF or DKIM fails, but neither inspects message content, encoding, or how multipart/alternative bodies are constructed. A malformed or inconsistently encoded message body can break DKIM signing even when authentication headers are correct.

SPF and DMARC don't inspect message content

SPF confirms the sending server's IP is authorized. DMARC defines what happens when SPF or DKIM fails — for example, whether to quarantine or reject the message. But neither protocol examines the body of the email, including how multipart/alternative parts are encoded or ordered.

Because DKIM signs the message body (including headers and content), any inconsistency in how the body is structured — like mixing UTF-8 and ISO-8859-1 encodings in different parts, or using incorrect MIME delimiters — can result in a signature mismatch, even if the sending IP is valid and DMARC policies are met.

DKIM signing is fragile to content inconsistencies

Multimedia emails often use multiple parts: plain text, HTML, and sometimes attachments. When constructing these in a multipart/alternative format, small encoding mismatches — such as a missing charset declaration or inconsistent line endings — can invalidate the DKIM signature.

Receiving servers check DKIM signatures as part of deliverability. If the signature fails, even with valid SPF and DMARC, the message may be marked as suspicious, routed to spam, or outright rejected. This is common with automated email tools that mishandle encoding during message assembly.

Even well-intentioned mail systems can cause issues. A message that looks correct in a testing tool may fail in practice due to subtle formatting differences that only appear in real-world delivery — especially in bulk or transactional workflows.

Check your message construction pipeline. Ensure all parts are consistently encoded and follow MIME best practices. Refer to RFC 2046 for structure guidelines and RFC 2183 for header handling.

Leverage tools that validate both structure and authentication. For example, MailTester’s inbox placement tool simulates real-world inbox behavior, including DKIM validation, across major inboxes — giving you early visibility into issues before sending to real users.

How to maintain consistent encoding across all outbound emails

You fix DKIM signature failures from mixed encoding by ensuring all parts of your multipart/alternative emails use UTF-8 and CRLF consistently. This includes template engines, content rendering, and outbound transports. Validate messages before large sends, monitor delivery reports for repeat failures, and automate checks with tools like MailTester's API.

Enforce consistency at the source

Use a template engine that defaults to UTF-8 encoding and CRLF line endings—avoid ones that let you mix encodings across parts.
Validate all email content before rendering: ensure HTML and plain-text versions use the same character set and line endings.
Check your email system’s configuration to prevent automatic line wrapping or encoding conversion during transit.

Prevent failures before they happen

Run bulk email list verification via MailTester’s bulk verification to identify and clean problematic addresses before sending.
Test your message structure using the MailTester API in real time before deploying large campaigns.
Monitor bounce logs and delivery reports for DKIM failures—even when SPF and DMARC pass, they can signal encoding mismatches in message bodies.
Integrate automated pre-send validation into your workflow. This catches encoding issues before they hit the inbox.
Use email delivery tools that let you simulate message structure and verify signatures end-to-end, like MailTester’s inbox placement testing.

DKIM relies on perfect message parity. Even a single byte difference—like a missing CRLF or a shifted UTF-8 byte sequence—breaks the signature. The best practice is to assume no part of the outbound email chain is immune to encoding quirks. RFC 5322 (the core SMTP standard) defines message syntax, including line endings, and RFC 6376 covers DKIM’s technical requirements.

A well-formed MIME message must have consistent line endings and encoding across all parts. Inconsistencies break the cryptographic digest.

When DKIM fails despite valid SPF and DMARC, the root cause is often in the message body’s encoding—especially for multipart/alternative content where HTML and plain-text versions don’t agree. It’s not always obvious during review. Automated validation is the only reliable way to catch it at scale.

Let’s be clear: you can’t rely on email clients or ISPs to fix encoding mismatches. You are responsible for consistency from the moment content leaves your system. Use tools that validate the message body and signature together.

Summary: Fix DKIM failures by standardizing encoding in multipart messages

Dkim signatures fail when multipart/alternative messages use mixed character encodings or inconsistent line endings. The signature remains valid, but canonicalization produces a mismatch between the signed body and the transmitted body.

The fix is in the message structure, not the signature

Ensure that all parts of a multipart/alternative message use the same encoding—UTF-8—and consistent line endings (CRLF). This alignment prevents canonicalization discrepancies that invalidate the DKIM signature, even if the cryptographic signature itself is correct.

Use UTF-8 for all text parts.
Standardize line endings to CRLF (carriage return + line feed).
Validate the full message structure before sending.
Test deliverability in real-world inbox conditions.

MailTester’s 98.9% accurate verification identifies encoding mismatches and other structural flaws that trigger DKIM failures before they reach the inbox.

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

Can mixed encoding cause a DKIM signature to fail even if the content looks identical?

Yes. Even if email content appears the same, differences in line endings or character encoding alter the canonicalized body. This mismatch breaks DKIM validation.

Does using only UTF-8 prevent DKIM failures?

Using UTF-8 helps, but doesn’t guarantee success. Line ending consistency (CRLF) and content formatting must also be uniform across all parts.

How can I detect encoding mismatches in my email templates?

Test the raw message body using MailTester’s inbox-placement test or a DKIM validator. Look for discrepancies between parts in line endings or charset declarations.

Is CRLF or LF better for DKIM consistency?

CRLF is the standard in SMTP and recommended for consistency. Use the same line ending across all parts to prevent canonicalization errors.

Can MailTester detect DKIM failures caused by encoding issues?

Yes. MailTester’s real-time verification and inbox-placement testing analyze the raw message structure and flag encoding inconsistencies that cause DKIM failure.

Why do some emails pass SPF and DMARC but still fail DKIM?

SPF and DMARC validate different aspects (sender IP and policy enforcement). DKIM validates the message body signature, which can fail due to encoding inconsistency.

Do all email providers check DKIM signature consistency the same way?

Most major providers (Gmail, Outlook, Yahoo) follow the same RFCs, but some apply stricter canonicalization rules. Testing with MailTester simulates real-world conditions.

Can I use MailTester to test one message before sending it?

Yes. MailTester’s real-time API and inbox-placement test allow you to validate a single message before delivery, ensuring DKIM and other headers are correct.

Do DKIM failures affect sender reputation over time?

Yes. Repeated DKIM failures, even small ones, can be flagged as suspicious behavior, lowering sender reputation and increasing the risk of filtering.

What’s the role of the 'in-app AI assistant' in fixing DKIM issues?

The AI analyzes the raw message body, detects encoding mismatches between parts, and suggests fixes such as standardizing charset or line endings.

How does MailTester’s 98.9% accuracy apply to detecting DKIM issues?

It reflects the overall accuracy in identifying email address validity and deliverability risks. When combined with inbox-placement testing, it reliably identifies structural flaws like encoding mismatches.

Do I need to renew MailTester credits every month?

No. Purchased credits never expire, so you can use them when needed, even months later. Start with 100 free verifications.