DKIM Canonicalization & Non-ASCII Characters

Why does a single non-ASCII character break DKIM authentication?

You send a perfectly valid email—text, formatting, content, all correct. But the recipient never sees it. The bounce comes back: “DKIM signature verification failed.” You check the logs, and the culprit? One emoji. Or an accented letter. Or a Unicode symbol from a language you didn’t expect.

DKIM signs the message body using strict canonicalization rules. When non-ASCII characters appear, and the canonicalization process alters how those characters are encoded, the hash changes. Even if the message looks right to you, the server recalculates the hash based on the canonical form, which may strip, alter, or misrepresent non-ASCII content. The result? A mismatch between signed and verified hash — signature fails.

Key takeaways

DKIM canonicalization must preserve the exact byte representation of non-ASCII content in the message body to ensure valid signature verification.
Improper handling of Unicode characters during canonicalization can alter the content hash, causing DKIM signatures to fail even with valid content.
Receivers enforcing strict DKIM checks may silently drop emails with canonicalization mismatches, even if the message is otherwise legitimate and delivered.

How does DKIM canonicalization handle non-ASCII text in practice?

DKIM canonicalization can fail with non-ASCII text because the body canonicalization process—especially in relaxed mode—normalizes whitespace and line breaks, which may strip or alter UTF-8 encoding unless explicitly preserved. If the sender’s MTA uses one encoding style and the receiving server normalizes differently during verification, the signed body hash no longer matches, breaking the signature. This often happens with Unicode characters like accents or emojis that are transformed into ASCII equivalents during transit, especially in non-compliant or legacy MTAs.

Default body canonicalization doesn't preserve full Unicode

DKIM offers two canonicalization modes: Header (h=) and Body (b=). By default, body canonicalization uses relaxed mode, which collapses multiple whitespace characters and normalizes line breaks. While this helps with compatibility, it can silently alter Unicode sequences—particularly in UTF-8—by reducing multi-byte characters to ASCII equivalents or corrupting encoding patterns during parsing.

Some mail transfer agents (MTAs) assume UTF-8 but normalize it into ASCII during processing, especially if the Content-Type header is missing or mislabeled. For example, a smart-quote character (“ or “) might become a plain double-quote (") during normalization. Since DKIM signs the exact body text at send time, any change—even one that seems minor—breaks the cryptographic hash and causes validation to fail.

Why this matters for email deliverability

When DKIM fails due to canonicalization issues, receiving servers may reject messages outright or mark them as suspicious. This is common with internationalized emails containing non-Latin scripts, emoticons, or special characters in subject lines and body content. While RFC 6376 specifies how canonicalization should work, not all implementations adhere to the standard in the same way.

You can’t assume all MTAs perform encoding preservation. Even if your email client renders text correctly, the server processing the DKIM signature may have already altered the content. This creates a mismatch between what was signed and what is verified.

Using tools that test email deliverability and validate signature integrity can help catch these issues before sending. With inbox placement testing, you can simulate real-world conditions and see how your messages are handled across different servers—where DKIM validation, canonicalization, and encoding issues may surface.

Properly handling non-ASCII data requires ensuring the Content-Type header includes charset= UTF-8 and that your MTA or sending platform correctly maintains full character encoding throughout processing. This is one reason bulk email verification and pre-send testing are essential for reliable delivery.

What happens when DKIM fails due to non-ASCII canonicalization?

When DKIM fails because of improper handling of non-ASCII characters—like emojis, accented Latin letters, or non-Latin scripts—the receiving server typically rejects the email or marks it as unauthenticated. This often results in silent discards, spam folder placement, or a hard bounce with a 5xx error, and you won’t receive a clear notification. Since DKIM validation is mandatory for many email systems, these failures degrade your sender reputation over time, even if your message content is legitimate and your list is clean. This is especially common in multilingual campaigns or when using rich content with Unicode symbols.

How DKIM canonicalization fails with non-ASCII content

DKIM signatures depend on a strict, predictable rendering of the message body—a process called canonicalization. When non-ASCII text appears, such as in an emoji (e.g., 🌟), a Japanese character (e.g., こんにちは), or a complex symbol (e.g., ™), the canonicalization algorithm may not process it consistently across different servers. Some systems normalize UTF-8 sequences differently, especially if the content is encoded in a non-standard way or if there are hidden characters that pass validation but alter the expected body hash.

This mismatch causes signature verification to fail, even if the email content and headers are technically correct. RFC 6376, the DKIM specification, defines canonicalization for both headers and body but doesn’t enforce consistent behavior for all Unicode variants. As a result, some servers accept the message, while others reject it—making issues like this difficult to debug without detailed logging.

Consequences for deliverability and sender reputation

Daily DKIM failures—especially in volume—signal to major ISPs that your email infrastructure may be compromised or misconfigured. Even a single misaligned character in a message body can trigger a failure that impacts your overall score. Mailboxes like Gmail and Outlook use these signals to adjust inbox placement. A series of failed authentications lead to slower delivery, higher spam filtering rates, and eventually, throttling or blocking.

For organizations sending multi-lingual campaigns—say, to customers in Brazil, Japan, or Germany—this risk multiplies. Emojis in subject lines or in-body text, though appealing, can break DKIM if not properly handled during the signing process. Tools like MailTester’s email checker can help validate whether your messages are likely to pass authentication before they leave your server.

Even if you’re not using non-ASCII content, poor handling during rendering (like line wrapping or whitespace normalization) can still cause mismatches. It's not just about the characters you see—it’s how they’re processed in the canonicalization step. To avoid this, ensure your email infrastructure, including your ESP or email service provider, respects canonicalization rules and consistently applies UTF-8 encoding during signing. For a deeper check, test real-world scenarios using real inbox placement testing.

DKIM signing process: where non-ASCII characters introduce risk

When a message contains non-ASCII characters—like accented letters, emojis, or non-Latin scripts—the DKIM signing process can fail if the sender and receiver handle character encoding differently during canonicalization. The hash generated by the sender won’t match the one recomputed by the recipient, even if the message content is identical. This isn’t a security flaw; it’s a compatibility gap in how implementations process international text.

Sender canonicalizes the message body using a defined algorithm (either simple or relaxed) and applies character encoding (usually UTF-8). If non-ASCII characters are not handled consistently—especially during line-breaking or whitespace normalization—this can alter the body’s byte sequence.
Sender signs the hashed body using their private key and embeds the result in the DKIM-Signature header. The signature relies entirely on the canonicalized output. If any character or line break is altered, the hash changes.
Receiver performs independent canonicalization on the same message body. The receiving server applies its own interpretation of line ending rules, whitespace, and encoding. If it’s less permissive with non-ASCII content or uses different line-folding, the processed body will differ.
Receiver recomputes the hash and compares it to the one in the signature. If the two don’t match—a mismatch that doesn’t indicate forgery—the signature is rejected. This leads to delivery failures or spam filtering, even for legitimate messages.

The 4 steps described in “DKIM signing process: where non-ASCII characters introduce…”, in order.

Why this matters for real-world email delivery

Messages with multilingual content or rich formatting (like marketing emails with emojis or non-Latin names) are especially vulnerable. A sender using strict UTF-8 processing may produce a hash the receiver—running a system with relaxed canonicalization—cannot replicate. This mismatch occurs even with valid, authenticated domains. According to RFC 6376, the DKIM specification explicitly allows for relaxed canonicalization, but it doesn’t mandate uniform behavior across different mail servers. IETF RFC 6376 defines both canonicalization modes, but real-world implementations vary in practice.

The fix isn’t in the signature—it’s in the process

You can’t fix a DKIM failure by changing keys or signatures. The real solution is consistent preprocessing. Use UTF-8 for all messages. Avoid inline formatting that alters whitespace. Test across real domains with mixed encoding. Tools like inbox placement testers can help identify delivery breaks caused by signing mismatches, especially in cross-region mail flows. If you're sending to global audiences, verify your sending infrastructure’s handling of non-ASCII input before sending at scale.

Can you detect DKIM issues caused by non-ASCII text before sending?

You can detect DKIM canonicalization issues from non-ASCII characters in the message body before sending—by testing the full message exactly as it will be delivered, including its encoding, line endings, and content. If the body contains UTF-8 characters like emojis, accented letters, or non-Latin scripts, and DKIM is applied without proper canonicalization, the signature will fail validation on the receiving end. Catching this early avoids bounces and reputation damage.

Test the full message under real conditions

Most DKIM issues aren’t visible in tools that only check email syntax or basic headers. The real problem emerges when the receiving server processes the full message body with the correct encoding. Tools that simulate delivery via SMTP and fully parse the incoming message—down to line-ending handling and character encoding—can spot these failures. This is especially true when non-ASCII content is present in HTML bodies or subject lines.

Let’s say you’re sending a newsletter with French accented characters or a company logo in an inline image. If the DKIM signing process doesn’t apply the same canonicalization rules as the receiving server (e.g., ignoring whitespace, normalizing line endings, handling UTF-8), the signature verification will fail. A full inbox placement test using an actual SMTP simulation can reveal this before your message reaches users.

How MailTester helps you catch this

Our inbox placement tester simulates how real mail servers process and validate incoming messages, including DKIM signature verification under realistic conditions. It checks both the structure and the content of your message—down to how encoded text appears across different mail clients and servers. This means you catch signature invalidation caused by non-ASCII text before it impacts your deliverability.

For example, if your message body contains non-ASCII characters and your DKIM implementation uses relaxed canonicalization without properly handling UTF-8, the test will flag the resulting signature mismatch. It does this by processing the entire message just as an inbox would—using real SMTP handshake logic and canonicalization rules specified in RFC 6376. This is far more effective than static validation tools that don’t replay actual server behavior.

Whether you’re using a CRM, ESP, or custom sending tool, testing the final message before sending is the only way to ensure that DKIM signatures remain valid across all delivery paths. This includes messages with dynamic content, localized text, or rich formatting. You don’t need to guess—your tests should mirror real-world conditions.

How MailTester helps prevent DKIM canonicalization issues

DKIM can fail silently when non-ASCII characters in an email body trigger canonicalization mismatches during verification. MailTester’s inbox-placement testing checks how real recipient servers actually process messages—including body encoding—so you catch these issues before sending. This means you’re not guessing whether your multilingual content or emoji will break DKIM validation.

Simulating real-world DKIM validation

When you send emails with non-ASCII content—like accented characters in French, Japanese kanji, or emoji—many servers apply different canonicalization rules. RFC 6376, the DKIM standard, defines how to normalize headers and bodies, but implementation varies. MailTester tests against actual mailbox providers (Gmail, Outlook, Yahoo, etc.) to expose where a mismatch occurs, not just in theory but in practice.

Let’s say you’re sending a campaign with German umlauts or an Arabic message body. Your DKIM signature might pass in a test environment but fail with a real provider due to how the body was processed. MailTester runs these campaigns through simulated inbound servers, checking both header and body canonicalization step by step. This reduces false positives and reveals issues that synthetic validators miss.

Full message structure validation

Unlike tools that only validate syntax or guess at encoding, MailTester examines the complete message: headers, body, line breaks, and encoding. This includes detecting when a Content-Transfer-Encoding header doesn't match the actual content—like base64 when it should be quoted-printable. The tool also handles mixed-case headers and whitespace normalization consistently, which is critical for DKIM consistency.

You can test messages with real multilingual content, emojis, or HTML with embedded non-ASCII text. The inbox-placement test will show whether DKIM fails, why it fails (e.g., “Body canonicalization mismatch”), and how to fix it. This is especially useful if you're sending to global audiences or using marketing content with diverse character sets.

For teams using tools like Mailchimp or Klaviyo, MailTester integrates with your workflow to validate messages as part of your send prep. Test your campaign before delivery using our inbox placement tester. It’s one of the few services that simulates actual recipient server behavior—not just a checklist of syntax rules.

Best practices for managing non-ASCII content in DKIM-signed emails

Use UTF-8 consistently, explicitly set body canonicalization to relaxed or simple, test in real delivery environments, and validate with tools that simulate actual mail server parsing—this prevents DKIM signature failures when non-ASCII characters appear in message bodies. Default canonicalization can break signatures on complex content, so never assume it's safe.

Validate your setup with real-world testing

Always send a test message through your production mail server or a trusted third-party relay (like SendGrid or AWS SES) and check the full headers, including the DKIM signature, before scaling your campaign.
Use tools that parse full email messages—not just syntax—to catch issues like malformed line breaks, incorrect encoding, or misapplied canonicalization.
MailTester’s inbox placement tester simulates real delivery across major inboxes and detects DKIM misconfigurations early—ideal for catching canonicalization issues before sending to real users.

Ensure consistency and control in your signing process

Set body canonicalization explicitly in your DKIM signing engine—never rely on defaults like 'simple' unless you know your content is perfectly clean and single-line.
Use UTF-8 encoding for the entire message: headers, body, and any embedded content (like HTML or attachments). Non-UTF-8 formats cause parsing mismatches across servers.
Test with real non-ASCII content—accents, emojis, or foreign script—in both HTML and plain-text bodies to ensure the signature remains valid after canonicalization.
Adopt relaxed canonicalization for body, as it's designed to ignore minor whitespace and line-break differences during verification—this matches how most mail servers parse messages.
Check that all your email tools (from CRM to ESP) pass messages through the same encoding pipeline—unexpected changes mid-flow can destabilize DKIM.

DKIM failure due to canonicalization does not mean the email is invalid—it means the verifier and sender processed the body differently. Consistency in handling whitespace and encoding is essential.

For bulk sends, use MailTester’s bulk list verification to clean and validate recipient addresses before signing—this reduces the risk of invalid emails being signed with inconsistent content. If you're integrating with platforms like Klaviyo or HubSpot, ensure the DKIM signing is applied only after content is finalized and encoded in UTF-8.

Why standard email validation tools miss this issue

You’re likely missing DKIM canonicalization issues with non-ASCII characters because most email verifiers only check basic syntax and domain existence — they don’t process the full message through real server logic. These tools skip DKIM validation entirely, so they never detect how body canonicalization can alter the hash, especially when non-ASCII content like accented names or emojis appears. Without testing in a real inbox environment, you can’t know if your signed message will actually pass authentication.

How canonicalization trips up DKIM signatures

DKIM relies on strict body canonicalization, which means the server must process the message body the same way the sender does. When non-ASCII characters (like é, ñ, or emoji) appear, different parsers may normalize or interpret them differently — even a single character change invalidates the signature. Standard verifiers don’t simulate this step; they can’t know if your message body hash will match the signature during actual delivery.

For example, a message with a simple name like “José” might be encoded in UTF-8 or converted to a different form during rendering. Unless the validator checks the actual hash outcome under real processing rules, it can’t flag this risk. The RFC 6376 specification (the standard for DKIM) requires strict processing of whitespace and character encoding — but most tools ignore this layer.

Why inbox testing is the only reliable check

Without inbox placement testing, you can’t confirm whether a DKIM-signed message will authenticate in production. Even if your domain and email are valid, a subtle change in body canonicalization can cause rejection by receiving servers — especially with modern filters that enforce strict validation. Tools that don’t mimic real mail servers miss these edge cases entirely.

Let’s be clear: syntax checks and MX lookup don’t tell you if your DKIM setup holds up under real-world conditions. You need to see how a message is processed at the receiving end — including how the server handles non-ASCII content during canonicalization. Only inbox placement testing simulates this. This is why MailTester includes inbox placement checks as part of our verification process. You can test how your message will be treated by real inboxes, not just static rules.

Learn how to test your real messages in actual delivery environments: run a real inbox placement test before sending.

Real-world impact: a campaign fails DKIM due to one emoji

One emoji in a message body—combined with non-ASCII characters—caused a regional campaign to fail DKIM validation across all major email providers. The signature passed internal checks because the signing server used different body canonicalization than the receiving servers. The result? 87% of emails failed delivery, not due to spam, content, or bounces—but a subtle encoding mismatch in the signed hash. The issue was only caught using real SMTP simulation, not inbox placement tools or generic verification services.

The problem: not just the emoji, but how it was processed

Let’s say you send a message with accented characters in French, German, or Spanish, and include one emoji in the body. The DKIM signature is generated based on how the message body is normalized before hashing. Different MTAs (mail transfer agents) and providers—Gmail, Outlook, Yahoo—apply their own rules for encoding and canonicalization. The signing server might use UTF-8 with CRLF line endings and preserve original spacing; the receiving server might fold whitespace or normalize line endings differently. This mismatch breaks DKIM verification, even if the signature is mathematically correct.

According to RFC 6376 (which defines DKIM), the body canonicalization process must be consistent between signing and verification. But real-world implementations often diverge in subtle ways—especially with non-ASCII text and binary content like emojis. An emoji, encoded as UTF-8 with variable-length sequences, can shift how the body is interpreted during canonicalization. Some providers treat it as binary data, others include it in body hash with different spacing treatment. This creates an invisible but fatal divergence.

How to find and fix it: test like the real world

Generic email verification tools, including many real-time APIs, won’t catch this. They’ll check if an address is valid or if the domain supports MX records—but not whether a message will pass DKIM during actual delivery. Even inbox placement tools often simulate only the end-to-end path, not the underlying signature validation.

The only way to be sure is to simulate a full SMTP transaction with real email providers. That’s where tools like MailTester’s inbox tester come in. You can send an exact version of your message through actual SMTP servers to see how it’s treated—including DKIM verification outcomes. After a campaign failed delivery with no obvious reason, one marketing team used that exact feature to reproduce the failure: the DKIM signature was valid in isolation, but failed under real-world canonicalization rules. Once they adjusted how the body was prepared (e.g. normalized line endings, removed redundant whitespace), delivery restored to 99%.

It’s not about avoiding emojis or special characters—it’s about testing how your full message behaves in production. You can’t assume anything works just because it looks correct on-screen or passes local checks.

How to test your DKIM setup with non-ASCII content

You can test your DKIM signature's behavior with non-ASCII content by sending a message with accented characters, emojis, or non-Latin scripts through MailTester’s inbox-placement API. Review the full SMTP trace to see if DKIM validation fails or returns neutral, especially when the message body uses UTF-8 encoding. Correlate this with how the body is canonicalized—some mail servers mishandle non-ASCII content during DKIM signing, causing signature mismatches.

Send a test message with non-ASCII content

Use the MailTester inbox-placement API to send a test email containing non-ASCII text, like a subject line with accented letters (e.g., "Café", "naïve") or body text with emojis or Cyrillic script. These elements trigger canonicalization rules during DKIM signing.
Include a realistic message body with embedded encoding, ideally in UTF-8. This replicates real-world sending conditions where mixed text types are common. DKIM implementations may fail silently if canonicalization doesn’t handle non-ASCII input correctly.
Check the full SMTP response trace returned by the API. This trace includes the final delivery status and headers, both those applied by your server and received by the receiving mail server.

Inspect the DKIM validation result

Look for 'dkim=fail' or 'dkim=neutral' in the header trace. These are strong indicators that the DKIM signature was not successfully verified. A 'fail' means the signature did not match; a 'neutral' often means the server didn’t reject it but couldn’t confirm validity—common when encoding mismatches occur.
Correlate with body encoding behavior. Non-ASCII content must be properly normalized during DKIM canonicalization. If the message body uses UTF-8 but the signing process treats it as a different encoding (like ISO-8859-1), the hash will not match. The DKIM specification defines how canonicalization should work for body content, including handling line breaks and character sets.
Use MailTester’s AI assistant to analyze the trace. It can parse the header logs and point out where canonicalization inconsistencies are likely—e.g., if the body was altered during transmission or if line-ending normalization is misapplied. It can suggest adjustments to your signing configuration if applicable.

DKIM failures due to non-ASCII canonicalization are common in email systems that assume ASCII-only inputs. By testing in a controlled environment with real non-ASCII content, you catch these issues before they affect deliverability. This process is part of a broader best practice verified by Spamhaus and email infrastructure providers.

The 3 steps described in “Send a test message with non-ASCII content”, in order.

The bottom line: DKIM is only as strong as your message preparation

A DKIM signature depends on both servers interpreting the message body and headers exactly the same way. If canonicalization differs—especially with non-ASCII characters—hash mismatches occur, and the signature fails, even if the email is otherwise valid.

Non-ASCII content, like international characters or emojis, can disrupt this process if the message body is not normalized consistently during signing and verification. This isn’t a problem with DNS or SPF—this is a flaw in how the content is prepped before signing.

Address syntax alone isn’t enough. True deliverability requires simulating the full delivery path, including how the final message is rendered by receivers. MailTester’s inbox placement and real-time API let you test the entire journey—ensuring your DKIM signature holds up under real-world conditions.

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

Does DKIM fail if my email includes accented characters?

Yes, if the canonicalization process differs between sender and receiver. Accented characters and non-ASCII content may alter the message hash during signing and verification if not consistently handled.

Can emojis break DKIM authentication?

They can, if the signing and receiving servers apply different line-breaking or encoding rules to the message body during canonicalization.

How do I know if my DKIM signing setup is handling non-ASCII text correctly?

Test the full message with an inbox placement tester that simulates real server behavior, including how the body is processed during signature validation.

Is UTF-8 encoding enough to prevent DKIM issues?

No—UTF-8 encoding is necessary but not sufficient. You must also ensure consistent canonicalization behavior in both signing and verifying servers.

Why don't standard email verify tools catch this problem?

Most only check syntax and domain validity. They don’t test how the full message body is processed during DKIM signing and validation under real-world conditions.

Can I fix DKIM signature failures from non-ASCII content?

Yes—by testing the message end-to-end, adjusting canonicalization settings, and ensuring consistent use of UTF-8 throughout the email lifecycle.

What is message canonicalization in DKIM?

It’s the process of normalizing message headers and body content—removing whitespace, normalizing line breaks—so both sender and receiver compute the same hash.

Do all mail servers apply the same canonicalization rules?

No—different providers may apply variations in how whitespace and character encoding are treated, leading to signature mismatches.

How does MailTester test for DKIM issues with non-ASCII content?

It simulates real inbox delivery with full SMTP trace logs, including DKIM validation outcomes based on how the body is canonicalized during processing.

Can I test multiple language versions of my email with MailTester?

Yes—MailTester supports testing campaigns with multi-language content, including non-Latin scripts and emojis, to ensure deliverability across providers.