What happens when DKIM verification fails?

You send an email from a trusted domain. The headers look clean. The content is on-brand. Yet it lands in spam—or worse, vanishes entirely. Why?

One common culprit hides in plain sight: encoding. When email headers use ISO-8859-1 instead of UTF-8, DKIM verification can fail—even if the rest of the message is valid. And when DKIM fails, the email gets treated as suspicious by modern filtering systems.

DKIM is a cryptographic check that confirms an email was genuinely sent from an authorized domain. It signs a subset of the email’s header and body. If the signature doesn’t match the content, verification fails. And when that happens, even legitimate messages may be blocked, quarantined, or tagged as spam.

Key takeaways

  • DKIM failure can occur even with valid messages when header encoding uses ISO-8859-1 instead of UTF-8.
  • DKIM relies on exact byte-level matching; encoding mismatches break the signature verification.
  • Fixing header encoding to UTF-8 prevents subtle but critical DKIM verification failures.

Why does using ISO-8859-1 break DKIM signatures?

DKIM signatures rely on a consistent, byte-for-byte interpretation of header fields during canonicalization. When you use ISO-8859-1 encoding—especially for non-ASCII characters—the byte representation differs from UTF-8, causing the signed header to diverge from what the receiving server re-computes. Even a single misencoded character breaks the signature, leading to rejection. This is why UTF-8 is not just preferred but required for reliable DKIM validation.

DKIM’s dependency on consistent header interpretation

DKIM signs a specific, canonicalized version of an email’s headers. That process assumes all characters are interpreted the same way across signing and verification. If the sender uses ISO-8859-1 and the receiver expects UTF-8 (which is the norm), the same character (like an accented letter) can map to different byte values. This inconsistency means the signature checks fail, even if the message content is otherwise valid.

The problem with ISO-8859-1 in modern email systems

ISO-8859-1 only supports basic Western European characters and encodes them as single bytes. It doesn’t handle multilingual text, emojis, or complex scripts. When a header field like Subject includes a non-ASCII character—say, “Café” encoded in ISO-8859-1—the bytes don’t represent the same Unicode code point as when UTF-8 is used. This mismatch alters the canonicalized header, invalidating the DKIM signature.

UTF-8, by contrast, unambiguously encodes all Unicode code points with a variable-length scheme. It’s the only encoding recognized across modern email systems and required by the standards. As outlined in RFC 6376, DKIM assumes UTF-8 for header and body content to ensure interoperability.

Let’s be clear: using ISO-8859-1 isn’t a minor quirk—it’s a direct cause of DKIM failure. If your email system ever logs a “DKIM signature verification failed” error and you’re using non-UTF-8 encoding, that’s likely why. The same applies to any automated email sender or mailing platform that processes headers without enforcing UTF-8.

If you’re sending to international audiences or handling multilingual data, ensure your email templates and mail servers default to UTF-8. You can validate this before sending by testing your message structure and encoding with tools that simulate real inbox behavior. For example, test inbox placement across real mail providers to catch encoding issues before they impact deliverability.

How does email header encoding affect DKIM signing?

DKIM signing requires headers to be normalized using UTF-8. If your email headers use ISO-8859-1 instead, even a single byte difference during parsing breaks the cryptographic match between the signed and received headers—causing verification to fail, regardless of domain setup or sender reputation.

The core rule: UTF-8 is mandatory

According to RFC 6376, the DKIM specification explicitly requires that all headers be normalized using UTF-8. This isn’t a suggestion—it’s a cryptographic necessity. When a DKIM signature is generated, the headers are processed as UTF-8 text. If the receiving server interprets those same headers with a different encoding like ISO-8859-1, the byte stream changes, even if the visible characters look identical.

Let’s say you have a header like “Subject: Résumé”. In UTF-8, the é is a two-byte sequence (0xC3 0xA9). In ISO-8859-1, it’s a single byte (0xE9). That one-byte difference alters the entire hash value used in the DKIM signature. No matter how valid your domain or SPF setup is, the signature will fail because the signed data and the received data don’t match.

Even if only one header—like From, Subject, or Date—is encoded incorrectly, the entire DKIM verification fails. This is true even if the email renders correctly in a client. The signing process is strict: what you sign must be byte-for-byte what gets verified.

Why most tools don’t catch this

Most email testing tools focus on syntax, format, or basic validity—not encoding mismatches. They might tell you your From header looks fine, but they won’t flag that your server sent it in ISO-8859-1 while DKIM expects UTF-8. This gap makes DKIM fails hard to diagnose.

That’s why using a service like MailTester’s real-time email checker helps: it simulates how real receiving servers interpret headers and can flag encoding issues before they impact deliverability. It doesn’t just verify if an address exists—it checks whether your message structure aligns with the standards that govern authentication.

For mailers sending bulk email, running full list verification through MailTester’s bulk verification tool uncovers inconsistencies across large volumes, including hidden encoding issues in headers that are often missed by standard validation. Encoding errors like this aren’t flagged in most spam or DNS checks—they only surface during DKIM validation, and only when the data doesn’t match.

Bottom line: if you’re sending headers in ISO-8859-1, DKIM will fail. If you’re not using UTF-8 consistently across all header fields, you’re breaking a hard rule. Fixing it means ensuring your email infrastructure treats all headers as UTF-8—no exceptions.

What kinds of headers are most affected by encoding issues?

Headers with non-ASCII characters—especially in subject lines, sender names, or recipient fields—are most likely to break DKIM when encoded in ISO-8859-1 instead of UTF-8. Without proper encoding, the signature verification fails silently, even if the message reaches the inbox. This is common when email clients default to ISO-8859-1, which lacks full support for emojis, accented names, or non-Latin scripts.

Which headers fail silently under incorrect encoding?

  • Subject lines containing emojis, accented characters (like café or naïve), or non-Latin scripts (e.g. Japanese, Arabic, Cyrillic) are often misencoded and cause DKIM signature failure if not explicitly set to UTF-8.
  • From, To, or Cc headers with personal names using non-ASCII characters—like Müller, Sánchez, or Иванов—fail DKIM if the encoding isn’t UTF-8. These names are commonly misencoded when systems default to ISO-8859-1.
  • Headers that lack explicit Content-Transfer-Encoding or charset declarations risk being interpreted as ISO-8859-1 by servers, leading to byte-level mismatches that invalidate DKIM signatures.
  • Messages sent in legacy systems or poorly configured email builders often default to ISO-8859-1, especially when no charset is specified. This leads to silent failures where the email delivers, but the signature checks fail.
  • Many email clients and routing systems assume UTF-8 only when explicit, so relying on defaults is risky. According to RFC 2047, proper header encoding requires explicit MIME handling—most fail to do this correctly.
  • Always set Content-Type headers with charset=utf-8. Use text/plain; charset=utf-8 or text/html; charset=utf-8 explicitly, not just relying on defaults.
  • Use =?UTF-8?B? or =?UTF-8?Q? encoding for non-ASCII parts in headers like From or Subject. This is required by the MIME standard to ensure integrity across systems.
  • Validate your email encoding stack using tools that simulate real-world sender behavior. Try an inbox placement test before sending to ensure signatures don’t fail due to encoding mismatches.
  • Use a real-time email verification API to catch encoding-related issues early. It checks not just syntax, but also how headers are processed by mail servers. Verify sender headers and content encoding before sending.
  • Review logs from your email service provider. Look for DKIM fails with no clear error—these are often encoding-related and not caught by basic validation tools.

DKIM fails when headers using ISO-8859-1 are canonicalized incorrectly, because the signature is computed over raw byte values—not decoded text. If your email’s headers contain non-UTF-8 characters and aren’t properly normalized before signing, the receiving server will see a mismatch during verification. The key is to inspect the raw DKIM-Signature header and confirm that all signed headers match their decoded values. Tools like MxToolbox or Google’s Mail-Tester can help you validate this.

Step-by-step detection process

  1. Fetch the raw email header output — extract the full message, including the DKIM-Signature field, from your email server, ESP, or testing tool. Look for entries like a=rsa-sha256 and b=... — these confirm DKIM was applied.
  2. Inspect the h= field in DKIM-Signature — this lists which headers were included in the signature. Headers like From, To, Date, or Subject are common. Any non-UTF-8 text in these fields can trigger miscalculation during canonicalization.
  3. Decode headers using ISO-8859-1 vs. UTF-8 — compare the actual text in headers to their decoded form when using each encoding. If a header contains a character like “é” or “ñ” and is sent in ISO-8859-1 but interpreted as UTF-8 during signing, the resulting hash will not match.
  4. Verify canonicalization with a third-party tool — use MxToolbox or MailTester’s inbox placement test to analyze the raw header. These tools will show you how the receiving server interprets the header values during DKIM validation, including encoding assumptions.
  5. Check for discrepancies between raw and decoded values — if the actual header text differs from what the receiving server expects after canonicalization (e.g., a character is shifted or garbled), DKIM will fail even if signatures are mathematically correct. This usually happens with poorly standardized email clients or legacy systems.

Common signs of encoding issues

  • DKIM passes for some recipients but not others — inconsistent failures across domains suggest encoding misinterpretation.
  • Signed headers show garbled characters, like é instead of é — this indicates UTF-8 decoding has been applied incorrectly to ISO-8859-1 data.
  • SPF and DMARC pass but DKIM fails — this isolates the problem to signature generation, not sender authentication.

According to RFC 6376, DKIM signatures must be computed over a canonicalized form of the headers, which depends on consistent encoding. If a header field contains multibyte characters and the encoding is not accounted for during canonicalization, the signature will not validate.

How to fix encoding issues before sending

DKIM fails when headers use ISO-8859-1 instead of UTF-8 because DKIM signs the raw header content. If the charset differs from what the signature expects, the hash won’t match, and the validation fails. Always set the MIME charset explicitly to UTF-8 in the email header using Content-Type: text/plain; charset=utf-8, and ensure your sending system generates headers in the same encoding. Otherwise, the signature is valid only for the original byte stream—not what the receiver processes.

Set the correct charset at the source

  • Explicitly define UTF-8 in every email’s Content-Type header: text/plain; charset=utf-8 or text/html; charset=utf-8. Never rely on defaults.
  • Ensure your email client, ESP, or template engine defaults to UTF-8 when generating headers. Many legacy systems still output ISO-8859-1 by default, especially in non-English markets.
  • Test headers with a tool like RFC 2047 compliance checkers to verify encoding consistency in MIME-protected fields like From, Subject, and To.

Verify the full email stack before sending

  • Before sending, validate the entire email as it will be delivered. Check that all headers and body content use UTF-8 consistently, especially in multilingual campaigns.
  • Use real-time email verification to catch encoding mismatches early. Tools like the MailTester API inspect the full message format, including headers, and flag inconsistencies that can break DKIM.
  • For bulk sends, run a bulk verification on your list first, including encoding validation, to ensure no addresses will trigger delivery failures due to malformed headers.
  • Check inbox placement across multiple providers using inbox placement testing to simulate real-world delivery and confirm that DKIM remains valid and the message renders correctly.

DKIM signing depends on exact byte streams. A mismatch in charset between signature and content breaks it. Prevent this by enforcing UTF-8 at every layer: in headers, in the body, and during signature creation. As RFC 6376 states, “the signer must ensure that the canonicalization process preserves the intended content.” Encoding errors break that guarantee.

You don’t need to guess why DKIM fails—MailTester’s inbox-placement tests and real-time API validate full email headers, including character encoding. When headers use ISO-8859-1 instead of UTF-8, DKIM signatures can break during verification, especially with internationalized domains. MailTester flags these issues upfront, so your messages don’t fail silently in the wild. Let’s walk through how.

Full header validation catches encoding mismatches early

DKIM relies on signed headers being identical in both the signature and the message as delivered. If a header uses ISO-8859-1 encoding—common in older systems but problematic for non-ASCII content—it can alter the signature’s hash. This mismatch leads to a DKIM failure even if the email is technically valid. RFC 5322 and RFC 6376 define how headers must be interpreted, and non-compliant encodings fall outside those standards. MailTester’s inbox-placement tester simulates real inbox behavior, checking headers against actual delivery rules, including encoding compliance.

Real-time checks and bulk verification reveal hidden risks

Our real-time verification API evaluates every part of an email’s structure, including the Content-Type and Subject header encoding. If a header is marked as ISO-8859-1 but contains Unicode characters, it’s flagged as risky. Same for headers with malformed encoding declarations. This prevents bulk sends from being rejected by DMARC or DKIM policies downstream. In bulk list verification, we identify addresses that might trigger technical failures due to malformed input—before you even send.

When a DKIM test fails, the inbox-placement tester shows exactly where it broke. The full header report includes encoding details, showing you how ISO-8859-1 caused a signature mismatch. You’re not left with a silent “failed” result. Our in-app AI assistant goes further: it explains why the failure occurred, highlighting encoding patterns and suggesting corrections. This isn’t guesswork—it’s structured analysis based on real SMTP behavior.

Why UTF-8 is not just a recommendation—it’s required

DKIM fails when email headers use ISO-8859-1 instead of UTF-8 because RFC 6376 explicitly requires all header fields to be canonicalized in UTF-8 before signing. Using any other encoding—even one widely supported like ISO-8859-1—breaks the standard and invalidates the signature. Even if the email displays correctly in your inbox, the receiving server silently rejects the DKIM check, damaging your sender reputation. This isn’t a corner case—it’s a core requirement for any authenticated, deliverable email.

The standard is clear: UTF-8 is mandatory

Let’s be precise: DKIM’s canonicalization process, defined in RFC 6376, mandates that all header fields be converted to UTF-8 before hashing. If you send headers in ISO-8859-1, the resulting hash will differ from what the receiving server expects. The signature is then considered invalid, regardless of whether the message content or recipient address is correct.

This is not a configuration quirk. It’s a protocol-level rule. The RFC doesn’t say “recommend” or “prefer”—it says “must.” Any deviation, whether intentional or accidental, breaks the authentication chain. If your email infrastructure assumes ISO-8859-1 is acceptable, it’s already non-compliant.

Why failure happens silently

Here’s the problem: a DKIM failure doesn’t always result in a bounce or error report. Many mail servers log the failure internally but still accept the message. This gives a false sense of success. You may see no delivery issues, yet your messages are marked as unauthenticated by receiving systems. Over time, this hurts inbox placement and damages your sender reputation.

Even if your email client renders the text correctly—because it interprets ISO-8859-1 properly—the canonicalization step used by the receiving server treats that same text as a different string, leading to mismatched hashes. The signature fails, no matter how well the message displays.

It’s worth noting that modern email systems expect UTF-8 by default. Standards bodies, including IETF, have long since moved toward UTF-8 as the base encoding. You can verify your headers’ encoding with tools like RFC 6376 or test the actual content of your email using an inbox placement tool that checks the raw header signature.

Preventing this issue starts with ensuring your email system, templates, and sending library all default to UTF-8. If you’re using third-party tools or code to generate messages, validate that encodings are explicitly set to UTF-8, not inferred from locale or legacy settings.

Before sending to a high-volume list, run a real-time email verification check to catch syntax and encoding issues early. Use our email checker to test individual addresses or bulk verify your list for issues that could cause DKIM to fail—including improper encoding during transport.

Can ISO-8859-1 ever be used safely in email headers?

Yes — but only if no non-ASCII characters appear in the header fields. Even then, using ISO-8859-1 is risky. Modern email systems expect UTF-8. If your headers contain any special characters — accents, emojis, non-Latin scripts — ISO-8859-1 will fail silently or corrupt data during transit. Stick to UTF-8 unless you’re certain the entire delivery path will preserve ISO-8859-1 without conversion.

Why UTF-8 is the only reliable choice today

Let’s be clear: ISO-8859-1 isn’t designed for international text. It supports only Western European characters. When you send headers with non-ASCII content using ISO-8859-1, you risk misencoding at any point in the chain — especially when passing through intermediary MTAs or email gateways. These systems often normalize to UTF-8, leading to garbled or truncated headers.

Even if your template engine defaults to ISO-8859-1, that’s not an excuse. The email industry has standardized on UTF-8 for decades. The IETF’s RFC 6376 (which defines DKIM) assumes UTF-8 for header normalization. If your headers are encoded in ISO-8859-1, the DKIM signature verification will fail — even if the content is otherwise correct. This isn’t a minor glitch. It breaks authentication.

Real-world consequences in delivery and reputation

When headers are encoded inconsistently, it’s not just about DKIM. Bounces, blacklisting, and inbox filtering can all be influenced by encoding mismatches. A badly encoded header might be caught by spam filters that detect anomalies in message structure. You don’t get a warning — only a failure, often untraceable without deep debugging.

Even if your headers appear fine in your testing environment, the moment they hit a different MTA or client, things can go wrong. A server in Tokyo may interpret ISO-8859-1 differently than one in Berlin. This lack of consistency undermines reliability. The modern email ecosystem assumes UTF-8 across the board — and for good reason.

If your email service provider or template system defaults to ISO-8859-1, it must be corrected before sending. You can’t rely on luck. Tools like MailTester’s email checker can help spot issues early — not just invalid addresses, but malformed headers that might lead to delivery problems or authentication failures.

Remember: consistency is key. Using UTF-8 prevents silent failures, ensures compatibility across systems, and keeps your sender reputation intact. It’s not just a best practice — it’s required for reliable delivery.

Common mistaken beliefs about DKIM and encoding

DKIM doesn’t tolerate encoding differences—using ISO-8859-1 instead of UTF-8 in headers breaks the signature because DKIM signs the exact byte sequence. Even one byte mismatch invalidates the signature, regardless of whether the email renders correctly in the inbox. The content and headers are signed separately, so UTF-8 must be used everywhere.

DKIM's sensitivity to header encoding

Many assume that minor encoding differences don't affect DKIM. They’re wrong. DKIM signs the raw header bytes exactly as they appear. If your email uses ISO-8859-1 for headers while the signing algorithm expects UTF-8, the signature fails—even if the email looks fine in the recipient's client.

It's a common mix-up because rendering engines are forgiving, but authentication is not. A correctly displayed email doesn’t mean DKIM passed. The receiver checks the cryptographic signature against the raw data, byte for byte.

Correct encoding isn’t optional—it’s required

Setting only the body to UTF-8 is not enough. DKIM signs both headers and body. Headers must be in UTF-8 during signing. According to RFC 6376 (the standard for DKIM), the header content must be encoded in UTF-8 before signing.

Tools like MailTester can help catch this misalignment early. Before sending, test your email headers and body encoding using inbox placement testing, which checks real-world delivery and signing behavior across providers.

Misconception Reality
Dkim can tolerate small encoding differences One byte difference due to misencoding breaks the signature. DKIM signs exact byte sequences.
Correct display means DKIM is working Rendering and signing are separate. A properly displayed email can still fail DKIM validation.
Only the body needs to be UTF-8 Headers must also be UTF-8. DKIM signs headers independently of the body.

For more on how email systems validate authenticity, see the DKIM specification in RFC 6376. The same standard confirms that all signed components must use consistent encoding to preserve signature integrity.

The real cost of ignoring encoding in DKIM

When email headers use ISO-8859-1 instead of UTF-8, DKIM signatures can fail silently. Even minor encoding mismatches disrupt cryptographic validation, leading to authentication failures that mail servers interpret as malicious intent.

These failures don’t just cause bounces—they harm sender reputation. Legitimate senders experience inbox placement drops below 70% and may be flagged by spam filters or blacklisted. Recovery requires days, sometimes weeks, especially if filters treat the issue as a sign of compromise.

Every misconfigured header is a step toward reduced deliverability. Preventing these issues starts with consistent, correct encoding from the first byte.

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 DKIM only fail if the body uses ISO-8859-1?

No. DKIM fails when any signed header is encoded incorrectly. The Subject, From, or To fields using ISO-8859-1 will cause signature mismatches even if the body is UTF-8.

How can I test if my DKIM signatures are valid?

Use tools like MxToolbox or MailTester’s inbox-placement testing. They analyze raw headers and validate DKIM signatures against the full email content.

Is UTF-8 required in all email fields?

Yes. RFC 6376 requires UTF-8 for all header fields used in DKIM canonicalization. Using other encodings breaks the signature.

Why does ISO-8859-1 still appear in some email systems?

Legacy systems or poorly configured email clients may default to ISO-8859-1. These systems often fail to set proper Content-Type headers, leading to misencoding.

Can a mail server fix ISO-8859-1 encoding automatically?

No. Once data is misencoded, re-encoding during transit does not fix DKIM failures—authentication is based on the signed and sent version.

What happens if DKIM fails but SPF and DMARC pass?

The email may still be marked as suspicious. Recipients often use multiple authentication checks; a single failure can impact inbox placement.

Do tools like MailTester detect encoding issues?

Yes. Our inbox-placement and real-time verification tests analyze email headers and detect encoding mismatches that can break DKIM.

Is there a way to catch this problem before sending to a large list?

Yes. Use MailTester’s bulk verification API to check the entire list and ensure all messages meet delivery standards—including proper encoding.

Why does MailTester claim 98.9% accuracy?

The accuracy includes detection of invalid addresses, catch-all scenarios, and technical red flags like encoding issues that affect deliverability.

Does MailTester integrate with SendGrid or HubSpot?

Yes. We support real-time verification and inbox-placement testing via integrations with SendGrid, HubSpot, Mailchimp, and Klaviyo.