Why does DKIM fail when your domain contains non-ASCII characters?

You sent a message from a domain like example.公司, and it bounced with a DKIM signature failure — even though the email looked correct. You double-checked your DNS, the key, the selector. Everything seemed right. So why did it fail?

Because your domain uses non-ASCII characters, and DKIM’s validation process treats Unicode and Punycode as different domains. If your DNS records use the encoded form (xn--example-8ua) but your DKIM signature references the original Unicode version, the signature will not align. The validator sees two different domains — and rejects the message.

DKIM expects consistency. If the domain in the signature header isn’t an exact match to the domain in the DNS TXT record, the check fails. This is especially common with internationalized domains (IDNs) that rely on Punycode encoding. Many systems assume ASCII-only inputs, and when they receive non-ASCII content in the wrong place, they cannot validate. This isn’t a bug — it’s a mismatch in expectation. The fix lies in precise configuration, not just in the key, but in how the domain appears across the mail chain.

Key takeaways

  • DNS TXT records for DKIM must use the Punycode version (e.g., xn--example-8ua) of an internationalized domain, not the Unicode form.
  • DKIM signature verification fails if the domain in the signature header does not exactly match the domain in the DNS record, even for IDNs.
  • Tools that validate DKIM signatures should be configured to process and compare domain labels in Punycode to avoid false failures on non-ASCII domains.

What does a non-ASCII DKIM failure look like in practice?

You send an email from support@मोबाइल-पेमेंट.कंपनी, and while SPF and DMARC pass, DKIM fails with a "signature verification failed" error. The receiving server sees the domain in the DKIM-Signature header as punycode (xn--mobil-pemt-jla.company) but tries to validate it against the plain Unicode form, causing a mismatch. This happens because the DKIM public key is published under the wrong domain format.

How the failure reveals itself in real logs

Let’s say you send a message from a domain using non-ASCII characters — like भारतीय-ईमेल.कॉम. The DKIM signature header will include the domain in Punycode, such as xn--bhrty--ml-zca.company. But unless the DNS TXT record for that exact Punycode form exists, the verifier can't find the public key.

Most email servers follow RFC 6376, the standard for DKIM, which requires the domain in the dkim-signature header to match exactly with the one in the DNS lookup. If the public key is published only under the Unicode version, validation fails — even if all other authentication checks pass.

Why DNS and DNS lookups get confused by non-ASCII domains

DNS doesn’t natively support Unicode. So any non-ASCII domain is converted to Punycode before being stored and queried. The key insight: the DKIM public key must be published using the Punycode form. If you only publish it under the human-readable Unicode form, it won’t be found.

This mismatch is common with domains using Arabic, Cyrillic, Chinese, or Devanagari scripts. It’s not a flaw in DKIM — it’s a system-level requirement. Without proper Punycode alignment in DNS, even well-formed signatures fail validation, leading to misclassified spam or bounced mail.

For example, if you’re using a third-party email service, it may auto-generate the DKIM signature using the domain in its internal representation. But if the DNS key is not published in the same form, the server won’t find it. The result? A clean SPF and DMARC pass, a DKIM failure — and no way to tell if the message was valid.

MailTester’s inbox placement and deliverability test lets you verify the full authentication state of any email address, including real-time checks across major providers. If you’re dealing with non-ASCII domains, it can catch signature mismatches before they reach the inbox.

For developers or admins, tools like RFC 6376 and IDNA tables define the exact rules for Punycode conversion. Always test your DKIM setup using the Punycode version of your domain in DNS records.

Ultimately, a non-ASCII DKIM failure isn’t about the signature being wrong — it’s about the key being unreachable. The fix? Ensure your DNS TXT record for DKIM matches the Punycode version of the domain used in the DKIM-Signature header.

How to verify your non-ASCII domain setup is correct

You can verify your non-ASCII domain setup by checking that the Punycode version of your domain resolves correctly in DNS, that your DKIM selector matches exactly what’s published and used in email headers, and that your full DKIM record is valid using tools like MxToolbox or dig. Use MailTester’s real-time API to test individual addresses from your domain to confirm they resolve without issues linked to encoding.

Step-by-step verification process

  1. Convert your non-ASCII domain to Punycode. If your domain is mobil-pemt-jla.company (with umlauts or non-Latin characters), use a standard converter to get xn--mobil-pemt-jla-company-53a. This is the version that appears in DNS records.
  2. Test the DKIM record using DNS lookup tools. Use MxToolbox or dig with the Punycode domain. Query for the DKIM TXT record using the full selector, like default._domainkey.xn--mobil-pemt-jla-company-53a. Ensure the record is published and not truncated (DNS limits are 255 characters per TXT RR).
  3. Verify the selector in the email header. Open a sent message and inspect the DKIM-Signature header. Confirm the d= tag matches the actual domain (Punycode version) and the s= tag exactly matches your published selector. A mismatch here causes failure regardless of DNS setup.
  4. Check that the selector is exactly published in DNS. A small typo—like using default instead of default._domainkey—will break validation. Use RFC 6376 to verify the correct syntax for DKIM record structure.
  5. Use MailTester’s real-time verification API to test addresses. Send a sample address from your non-ASCII domain through the real-time verification API. This confirms not only that the address exists but that the full delivery path—including DKIM processing—is working as expected. This catches encoding issues during delivery that DNS alone can’t reveal.

Why this matters

Non-ASCII domains are not universally handled the same way across all email systems. If the Punycode representation doesn’t match exactly in DNS and headers, most validators will reject the DKIM signature, even if the key is correct. A single character difference causes failure, and the error is often not visible without testing with actual email traffic.

Using the API to test individual addresses helps you spot issues early—before sending to a large list. You're not just validating DNS; you're simulating real delivery. This reduces bounces, improves sender reputation, and avoids being flagged by receivers that enforce strict DKIM policies.

Common mistakes when configuring DKIM for non-ASCII domains

You’re likely failing DKIM checks for non-ASCII domains because you’re using the Unicode version of the domain name directly in DNS records, not its Punycode equivalent. This breaks the signature validation chain. Email systems expect domain names in ASCII form, and any deviation—even in the selector name or DNS record—causes validation to fail. Let’s walk through the top pitfalls.

DNS record encoding: Unicode vs. Punycode

  • Never enter a domain like пример.рф directly into your DKIM TXT record. Use the Punycode form xn--e1a4c.xn--p1ai instead.
  • Confusing Unicode with Punycode is the most common error. DNS only processes ASCII, and DKIM relies on exact matching of the domain’s public record.
  • Verify your DNS record using MXToolbox or DNS-SVCS to ensure it resolves to the correct ASCII-encoded version.

Selector mismatches and copy-paste errors

  • Many tools auto-convert Unicode to Punycode, but you must ensure the DKIM selector name matches exactly the DNS record name—no exceptions.
  • Copying a selector from a dashboard that displays the Unicode version will cause failure unless you re-encode it properly. Let’s say your selector is mail and your domain is пример.рф—the record should be mail._domainkey.xn--e1a4c.xn--p1ai, not mail._domainkey.пример.рф.
  • Always verify the full TXT record name in your DNS provider’s interface—don’t trust what a tool shows you until you check it against the actual DNS lookup.
  • Even if a client or server sees your mail in Unicode, it still validates using the DNS-stored Punycode form. Email infrastructure does not auto-convert Unicode on the fly—only the sending server must do it correctly.
DKIM validation fails if any part of the domain or selector does not match exactly in ASCII form. No exceptions.

Before sending to international domains, double-check your DKIM record with a real-time email verification tool that simulates delivery conditions. Use MailTester’s inbox placement test to verify whether your DKIM signature survives the full path to the inbox.

How DMARC checks interact with non-ASCII DKIM failures

DMARC will reject messages if DKIM fails—even if SPF passes—because DMARC requires alignment between the From header and the domain in the DKIM-Signature. For non-ASCII domains, using inconsistent encoding (like Unicode in the From header and Punycode in DKIM) breaks this alignment, causing DMARC to fail. If your DMARC policy is set to quarantine or reject, even legitimate mail may be blocked.

Why alignment matters when domains contain non-ASCII characters

DMARC’s alignment check compares the domain in the From header to the domain in the DKIM-Signature header. When a domain includes non-ASCII characters (like é, 周, or म), it must be represented consistently across both headers. The standard encoding for email headers is Punycode (e.g., xn--example-4xa.com), but if one header uses Unicode and the other uses Punycode, alignment fails.

Let’s say your From header says “noreply@example.公司”. This must be encoded as something like “[email protected]” in the DKIM-Signature header. If the DKIM-Signature uses the Unicode version instead, the domains won’t match—DMARC will fail even if encryption and signature validity are correct.

Consequences of DKIM failure in non-ASCII contexts

DMARC policies are strict: if DKIM fails, the message is rejected or quarantined, regardless of SPF status. This is true even for well-intentioned emails sent to users in non-Latin-script regions. A failure here doesn’t mean your message is spam—it just means the authentication chain broke due to encoding mismatch.

As outlined in RFC 6376 (the DKIM specification), the signature must accurately reflect the domain in its encoded form. Using tools that don’t properly normalize non-ASCII domains during signing or header processing is a common oversight. You can test whether your domain’s encoding is consistent using email deliverability test tools designed for real-world inbox placement.

For example, MailTester’s inbox placement test simulates delivery across major providers and flags alignment issues before you send to real users. It checks both the From header and DKIM domain encoding in context—helping catch inconsistencies you might miss in lab tests.

DMARC alignment isn’t a technicality. It’s the foundation of reputation systems. Even if your SPF and DMARC records are configured correctly, a single encoding mismatch in the DKIM signature can lead to delivery loss. Consistency isn't optional—it’s required.

Why most email-verification tools won't catch non-ASCII DKIM issues

Most email-verification tools only check if an address is syntactically valid and reachable—they don’t validate how the sending system encodes non-ASCII domain names in DKIM signatures or whether the DNS record uses the correct Punycode form. This means failures in internationalized domains (IDNs) often go undetected until delivery fails, even if the address itself is technically valid.

Verification tools miss the real root of DKIM failure

Standard tools focus on basic syntax, domain existence, and SMTP responsiveness. They do not inspect the alignment between the DKIM-Signature header and the public key published in DNS, nor do they confirm that the domain name used in the header matches the Punycode version in the DNS TXT record.

For example, a domain like example.中国 will appear as xn--fsq99g.cn in DNS. If your sending system uses the Unicode form (example.中国) in the DKIM-Signature, the signature will fail even if the address is real and deliverable.

Real-time testing is the only reliable fix

You can't catch this issue at signup or during list collection. DKIM signing happens at send time, and only a live test with the actual sending stack can reveal encoding mismatches.

Tools like MailTester can verify whether the underlying domain is reachable and has correct MX records, but only your email infrastructure determines if the DKIM-Signature header matches the published key. You need to test both the sending stack’s encoding and the DNS record’s form in real time.

That’s why we built inbox testing at MailTester's inbox placement tool—to simulate real delivery and catch issues like malformed DKIM signatures early.

If the domain name includes non-ASCII characters, ensure your mail server or ESP correctly encodes it in the DKIM-Signature using Punycode. The IETF’s RFC 6376 describes how DKIM signatures must map to DNS records, and compliance requires attention to encoding at every layer. When in doubt, validate through a real-time email test using a known compliant stack.

How MailTester helps verify non-ASCII domain delivery readiness

You can test non-ASCII domain email addresses for validity, detect encoding mismatches that cause DKIM signature failures, and evaluate inbox placement potential at scale using real recipient domains. MailTester’s bulk verification and inbox tests catch structural issues tied to UTF-8 encoding, domain normalization, and signature alignment — all before your messages go out, reducing bounces and improving deliverability.

Bulk verification for non-ASCII domains

  • Upload your list of email addresses from a non-ASCII domain (like naïve@example.公司) to MailTester’s bulk verification tool and receive instant results on validity, spam risk, and catch-all status.
  • Each address is checked for common encoding pitfalls — including improper IDNA encoding of internationalized domain names — which can break DKIM signatures if not handled correctly during DNS resolution and message signing.
  • High-risk cases like addresses with special Unicode characters are flagged early, helping you avoid delivery issues tied to mismatched domain representations.

Real-time inbox-placement testing

  • Use the MailTester API to run inbox placement tests on actual recipient domains, simulating real-world delivery conditions even for non-ASCII domains.
  • The API evaluates whether DKIM signatures are accepted by major inboxes (Gmail, Yahoo, Outlook) by analyzing header consistency, domain alignment, and cryptographic integrity — a step crucial when non-ASCII domains are involved.
  • Our 98.9% accuracy rate reflects our ability to detect structural flaws in email flow, including issues where domain encoding differences between sender and recipient DNS records invalidate DKIM checks.
  • Testing with real destinations prevents assumptions based on blacklists or generic rules; for example, a domain like éxample@domain.рф may resolve correctly but fail DKIM if the signature uses a different IDNA form than the one used by the verifier.

DKIM signatures rely on exact domain matching, and non-ASCII domains are especially sensitive to encoding variations. RFC 6592 and RFC 7830 define the standards for IDNA use in emails, but real-world implementations sometimes diverge. Tools like RFC 6592 provide the baseline, but testing is the only way to confirm your implementation holds under real conditions.

How to test your DKIM signature alignment before sending

You can validate your DKIM signature alignment by sending a test email, extracting the DKIM-Signature header, checking that the domain is in Punycode (like xn--example-8ua), and verifying the public key exists in DNS using the exact domain and selector from the signature. This prevents alignment failures when emails land in spam folders or get rejected.

Step-by-step DKIM verification process

  1. Send a test email through your mail server or SMTP provider. Use a real sender address and a known recipient. The goal is to capture a complete, genuine email header with a valid DKIM signature.
  2. Inspect the full email headers. Locate the DKIM-Signature field. The d= tag inside this field shows the domain that signed the message. If the domain contains non-ASCII characters (like accents, Cyrillic, or East Asian characters), it will be encoded in Punycode (e.g., d=xn--example-8ua).
  3. Copy the domain exactly as it appears in the d= field (including the Punycode prefix). Do not convert it back to Unicode. This is the exact domain you must query in DNS.
  4. Use dig TXT or a tool like MxToolbox to query the DNS TXT record for the selector and domain combination. For example: selector1._domainkey.xn--example-8ua. Ensure the record returns a valid public key and matches the one used in the signature.
  5. If the TXT record returns no data or a mismatched key, the signature alignment is broken. This is a common issue when non-ASCII domains are misencoded or when DKIM selectors are incorrect or mismatched on the server side.

Why this matters for deliverability

DKIM alignment failure is a known reason for email rejection, especially with providers like Gmail and Yahoo, which enforce strict alignment between the From domain and the DKIM d= domain. Misaligned or missing keys can trigger spam filtering rules or lead to permanent rejection.

According to RFC 6376 (the standard for DKIM), the d= domain must be publicly verifiable in DNS. A failure here often means the signature is valid but not aligned to the From address.

Use MailTester’s email checker to verify whether the sender address itself is valid and properly configured before sending. While this does not directly test DKIM, it helps rule out common sender issues early.

What to do after finding a non-ASCII DKIM failure

If your DKIM signature fails due to a non-ASCII domain context, the issue is likely a mismatch between the domain in your DNS record and the Punycode version used in the email header. Correcting this requires updating your DNS record to match the encoded form (like xn--example-tla.com) and re-publishing the DKIM key with the proper selector and domain. Re-test with a tool like MailTester’s inbox-placement API to confirm alignment and delivery success.

Step-by-step: Fixing the DKIM signature mismatch

  1. Confirm the domain format used in the email header Inspect the raw email headers to see the exact domain string used—often encoded in Punycode. For example, a domain like “café.com” appears as “xn--caf-dma.com” in the DKIM-Signature header. This is the version you must match in DNS.
  2. Update your DNS record to use the Punycode version Ensure your DKIM TXT record points to the Punycode form of the domain, not the original Unicode version. A mismatch here causes verification failure even if the key is correct. Use the Punycode specification to validate the encoding if unsure.
  3. Re-publish the DKIM key with the correct selector and domain Regenerate or re-upload your DKIM public key using the Punycode domain and the same selector. The selector must match exactly what appears in the DKIM-Signature header. Even a slight mismatch—like a capitalization difference or incorrect domain—breaks verification.
  4. Re-test using MailTester’s inbox-placement API to verify alignment Send a test message through MailTester’s inbox-placement API to check both DKIM alignment and actual inbox delivery. This simulates real-world conditions and confirms whether the fix resolved the failure. You can also verify individual addresses beforehand with the email checker if you’re testing a subset.

Why this matters

Non-ASCII domains are increasingly common, but many tools and systems still default to Unicode, causing silent failures in validation. According to IETF standards, all email systems must support Punycode for internationalized domain names, so ignoring this step undermines deliverability for a growing number of domains.

Fixing this issue isn’t just about passing DKIM—it’s about ensuring your emails are trusted across all major inboxes. A single mismatch in encoding can send your messages to the junk folder, even with a valid signature. Use the API to verify success in real conditions before deploying large campaigns.

Non-ASCII domains and sender reputation: what goes wrong

When non-ASCII domains use incorrect Unicode encoding in DKIM signatures, receiving servers see a mismatch between the domain’s actual label and the one referenced in the signature. This triggers consistent DKIM failures, even if the email content is valid. Repeated failures at scale signal poor sender hygiene, which receivers interpret as a risk — leading to throttling, temporary blocking, or reputation degradation.

Encoding mismatches break alignment

Non-ASCII domains (like example.рф or schön.de) must use IDNA encoding (Punycode) in DNS and email headers. If the DKIM signature references the original Unicode form instead of the encoded version, receivers reject it as invalid. This isn't a minor glitch — it's an alignment failure that breaks SPF/DKIM/DMARC chain verification.

Even if the email reaches the inbox, the repeated DKIM failure sends a signal to receivers like Gmail or Microsoft that your sending practices aren't consistent. According to industry standards, consistent authentication breakdowns reduce sender trustworthiness over time — and can trigger inbox placement issues, even without direct blacklisting.

Reputation damage begins early

You don’t need to be blocked to suffer harm. Most major email providers use heuristic filters that penalize senders with low authentication success rates. If 10% of your sends fail DKIM due to encoding errors, even on a small list, that data accumulates and affects your overall sending reputation.

This is especially dangerous at scale. Sending to 10,000 addresses with mismatched encoding leads to repeated failures across multiple infrastructure points. Receiving servers monitor this pattern and may impose rate limits or temporarily reject messages — not because the content is bad, but because authentication is inconsistent.

Let’s be clear: an email can be technically valid but still fail delivery due to a small but systemic encoding mismatch. The sender’s reputation doesn’t care about intent — it tracks behavior.

Prevention starts before sending. With MailTester’s bulk email verification, you can catch domains where DKIM alignment is broken before you send. It checks for valid syntax, MX records, and real domain infrastructure — including known issues around non-ASCII encoding. Screening large lists early stops reputation damage before it begins.

Final takeaway: consistency wins, even in non-ASCII contexts

DKIM and DMARC rely on pixel-perfect alignment between the domain in the From header and the one in DNS records. Even minor differences — like case variations or encoding mismatches — break validation.

Non-ASCII domains, such as those in Cyrillic or Chinese scripts, are not exempt. They must be encoded using Punycode in DNS records, and the exact same form must appear in the message header. A single character out of sync causes a signature failure.

Use MailTester’s real-time API and bulk verification to catch these errors early. Ensure consistency across your email flows, especially when supporting multilingual domains. Deliverability and sender reputation depend on it.

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 DKIM work with non-ASCII domains?

Yes, but only if the domain is consistently encoded as Punycode (xn--...) in DNS and the DKIM-Signature header. Mismatched encoding breaks validation.

How do I know if my DKIM signing uses the correct domain form?

Check the DKIM-Signature header in a sent email. It should use the Punycode version (xn--...) of your domain. Confirm this matches the DNS TXT record.

Does MailTester detect DKIM signature failures?

MailTester doesn’t directly report DKIM failures, but it verifies inbox placement and detects invalid or unreachable addresses — key indicators of underlying issues.

Why does my email pass SPF but fail DKIM with a non-ASCII domain?

SPF uses the envelope sender domain, which may be ASCII. DKIM uses the header domain, which may be encoded in Punycode. Mismatched forms cause alignment failures.

What happens if I use Unicode in a DKIM selector?

It breaks DNS resolution. Selectors must use only ASCII characters. The full domain must be in Punycode, including the selector name.

Can DNS caching cause non-ASCII DKIM issues?

Yes. Old DNS records may hold incorrect or stale Punycode versions. Clearing caches or waiting for TTL expiry helps, but proper configuration is key.

Is there a way to test non-ASCII DKIM before sending?

Yes. Use MailTester’s inbox-placement tests and real-time verification API with known addresses to validate delivery path integrity.

Do receiving servers support Punycode in DKIM?

Yes, as long as the receiving server processes the domain in the DKIM-Signature header using consistent Punycode mapping. Most modern servers do.

How does DMARC alignment fail with non-ASCII domains?

Alignment fails when the From domain (Unicode) doesn’t match the DKIM-Signature domain (Punycode). The domains are considered different, even if semantically identical.

Can I avoid non-ASCII domains entirely?

Yes, but it limits reach. Many markets use local language domains. When used, they must be handled correctly in all email infrastructure layers.

How many non-ASCII DKIM failures are due to misconfigured selectors?

The majority. Most issues arise from using Unicode in selectors or DNS records, not from the encoding itself being unsupported.

Can tools like MailTester help debug DKIM issues?

Not directly, but they help identify failed deliveries and invalid addresses early. Use real-time tests to catch failures before mass sends.