Why does DKIM fail when emails contain UTF-8 characters?

You send a perfectly crafted email with an accent in the subject line—maybe “Café” or “Résumé”—and it fails to deliver. Or worse, it lands in spam. You check your headers, your SPF, your DKIM setup. Everything looks correct. But the signature still fails.

Here’s the catch: DKIM signing relies on a strict canonicalization process. When an email includes UTF-8 characters—accents, emoji, or non-Latin scripts—the canonicalization step can break if those characters aren’t handled properly. Even a minor mismatch in encoding between what’s signed and what’s verified can invalidate the entire signature.

DKIM is designed to verify that the email hasn’t been altered in transit. But if the signing process misinterprets a single character due to UTF-8 handling, the signature fails—regardless of whether the email content is actually malicious.

Key takeaways

  • DKIM canonicalization processes headers and body content in a strict, case-sensitive way—UTF-8 characters must be encoded consistently during signing and verification.
  • Accented letters, emoji, or non-Latin scripts in email subjects or body can invalidate DKIM signatures if not properly normalized before signing.
  • Even minor header encoding mismatches—such as improper charset declaration or line-ending handling—can cause DKIM verification to fail, leading to delivery issues or spam filtering.

What is DKIM canonicalization, and why does it matter?

DKIM canonicalization standardizes how an email’s content is formatted before signing, ensuring servers interpret the message the same way—no matter who sends it. If the headers or body aren’t processed the same, the DKIM signature fails, and your email gets rejected or marked as spam. This is especially critical when you use UTF-8 characters like accented letters or emojis, which must be encoded correctly per RFC 6365 to avoid breaking the signature chain.

How DKIM canonicalization works

When you sign an email with DKIM, the signing server applies a set of rules to normalize the content—trimming whitespace, converting line breaks, and standardizing header formatting. This process is called canonicalization. It’s designed to make the signed content predictable and consistent across mail servers that may reorder or modify the message slightly during transit.

There are two modes: relaxed and strict. Most domains use relaxed canonicalization, which tolerates minor changes like extra whitespace or reordered headers. Strict canonicalization requires the exact original format. Using strict mode with non-ASCII text can quickly break if the email isn’t formatted precisely, which is why relaxed is standard in practice.

UTF-8 and the hidden risk in DKIM signing

When your email contains non-ASCII text—like names in French, Japanese, or emojis—the content must be encoded using RFC 6365-compliant methods to maintain integrity through canonicalization. This means UTF-8 text must be properly quoted and encoded in headers, body, and any signed parts. If your email client or service doesn’t do this correctly—especially if it uses a malformed or outdated encoding scheme—the content changes during signing, and the signature validation fails.

For example, sending "Café" as raw UTF-8 in a header without proper encoding (like =?UTF-8?Q?Caf=C3=A9?=) can cause the signed headers to mismatch during verification. This isn’t a problem with the DNS record or the private key—it’s a flaw in how the content was normalized before signing. The result? A failed DKIM check, even if everything else is correct.

Many tools that check email deliverability or test DKIM signatures won’t catch this unless they simulate the full canonicalization process. That’s why it’s essential to use a sender that properly implements RFC 6365 and maintains consistency in how content is processed across your email pipeline.

For a real-world check, you can test your DKIM alignment with tools that validate the full signing chain. If you're managing a bulk mailing list, use a service like MailTester’s bulk email verification to catch invalid or misformatted addresses before sending—many of which stem from encoding issues that break DKIM.

For deeper insight, refer to the foundational specification: RFC 6365, which defines how UTF-8 should be quoted in email headers. Also see the Internet Society’s guide on DKIM, which clarifies how canonicalization fits into overall email security.

How to diagnose a DKIM canonicalization error with UTF-8 content?

If your email fails DKIM validation with a "canonicalization error" or "signature mismatch" in the headers, and you're using UTF-8 characters in the subject, body, or From field, the issue is likely improper handling of encoding during signing. Check the full email trace—specifically the Received-SPF, Authentication-Results, and DKIM-Signature headers—to isolate whether the failure points to canonicalization. If the receiving server sends a DMARC feedback report (RFC 8098), it often includes exact error details. Tools like MxToolbox or RFC 6376 define how canonicalization should work: if your signing implementation doesn’t preserve UTF-8 encoding during header normalization, the signature will fail. Let’s break down how to verify this.

Check the full email trace for authentication failure details

  • Open the full email header (not just the visible parts) and look for Received-SPF and Authentication-Results lines near the top.
  • Look for any mention of Dkim-Signature failures, especially with the words "canonicalization" or "signature mismatch."
  • Search for the dkim=permerror or dkim=fail status in the results, which indicates a problem during the signature verification step.
  • Confirm the domain in the DKIM-Signature header matches your sending domain—mismatched domains are a common misdiagnosis.

Review DMARC feedback reports for root cause clues

  • If your domain has DMARC enabled, receiving servers may send feedback reports (RFC 8098) to a designated address.
  • These reports often list exact failure reasons—look for fields like reason=canonicalization-error or reason=signature-mismatch.
  • Feedback reports typically include the full message and header, making them excellent for reproducing the issue in a test environment.
  • These reports are often sent to [email protected] or a dedicated mailbox; ensure you're monitoring them.

If you’re sending personalized emails with accents, emojis, or non-Latin script in the subject or body, the signing process must preserve UTF-8 encoding through both "simple" and "relaxed" canonicalization modes. Many older or poorly implemented mailing systems incorrectly convert or strip UTF-8 content before signing, which breaks the signature when the receiving server applies canonicalization rules strictly. You can test your setup with a real-world tool: run a sample message through email inbox placement testing to see how it’s received and verify whether the headers show errors under real-world conditions.

The exact process to fix DKIM canonicalization issues involving UTF-8

If your DKIM signature fails due to UTF-8 characters in headers like Subject, To, or From, you must ensure those values are properly encoded before signing—using quoted-printable or base64 per RFC 6365—and the encoding is applied before canonicalization, not after. Always sign with the same canonicalization mode (relaxed or simple) used in your DKIM record, and verify the new signature with a tool that checks both DKIM and DMARC alignment.

Step-by-step: Fixing UTF-8 in DKIM signing

  1. Identify the signed headers. Check your DKIM signature to see which headers are signed—typically From, To, Subject, and MIME-Version. If any contain UTF-8 characters (like non-ASCII names, accented letters, or emoji), they must be encoded before signing.
  2. Use RFC 6365-compliant encoding. For text content, apply quoted-printable encoding for readability and base64 for binary or highly non-ASCII data. This ensures UTF-8 content is represented correctly in header fields without corrupting the signature.
  3. Apply encoding before signing. You cannot encode after signing. The canonicalization process applies to the raw header value as it appears in the message. If the value is not encoded before signing, the signature will not match when the recipient decodes it.
  4. Match the canonicalization mode. Check your DKIM DNS record for the canonicalization settings—either "relaxed" or "simple." Your signing process must use the same setting to produce a valid signature. Mismatched modes cause failures even with correct encoding.
  5. Re-sign the message. After encoding the headers and confirming the canonicalization mode, generate a new DKIM signature using your private key. Do not reuse old signatures—this will not fix the issue.
  6. Verify the signature. Use a real-world email testing tool like inbox placement tester or parse DMARC reports to see if the message passes DKIM validation. Tools like MxToolbox or Spamhaus can also help diagnose alignment issues. If the signature fails, go back and ensure encoding was applied before signing and that the header content matches expectations.

Why this matters: the consequences of wrong encoding

Even small encoding mistakes break DKIM validation, leading to bounced messages, low inbox placement, or flagged spam. Recipients like Gmail and Outlook rely on strict DKIM checks. Improper handling of UTF-8 content means your domain’s reputation suffers, even if your content is legitimate.

Proper encoding is not optional for international emails. The RFC 6365 standard exists because inconsistent handling breaks the signing chain. Using tools that simulate real mail servers—like those in MailTester’s inbox placement feature—lets you catch these issues before sending to real users.

Common mistakes in UTF-8 handling that break DKIM canonicalization

DKIM canonicalization fails when non-ASCII characters aren’t encoded properly before signing, especially when header fields aren’t normalized or MIME-encoded before the signature is generated. You can’t just sign raw UTF-8 — the signing process must see the same byte sequence that the receiving server will parse. If you sign content with unencoded Unicode, you’ll get a mismatch. Let’s go through the most common real-world errors that trip up even experienced senders.

Improper header encoding before signing

  • Using plain UTF-8 text in headers like Subject or From without MIME encoding (e.g., Subject: =?UTF-8?B?...).
  • Applying Content-Transfer-Encoding only in the final message, not before DKIM signing — this breaks canonicalization because the signed content changes.
  • Signing raw text that includes ö, é, or other non-ASCII characters without RFC 2047 encoding — the signature will never validate.

Normalization and whitespace issues

  • Not normalizing whitespace in header fields before signing — extra spaces, line breaks within headers, or inconsistent indentation change the canonicalized form.
  • Mixing non-ASCII characters across multiple headers (e.g., From and Subject both using UTF-8) without consistent MIME encoding, leading to mismatches during validation.
  • Encoding the same header content differently in different parts of the message (e.g., one instance with quoted-printable, another with base64).

DKIM requires both sender and receiver to arrive at the same canonicalized header set. If you sign raw UTF-8 and the receiving server processes it as a MIME-encoded string, the hash won’t match. This is one of the few places where the difference between what you send and what is signed matters.

Let’s get concrete: if you send Subject: Über den Weg and sign that raw string, but the receiving server sees it as Subject: =?UTF-8?Q?Uber_den_Weg?=, the signature checksum fails. You can’t recover from that. The fix is to encode everything properly before signing — RFC 2047 is your guide here.

Even tools that claim to automate DKIM signing can fail if you feed them unencoded data. If you’re building your own system, use a well-tested library (like Python’s email package or a trusted MIME encoder) and test with real receivers. A single misencoded word can break delivery for thousands of users.

You can verify whether your DKIM-protected messages are properly signed and canonicalized with real inbox testing. Try a real-world delivery test that checks both parsing and signature validation: test inbox placement and DKIM validation before sending to your full list.

How to test if your DKIM fix worked with UTF-8 content

Send a test email with UTF-8 content to mail-tester.com or use MailTester’s inbox-placement testing to validate the full signature chain. Check the DKIM signature using MxToolbox or DNS TXT record lookup to ensure it verifies without errors. Confirm the signature passes only when using real, unmodified headers — including the full encoding chain. Use the MailTester API to test individual addresses with UTF-8-heavy headers and verify that the DKIM status reflects success.

Step-by-step validation process

  1. Send a real email with UTF-8 content to mail-tester.com — This simulates a live delivery and shows how your DKIM signature holds up under actual conditions. It checks not just the signature itself, but also how it interacts with headers like Subject and From when encoded in UTF-8.
  2. Inspect the DKIM signature with MxToolbox or DNS TXT lookup — Use MxToolbox’s DKIM checker to verify the signature’s existence and validity. This confirms your public key is correctly published and the signature aligns with the message body and headers. A failure at this stage means the fix didn’t stick.
  3. Validate with unmodified headers, including full encoding chains — DKIM signing requires the canonicalization to match the actual headers sent. If you skipped or altered any encoding step during signing, the verification fails. You must test with the full, raw header set as sent — not sanitized or reformatted.
  4. Use MailTester’s real-time verification API for targeted checks — Run individual address validations through the verification API. Select addresses with non-Latin characters in subject or name fields. Check the response for “valid” status and a matching DKIM verification result to confirm consistency across real-world sending.
  5. Review the full header chain in a raw email — Open the delivered message in a mail client or email analyzer. Look at the full MIME headers, especially the Subject: and From:. Ensure they appear exactly as signed, with correct encoding (e.g., Subject: =?UTF-8?B?...?), and that the DKIM signature includes them unaltered.

Why real-world testing matters

DKIM canonicalization errors often only surface under actual UTF-8 headers. A signature that passes in a controlled test may fail in production when the full header chain is sent. This is why testing with real content — not just a sample — is required. According to RFC 6376, the canonicalization process must preserve the exact header order and encoding as received by the mail server. This includes handling of folded lines, charset declarations, and non-ASCII text.

Even if you use tools that claim to fix DKIM errors automatically, they fail when the underlying issue is a misaligned canonicalization step in the signing chain. Only testing with real, UTF-8-heavy headers — and verifying the full signature — reveals true success.

What to do if your email sends with UTF-8 but DKIM still fails

If your email uses UTF-8 characters and DKIM fails despite correct syntax, the issue is likely canonicalization. DKIM signing must preserve header content exactly as signed—any alteration, including encoding changes, breaks the signature. You're not alone: UTF-8 handling is a common source of silent DKIM mismatches. Double-check your DNS records, signing library logic, and whether third-party tools are rewriting headers.

Check your DKIM DNS configuration

  • Verify the DKIM selector and domain match exactly between your email headers and the published DNS record.
  • Use a tool like MXToolbox's DKIM Lookup to confirm the TXT record is published and readable by DNS resolvers.
  • Ensure the selector (e.g., "default" or "mail") is correctly referenced in your signing process and the record is not truncated by DNS limits.

Validate your signing process and library

  • Confirm the DKIM library you're using (like OpenDKIM, DMARCian, or custom code) applies relaxed canonicalization to headers and simple to body, as defined in RFC 6376.
  • Check that UTF-8 characters are preserved unchanged in the signed header fields. Some libraries auto-encode or normalize characters, which breaks DKIM.
  • Test by signing a simple email with known UTF-8 content (e.g., "Subject: Café & Résumé") and comparing the output against a known-good sample using a public validator like DKIMValidator.com.
  • Disable any email filtering, rewriting, or preprocessing layers between signing and sending—these often alter content without notice.
DKIM fails silently when canonicalization doesn’t match the signature. One character changed in a header can invalidate the entire signature, even if the email arrives.

Let’s be clear: if your email client shows non-ASCII text correctly but DKIM still fails, the signing process likely altered the content—even if subtly. Use real-world validation. Compare your signed headers line-by-line with a trusted, working DKIM-signed email. The difference may be in line endings, whitespace, or character encoding normalization. Fixing these inconsistencies fixes your DKIM issue.

If you're sending via an ESP like SendGrid or Mailchimp, check their documentation to see if they apply post-signing transformations. Some services modify headers after signing, breaking signatures.

Use MailTester’s inbox placement tester to see if your email is landing correctly in inboxes—this helps determine if DKIM is truly failing delivery, or if other factors (like spam triggers or poor engagement) are at play.

The role of UTF-8 encoding in email header canonicalization

You must encode non-ASCII characters in email headers using quoted-printable or base64 and explicitly declare the charset (like UTF-8) to ensure consistent canonicalization. Without this, receivers may parse the same header differently, breaking DKIM validation since signed content must match exactly across all systems. This is required by RFC 6365.

How headers are meant to be encoded for consistency

When you include non-ASCII characters in headers like Subject or From, you can't just write them raw. For example, "Cérémonia" must be encoded as Subject: =?UTF-8?Q?C=C3=A9r=C3=A9monia?=. The =?UTF-8?Q? prefix tells receivers to interpret the following text in UTF-8 using quoted-printable encoding. This ensures every mail server—regardless of locale or config—parses the header the same way.

Even when you use Unicode characters directly in your email client's UI, the underlying MIME structure must still declare the charset and properly encode the bytes. If the charset isn’t declared, or encoding fails, receivers may canonicalize the header differently during DKIM signature verification. The result? A valid signature fails because the signed content doesn’t match the received one.

Why this breaks DKIM signing

DKIM signs a canonicalized version of the email headers. Canonicalization normalizes whitespace, line breaks, and header order—but it depends on the raw header values being consistent before parsing. If one system treats Subject: Cérémonia as a single UTF-8 string and another parses it as ASCII with malformed bytes, the resulting canonical values differ. The signature fails even if the message content is correct.

This is why standards like RFC 6365 exist: to ensure that internationalized headers are encoded uniformly, so signed content can be verified across diverse infrastructure. Modern mail systems expect this. Failure to follow it—especially in bulk campaigns with non-Latin subject lines or sender names—leads to silent DKIM failures.

Let’s be clear: if you’re sending emails with special characters and don't encode them properly or forget to declare UTF-8, you're increasing the risk of delivery failure. Even a single incorrectly encoded header can cause your DKIM signature to be rejected. Use a tool like our email checker to inspect address and header structure before sending, especially when including non-ASCII text.

How MailTester helps verify DKIM and UTF-8 issues in real time

You can catch DKIM canonicalization errors caused by UTF-8 characters before they break deliverability by testing email signatures and content in real time. MailTester’s API lets you send test emails via any SMTP provider and instantly verify DKIM signature validity, including how UTF-8 encoded headers are handled. You can also test inbox placement with rich, non-ASCII content to see if recipients or filters flag or block your messages.

Test real-world email flows with full verification

  • Use MailTester’s real-time verification API to send test emails through your preferred SMTP provider and get immediate feedback on DKIM signature validity—no waiting for bounces or feedback loops.
  • Run inbox-placement tests with UTF-8-heavy content, like non-Latin subject lines or accented body text, to detect if your domain triggers filters or gets marked as suspicious.
  • Send messages with non-ASCII headers (e.g., display names with emojis or Cyrillic characters) and validate how the sender’s server performs canonicalization—critical for DKIM compliance with RFC 6376.
  • Integrate with your system to test bulk lists containing non-ASCII data, catching UTF-8 issues across hundreds or thousands of addresses before send.

Get help diagnosing problems faster

  • Upload error logs or failed DKIM signature responses and use the in-app AI assistant to interpret patterns. It cross-references known issues, like misaligned header normalization or encoding mismatches, and suggests corrective steps.
  • Use the AI assistant to validate header canonicalization output against RFC 6376 recommendations—especially important when using custom mailers or third-party senders with non-standard implementations.
  • Test with real-world email clients (Gmail, Outlook, Yahoo) to see how UTF-8 content renders and whether filters mark your email as risky—helping you avoid deliverability pitfalls without guesswork.
  • Check domains that reject messages with non-ASCII headers and see which ones accept them, based on actual test results from MailTester’s global network of testing servers.

DKIM signing with UTF-8 requires strict adherence to header normalization rules. Even small deviations in whitespace or encoding can invalidate a signature. RFC 6376 defines canonicalization precisely; MailTester validates compliance in real time.

Why sender reputation suffers when DKIM fails due to UTF-8

When DKIM fails because of UTF-8 characters in the email’s header or body, it signals flawed email engineering to receiving servers. Even a single failure can trigger suspicion, and repeated issues degrade sender reputation over time. Receiving servers use signing consistency as a key signal for trust—frequent DKIM problems make your domain look unreliable, leading to throttling or outright rejection. Even if your content is legitimate, unresolved canonicalization errors can harm deliverability for weeks or months.

DKIM failures erode trust with receiving servers

Each DKIM failure acts as a red flag. Receiving servers don’t just see a bad hash—they see a pattern of inconsistency in your domain’s email infrastructure. This isn’t just about one message; it’s about reliability. If your signing process breaks regularly, especially with UTF-8 content, servers assume either misconfiguration or a broader technical flaw in your sending setup. This assumption affects your sender reputation score, which influences whether messages land in the inbox or get filtered.

UTF-8 canonicalization issues commonly arise when non-Latin characters—like accented letters or emojis—are included in headers or the message body without proper normalization. The DKIM specification requires strict, deterministic handling of these characters, and any deviation breaks the signature. For example, combining characters or multi-byte sequences must be processed in a consistent way across the signing and verification steps. A single misstep here causes failure—even if your content is otherwise valid.

When this happens repeatedly, it can trigger automated throttling. ISPs and large email providers like Gmail, Outlook, and Yahoo track signing success rates. If your domain crosses the threshold of repeated failures, they may reduce your sending rate or flag your domain for deeper scrutiny. You might not see an immediate bounce, but your inboxes will slowly fill with fewer messages over time.

It’s not just about avoiding bounces—it’s about maintaining trust. Once reputation drops, recovery is slow. The underlying cause—UTF-8 canonicalization in DKIM—needs to be addressed at the signing layer. You can’t fix it after the fact if you’re relying only on delivery reports. That’s why testing your email templates in real inbox environments matters.

Use an inbox placement tool to validate your emails before sending at scale. MailTester’s inbox tester checks how your messages appear across major providers, including signature and encoding compatibility. It’s not just about syntax—it’s about real-world deliverability.

For teams sending large volumes, validating your email list ahead of time can also prevent reputation damage. A single invalid or malformed address isn’t the issue—but multiple DKIM-failing messages, even from legitimate ones, signal trouble. Verify your list in bulk to catch structural flaws early. It’s a small step that keeps sender reputation intact.

Understanding how UTF-8 affects DKIM signing isn’t optional. It’s fundamental. The IETF’s RFC 6376 (the DKIM standard) mandates consistent handling of character encoding during canonicalization. Deviations, even subtle ones, break the chain. Proper implementation isn’t a feature—it’s a baseline of email engineering. If you're sending newsletters, transactional mail, or marketing campaigns, ensuring your DKIM process handles UTF-8 correctly is part of maintaining inbox placement.

The bottom line on fixing DKIM canonicalization with UTF-8

DKIM signing fails with UTF-8 characters in headers when the content isn't properly encoded and the charset is not declared. This breaks canonicalization, leading to signature validation failure.

Test changes in isolation

Always validate fixes in a staged environment that mirrors real recipient behavior. Use actual inbox feedback from providers to confirm the signature passes across different receiving systems.

Verify across providers

Use a tool like MailTester to test your signed emails across multiple inbox providers. It checks for correct UTF-8 encoding, header normalization, and signature validation—no guesswork.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can UTF-8 content break DKIM signing?

Yes. If UTF-8 characters in headers are not properly encoded before signing, they cause canonicalization mismatches, leading to DKIM signature failures.

What is the difference between relaxed and simple DKIM canonicalization?

Relaxed mode ignores whitespace and normalizes line breaks; simple mode preserves exact formatting. Relaxed is more forgiving with UTF-8, but both still require correct encoding.

How do I know if my DKIM signature is failing due to UTF-8?

Check email trace logs for DKIM or DMARC failure reports. Look for errors mentioning 'canonicalization' or 'signature mismatch' when UTF-8 content is present.

Does email service provider (ESP) signing bypass UTF-8 issues?

Not always. Some ESPs apply their own encoding rules after receipt, which can alter canonicalized content and break DKIM if not handled correctly.

Can I use emoji in emails without breaking DKIM?

Yes, but only if emoji are encoded using UTF-8 with proper MIME encoding. Incorrect handling will trigger canonicalization errors.

How often should I test DKIM with UTF-8 content?

Test new templates or content with non-ASCII text before sending to real users. Run periodic inbox-placement tests using tools like MailTester.

What’s the best way to encode UTF-8 in email headers?

Use quoted-printable encoding with explicit charset declarations, such as =?UTF-8?Q?Text?=. Ensure encoding is applied before signing.

Can I fix DKIM canonicalization errors without changing the DKIM DNS record?

Yes — if the error is in header encoding, not the key or selector. Fixing the signing process or library input resolves the issue without DNS changes.

Why do some receivers accept UTF-8 emails with DKIM errors?

Different MTAs apply varying levels of strictness. Some ignore small canonicalization mismatches; others log or reject them based on policy.

Does MailTester support testing UTF-8 DKIM issues?

Yes. MailTester’s inbox-placement and real-time verification API allow testing emails with UTF-8 content and validate DKIM signature integrity across providers.