Why does Gmail reject DKIM-signed emails with non-UTF-8 To headers?

You send a perfectly formatted email, signed with DKIM, and it lands in Gmail’s spam folder—or vanishes entirely. You check the headers, the DNS records, the content. Everything looks right. But Gmail still rejects it.

Here’s the twist: even a single header field encoded in anything but UTF-8—like a To: header using ISO-8859-1—can cause a DKIM signature validation failure, even if everything else is correct. It’s not spam. It’s not a misconfigured server. It’s a protocol-level strictness.

Gmail enforces full MIME compliance, including UTF-8 encoding for all header fields, regardless of whether they’re signed or not. When DKIM signs a message, it’s hashing the exact byte sequence of the headers as sent. If the To: field isn’t UTF-8, the hash doesn’t match, and the signature fails—no matter how legitimate the message. The integrity of the verification chain rests on literal precision.

Key takeaways

  • Gmail requires all header fields in DKIM-signed emails to be encoded in UTF-8, including the To: field.
  • DKIM signatures are cryptographically bound to the exact byte sequence of headers; non-UTF-8 encoding breaks validation even if content is otherwise correct.
  • Rejection due to encoding mismatch is a protocol-level failure, not a spam or content issue—fixing it requires encoding compliance, not list cleaning or domain whitelisting.

How UTF-8 encoding affects email authentication

You can’t rely on your email rendering correctly in a client if the To header isn’t UTF-8 encoded—Gmail and other major providers validate the DKIM signature over the entire header structure, including To, From, and Subject. Any non-UTF-8 character set in these headers breaks the cryptographic integrity, causing rejection even if the message displays fine. This is required by RFC 5322 and RFC 6376, which govern email formatting and DKIM signing.

Why the To header matters in DKIM validation

DKIM signs the entire email header and body as a cryptographic payload. That means the signature is only valid if every part—including the To field—uses UTF-8. If your mail server or toolset defaults to ISO-8859-1 or another encoding, the signed header doesn’t match the received one, and Gmail discards the message silently.

Let’s say you send an email with a To header like To: =?ISO-8859-1?Q?J=C3=B6rn=40example.com?. Even if the client renders it correctly, the DKIM signature was computed over non-UTF-8 data. Gmail’s validation pipeline checks the actual header bytes before display, and when it detects a mismatch, it’s treated as a forgery—whether intentional or not.

What major providers actually enforce

SMTP servers from Gmail, Yahoo, Outlook, and others adhere strictly to RFC 5322, which defines email header syntax, and RFC 6376, which standardizes DKIM. These standards require that non-ASCII characters in headers be encoded using UTF-8 with proper MIME encoding (e.g., =?UTF-8?B?... or =?UTF-8?Q?...).

If your email system generates or forwards headers in a non-UTF-8 format—especially through legacy systems or poorly configured templates—you’re likely to trigger delivery failures without obvious error messages. The server doesn’t reject the email because of content; it’s because the cryptographic signature doesn’t validate.

Even if your message renders correctly in 99% of clients, Gmail will still reject it if the To header fails UTF-8 validation during DKIM checks. This isn’t a client-side rendering issue—it’s a mail server-level validation rule.

Use tools that validate the actual MIME structure of your messages before sending. You can test how your email headers are encoded using a service like W3C’s guide on character encoding or RFC 6376 (DKIM Signature and Verification) for deeper technical context.

If you're sending bulk email with dynamic To fields, especially with international characters, use a tool that checks both syntax and encoding. For example, MailTester’s email checker validates whether addresses are syntactically correct and includes checks for common header-related issues, including encoding risks that impact authentication.

What happens when DKIM validation fails due to encoding

If a Gmail-receiving server encounters a DKIM-signed email with a To header that isn’t encoded in UTF-8, it logs the failure internally but doesn’t send a bounce or error code back to the sender. The message may be rejected silently, never reaching the inbox, and the sender gets no notification. This silent failure can degrade sender reputation over time, especially if it happens repeatedly across multiple sends.

The silent impact on deliverability

Unlike a clear 5xx SMTP error, DKIM validation failures from invalid encoding are invisible to the sender. Gmail doesn’t return a hard bounce, so you’re left guessing why some emails aren’t arriving. This lack of feedback makes troubleshooting difficult and delays fixes.

Even a single misencoded header can cause DKIM verification to fail. Since DKIM signs the entire message-body and header content, including the To field, any deviation from expected formatting breaks the cryptographic signature. The server sees the signature as invalid and discards the message, often without logging details publicly.

Reputation and long-term consequences

Repeated DKIM failures, even silent ones, signal to Gmail that your sending infrastructure isn’t consistent or well-configured. Over time, this lowers your sender reputation. Gmail’s systems track patterns across domains, IPs, and message integrity. If your messages fail DKIM validation more than expected for a given volume, you may be flagged, throttled, or even blocked.

According to RFC 6376, which defines DKIM, the integrity of the signed header fields is mandatory. If the To header isn’t properly encoded in UTF-8, the signature validation will fail. You can test this by validating headers using tools that follow the standard, such as those provided by the IETF RFC 6376.

Let’s be clear: there’s no email bounce, no error message, and no automatic fix. You’ll only know about it when engagement drops or the message never shows up in the inbox. This makes proactive validation of your email headers essential.

Use a reliable email-verification service to catch encoding issues before sending. Verify individual email addresses to check for structural issues, including header compatibility. If you’re sending in bulk, validate your entire list for formatting, deliverability signals, and compliance. These steps help you stay ahead of silent failures that hurt long-term deliverability.

Common sources of non-UTF-8 To headers in practice

Non-UTF-8 To headers often result from legacy systems, incorrect encoding handling in APIs, or improperly encoded international characters in email addresses. When systems output headers in ISO-8859-1 or Windows-1252 without conversion, Gmail’s strict parsing rejects them—even if the email content is otherwise valid. This commonly happens in older CRM or newsletter platforms that predate modern email standards.

Limited encoding conversion in outdated or misconfigured tools

Many legacy systems still default to ISO-8859-1 or Windows-1252, especially in regions with long-standing software stacks. Even when you use modern tools, a misconfigured API endpoint might pass raw header data without normalizing encoding. Let’s say you’re pulling names from a database using a script that assumes Latin-1. If the output isn’t explicitly converted to UTF-8 before header construction, Gmail sees a mismatch and rejects the DKIM signature.

Improper use of PHP’s mb_convert_encoding() or similar functions can worsen the problem. If the function isn’t applied consistently across all header fields—or if the input encoding is guessed wrong—the resulting header may still be non-UTF-8. This is a common pitfall in automated systems. The solution isn’t just running a conversion function once, but ensuring every string entering a header field is explicitly validated and normalized.

International email addresses without proper encoding

Email addresses with non-Latin characters—like 中文, ç, or ñ—are often embedded directly into To headers without proper RFC 6531-compliant encoding. Gmail and other modern servers require these characters to be encoded using UTF-8 and quoted-printable or Base64 (as defined in RFC 6531). If you send an address like user@例子.com without encoding the non-ASCII parts, the To header fails validation.

Even common cases like Latin-accents (e.g. João) can break unless processed correctly. Some email clients silently fail, but Gmail logs the rejection clearly in its delivery reports. This is why even small oversights—like forgetting to encode a single name—can trigger DMARC or DKIM validation failures, especially with authenticated messages.

If you’re unsure whether your headers are properly encoded, test the full sending pipeline with real-world inbox placement tools. Use MailTester’s inbox placement test to simulate how Gmail receives your email—including header parsing. It checks both DKIM and MIME structure, highlighting encoding issues before they impact deliverability.

Step-by-step: Verify and fix To header encoding before sending

Gmail rejects DKIM-signed emails with non-UTF-8 To headers because it enforces strict MIME compliance. If the To header uses a charset other than UTF-8—like ISO-8859-1 or no encoding at all—Gmail may fail the DKIM validation, even if the signature is mathematically correct. The fix is to ensure the To header is properly MIME-encoded in UTF-8, then re-sign the message using the updated header string.

  1. Extract the raw header from your outbound email. Use your SMTP logs, message source (View → Show Original in Gmail), or a mail server debug tool. Look for the exact To header as sent.
  2. Check the To header's encoding. A properly encoded To header appears as =?UTF-8?B?...?=. If it uses =?ISO-8859-1?B?... or no encoding, it’s incompatible with Gmail’s DKIM enforcement.
  3. Re-encode the To header in UTF-8. Apply MIME encoding using base64. For example, "Jörg Müller" becomes =?UTF-8?B?SsOvcmcgTYh1bGxlcmA=?=. Use tools like RFC 2047 to validate the syntax; incorrect encoding breaks parsing.
  4. Re-sign the email with DKIM using the corrected headers. DKIM signs the header fields *in their final form*. If the To header changes after signing, the signature becomes invalid. Always sign after finalizing the encoded headers.
  5. Test the full flow using a verification tool. Send a test email through your system and check the raw message again. Use MailTester's inbox placement tester to verify that the email hits the inbox and passes DKIM checks—no hidden rejections.

Why encoding matters beyond Gmail

While Gmail is strict, other providers like Outlook and Yahoo may silently ignore or misinterpret non-UTF-8 headers. This leads to inconsistent delivery and unreliable reputations. Using UTF-8 ensures cross-platform compatibility.

Encoding isn’t optional, especially with Unicode characters in names or domains. Even a single unencoded emoji in a To field can trigger rejection if the header isn’t UTF-8-safe. Never assume your mailer handles this correctly—verify it does.

Keep your send pipeline clean

Integrate header validation early. Don’t assume your mail client or ESP auto-corrects encoding. Catch issues at the point of message assembly—before DKIM signing and sending.

Use MailTester’s bulk verification to check list hygiene, including malformed addresses and encoding issues. Ensure your entire email campaign starts with clean, encoded data.

How email verification tools help prevent encoding issues

You can catch encoding problems in To, From, and Subject headers—especially in DKIM-signed emails—before they cause Gmail rejections by simulating actual delivery in real time. Tools like MailTester check header compliance during inbox placement tests, flagging non-UTF-8 encodings even within signed payloads, so you fix issues early, not after bounces or spam folders.

Real-time checks catch header compliance in live delivery conditions

Many senders assume DKIM validation alone ensures deliverability, but signed emails can still fail if headers contain non-UTF-8 characters. This is especially common with international addresses or non-Latin characters in names. MailTester’s real-time API doesn’t just validate addresses—it performs a full delivery simulation, checking how headers behave when sent over SMTP, including MIME encoding integrity.

When you use the API email checker, it evaluates not just syntax but content encoding in the To, From, and Subject fields. If a header uses ISO-8859-1 or lacks proper MIME charset declarations, it’s flagged as invalid—even if the email address itself is deliverable.

Bulk verification helps spot systemic encoding problems

When many addresses fail inbox placement testing, the issue isn’t always the address. Patterns often point to flawed encoding. MailTester’s bulk verification system reveals clusters of failures tied to specific header anomalies—say, a sudden spike in rejections only affecting messages with special characters in the To field.

This helps you identify root causes: are you using legacy systems that output non-UTF-8? Is your template engine not sanitizing or encoding output correctly? These issues can go unnoticed until you run inbox placement tests. As the IETF notes in RFC 2047, encoded words in headers must follow strict formatting—non-compliant values break SMTP processing and trigger filters like Gmail’s.

By combining real-time API checks with bulk inbox testing, you don’t just validate addresses—you validate the entire message envelope. If you’re seeing unexpected rejections, especially with DKIM-signed emails, encoding in headers is often the silent culprit. Use inbox placement testing to confirm whether UTF-8 compliance is the fix your campaign needs.

DKIM and UTF-8: the standard, not the exception

Using non-UTF-8 encoding in the To header of a DKIM-signed email breaks RFC 6376, the official DKIM standard. Gmail and other major providers reject such emails not because they’re "too strict," but because the headers are technically invalid. UTF-8 is required for all unencoded headers—supporting anything else is a misconfiguration, not a feature. You must fix this at the sending source.

The Technical Foundation: What RFC 6376 Actually Says

  • Draft RFC 6376 (DKIM) mandates that all unencoded headers—including To, From, Subject—must use UTF-8. This is not optional.
  • If your email uses ISO-8859-1, Windows-1252, or any non-UTF-8 encoding in the To header, it fails the DKIM signature validation, even if the signature itself is mathematically correct.
  • Gmail and other major providers enforce this rule rigorously. A failed DKIM check due to header encoding is not a "gray area"—it’s a hard rejection.
  • Non-UTF-8 headers may pass basic syntax checks in some systems, but they violate the standard and will not be accepted by compliant mail transfer agents (MTAs).

Why “It Works Somewhere” Is a Misleading Excuse

  • Some older or misconfigured mail systems may accept non-UTF-8 headers without complaint—this doesn’t make it correct, only inconsistent.
  • These systems aren’t enforcing the standard; they’re bypassing it. Relying on this behavior is a liability, especially when sending at scale.
  • You can verify the expected behavior by testing your messages against RFC-compliant environments, such as those run by IETF or MXToolbox.
  • Fixing the underlying encoding mismatch at the application or email service level is the only sustainable solution. Automated tools won’t help if the source sends malformed data.

Let’s be clear: encoding issues are not “edge cases.” They are violations of the protocol. If your email client or platform outputs To headers with non-UTF-8, you’re not optimizing—you’re breaking the system. Use UTF-8 universally, especially in DKIM-signing contexts. Your deliverability depends on it.

If you're sending emails at scale and want to catch malformed headers before they go out, you can test your list’s reliability with bulk verification—our tool checks for common issues, including non-compliant header encoding.

Gmail’s approach to DKIM and header integrity

Gmail validates every DKIM signature in full, including the header checksum. If the To: header isn’t encoded in UTF-8, even slightly misaligned, the signature fails — and Gmail rejects the email. No exceptions. Signed content must be intact. Integrity over convenience.

DKIM signing checks the exact header content

DKIM signs specific headers, like To:, From:, and Subject:, using a cryptographic hash. Gmail doesn’t accept deviations — even if the body is valid, a non-UTF-8 To: header breaks the checksum. This is by design: if headers are modified, the signature should fail.

Let’s say you send a message with a To: header that uses ISO-8859-1 instead of UTF-8. The byte sequence differs. DKIM’s hash now doesn’t match. Gmail sees that and drops the message — not because of content, but because of integrity violation.

There are no loopholes for signed messages

Gmail doesn’t allow exceptions. Even if you’ve set up SPF, DKIM, and DMARC correctly, a malformed header encoding breaks the chain. The signature is valid only if the entire signed header set is transmitted exactly as signed.

This rule is enforced consistently across Gmail’s infrastructure. The RFC 6376 specification (the standard for DKIM) mandates this level of integrity. RFC 6376 defines the signed header fields and requires byte-identical transmission. Gmail follows this strictly.

Many senders assume DKIM is forgiving. It is not. A single byte difference — like a missing BOM, or an incorrectly encoded accent — can invalidate the signature. This is why tools that verify email headers before sending are essential.

You can prevent these errors by validating your email headers during composition. Use an inbox-placement test to detect these subtle issues before sending to real users. Test inbox placement with real email clients, including Gmail, to catch header encoding problems early.

Proactive testing with inbox placement tools

MailTester’s inbox placement testing mimics the actual delivery path Gmail and Outlook use, catching encoding issues like non-UTF-8 To headers before they trigger rejections or damage sender reputation. Unlike passive checks, it simulates real inbox conditions—headers, authentication, and content—so you fix problems before they hurt deliverability.

How real inbox testing uncovers hidden issues

When you send an email, Gmail doesn’t just check SPF or DKIM—it validates every part of the message, including headers. A To header with non-UTF-8 encoding may not break the message format, but Gmail may reject it silently or flag it as suspicious. MailTester’s inbox placement tool sends test messages through real email infrastructure and logs how each email is processed, including header validation.

These logs include detailed inspection of all headers, showing exactly where encoding fails. For example, a To header with a non-UTF-8 character like "ü" sent without proper charset declaration will appear in the log as malformed, pinpointing the exact issue. You can see whether the problem lies in your email client, template engine, or content management system.

Tools that only validate syntax miss these subtle but critical failures. By testing inside Gmail’s actual delivery pipeline, MailTester reveals exactly how your message behaves in production—not in theory.

Fast root cause analysis with actionable logs

Unlike black-box tools that only say “message blocked,” MailTester gives you full header validation logs. You’re not left guessing. The logs show the exact moment of failure—whether it’s a malformed To header, an invalid DKIM signature, or a missing encoding directive.

These logs aren’t just for diagnostics—they’re part of a real workflow. You can use them to audit your sending stack, validate templates, or onboard new team members. When a campaign fails to deliver, you can pull the test log and see not just “why it failed,” but “where and how” it failed.

For instance, if your newsletter sends to a high-volume list and some emails bounce mysteriously, this kind of data lets you isolate whether the issue is encoding, DNS, or a server-side filter. The same applies to campaigns using dynamic content or localization, where character encoding is easy to overlook. Proper UTF-8 handling is standard in SMTP and RFC 5322—but it’s often not enforced in the tools that generate the email.

Proactive testing isn’t just about avoiding bounces. It’s about protecting your sender reputation. A single unverified header issue can trigger temporary blocks or long-term filtering.

To test your email’s inbox placement today—see how your messages are treated by real platforms like Gmail and Outlook—run a test at MailTester’s inbox tester.

How to integrate encoding checks into your workflow

You can prevent Gmail from rejecting DKIM-signed emails due to non-UTF-8 To headers by validating header encoding before sending. Use the MailTester API to check email headers in real time, catch invalid encodings early, and correct them before they hit the wire. This stops bounces and deliverability issues before they happen.

Real-time validation in your SMTP pipeline

  • Integrate the MailTester Verification API directly into your SMTP sending workflow to validate header encoding before dispatch.
  • Pass the raw email header data to the API—especially the To, From, and Subject fields—to detect non-UTF-8 encodings that trigger Gmail’s rejection of DKIM-signed messages.
  • Use the API’s response codes to automate rejection or sanitization: invalid encoding? Rewrap the header in UTF-8 before sending.
  • Connect MailTester to SendGrid, Mailchimp, HubSpot, or Klaviyo via their native webhooks or API layers to validate every outbound email automatically.
  • Set up pre-send checks in your transactional or marketing flows—catch encoding issues in testing and production without modifying your core delivery pipeline.
  • Even with high sender reputation, UTF-8 issues in headers can break DKIM alignment; catching them early prevents sudden drops in inbox placement.

Quick debugging with the in-app AI assistant

  • Paste a raw email header (including the To line) into the MailTester email checker to instantly surface encoding problems.
  • The in-app AI assistant will flag non-UTF-8 fields, suggest fixes, and show which part of the header is invalid—no deep protocol knowledge required.
  • This tool works for both bulk campaigns and individual debug sessions, reducing trial-and-error time by focusing only on actual issues.
  • For complex cases, consult the IETF RFC 6854, which defines how email header encoding should be handled in non-ASCII environments.

Encoding errors in To headers are a known cause of DKIM rejection. The fix isn’t in the DKIM signature—it’s in making sure the header fields carry UTF-8 content. Let MailTester enforce that rule before you send.

Conclusion: Encode everything in UTF-8 — every time

Non-UTF-8 encoded To headers in DKIM-signed emails break authentication, leading to immediate rejection by Gmail. This isn’t a theoretical risk — it’s a recurring issue in systems that neglect proper encoding at the header level.

These problems often go unnoticed until bounces rise or inbox placement drops. The fix is simple: enforce UTF-8 across all email fields, especially those involved in DKIM signing.

Verification tools and inbox testing uncover such flaws early. They prevent damaged sender reputation and costly deliverability issues before they impact real users.

Sources

Keep reading

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

Frequently asked questions

Does Gmail reject all non-UTF-8 headers in DKIM-signed emails?

Yes. Gmail enforces RFC 6376 and requires UTF-8 encoding for all header fields involved in DKIM signing, including To, From, and Subject.

Can I still send emails with non-Latin characters if headers aren’t UTF-8?

No. Even with non-Latin characters, headers must use UTF-8 encoding to pass DKIM validation in Gmail.

Does DKIM validation happen before or after the message is accepted?

It happens after message acceptance, but during final processing. Failure can result in silent rejection.

How do I check if my To header is UTF-8 encoded?

View the raw message source. If the To header appears as `=?UTF-8?B?...?=` or similar, it’s correctly encoded. Otherwise, it’s invalid.

Can I fix a DKIM signature after it’s been created?

No. Recreating the signature requires resending the message with corrected headers. The original signature is invalid.

Why don’t I get a bounce message when Gmail rejects my DKIM-signed email?

Because the failure occurs during DKIM validation, which happens internally. There’s no SMTP error code or bounce returned.

Does MailTester support real-time DKIM header testing?

Yes. The MailTester API validates headers, including encoding, during real-time verification and inbox placement tests.

Is UTF-8 encoding required for all email headers?

Yes, for standards compliance. While some systems may accept non-UTF-8, major providers like Gmail enforce UTF-8 for signed headers.

Can a role account cause DKIM rejection?

Not directly. However, role accounts (e.g. info@) may be flagged by Gmail if they receive low engagement. Encoding issues are unrelated.

What happens if I send a message with a signed but malformed To header?

Gmail will reject it silently. The signature fails, and no delivery or notification is issued.

How can I avoid encoding issues in automated email sends?

Use tools like MailTester to validate headers before delivery. Integrate verification into your workflow.

Does MailTester catch non-UTF-8 encoding during bulk verification?

Yes. It checks header integrity in bulk and highlights encoding issues across your list during inbox placement testing.