DMARC & Non-ASCII Domains

Why do non-ASCII domain characters matter in email verification?

You send a campaign to a customer in Tokyo, São Paulo, or Moscow—and the email fails to deliver. The address looks right. The domain is real. But something’s off. That’s often not a typo. It’s a non-ASCII character in the domain, like 電子メール or кириллица.

These domains work fine in browsers, but core email protocols don’t handle them directly. Instead, they’re converted to ASCII via Punycode before DNS lookup. This encoding layer is invisible to most email verification tools, creating blind spots that lead to false positives and failed deliveries.

DMARC policy enforcement relies on accurate domain matching during DNS checks. When non-ASCII domains are misencoded or unhandled properly during verification, DMARC validation fails—even though the email is legitimate. This is why understanding Punycode’s role isn’t just technical trivia—it’s critical for deliverability.

Key takeaways

Non-ASCII domains must be converted to Punycode for DNS resolution, and failure to do so causes email verification failures.
DMARC policy enforcement depends on exact domain matching in DNS, so incorrect Punycode handling leads to false negatives in validation.
Verification tools that skip or misapply Punycode encoding will report valid addresses as invalid, harming sender reputation and inbox placement.

What is the role of DMARC in verifying email addresses with non-ASCII domains?

DMARC doesn’t validate non-ASCII domain characters directly—it relies on DNS resolution of the domain in Punycode format, which is how internationalized domains are encoded for email systems. As long as the domain’s DNS records (SPF, DKIM, DMARC) are correctly published in their Punycode form, DMARC enforcement treats the domain as valid regardless of its original Unicode representation.

How DMARC interacts with internationalized domains

When you verify an email address with a non-ASCII domain—like 例子@域名.中国—the domain is first converted to Punycode: 例子@xn--8ws00zhy3a.com. DMARC policy enforcement operates on this encoded form. The key point is: DMARC doesn’t parse the original Unicode characters. It only checks whether the DNS records for the Punycode version are properly configured.

Let’s say your domain is example.中国. For DMARC to enforce properly, the TXT records for example.中国 must be published as example.xn--8ws00zhy3a.com in DNS. If they’re missing or misconfigured in that form, DMARC fails—not because the characters are non-ASCII, but because the DNS resolution path is broken.

This is why email verification services like MailTester check the Punycode form during SPF, DKIM, and DMARC validation. We ensure that even if a domain uses non-ASCII characters, the authentication frameworks still work as expected. The underlying email system treats everything in DNS as Punycode, so that’s what you must verify.

For a deeper dive into how IDNs (internationalized domain names) are resolved in email systems, see the IETF RFC 6876, which defines the handling of Unicode in email addresses.

What this means for email verification

DMARC policy enforcement doesn't care if the domain uses Cyrillic, Han, or Devanagari letters. It only cares that the DNS records for the Punycode form are present, correctly formatted, and aligned with the sending source.

That’s why tools like MailTester’s bulk verification don’t just check for validity—they test whether all authentication layers (including DMARC) are active on the actual domain record, regardless of character set.

If your list includes non-ASCII domains, don’t assume DMARC is “working.” Verify it’s published correctly in Punycode. A missing or misaligned record in that format will cause DMARC failures, even if the domain looks valid to a human.

This is why automated email verification—including real-time checks via the MailTester API—includes DNS-level validation of internationalized domains, ensuring that DMARC, SPF, and DKIM are all functional at the level the mail server actually reads them.

Don’t let the complexity of non-ASCII domains trip you up. The email system doesn’t see them as Unicode. It sees them as Punycode. Make sure your verification process treats them the same.

How are non-ASCII domains technically processed during email verification?

When you enter a domain like '例子.邮件', it’s automatically converted to Punycode—'xn--fsq0v38c0e.xn--0zwm56d'—for DNS and email protocol use. All verification checks, including SPF, DKIM, and DMARC, run on this encoded form. The system decodes it back to Unicode only for display, ensuring technical integrity while keeping the UI user-friendly.

Step-by-step: How non-ASCII domains are verified

Input domain is normalized to Unicode — The original domain, such as '例子.邮件', is accepted in human-readable form. This is the first point of contact in any email verification workflow.
Converted to Punycode for DNS resolution — The Unicode form is encoded using IDNA (Internationalized Domain Name in Applications) to produce a valid DNS name. For example, '例子.邮件' becomes 'xn--fsq0v38c0e.xn--0zwm56d'. This is the only form that DNS servers understand.
SPF, DKIM, and DMARC records are queried using Punycode — All DNS lookups for email authentication records use the Punycode version. This ensures that the protocol-level checks are performed on the actual domain the email client will see.
Results are mapped back to the original Unicode domain — After the verification completes, the system decodes the Punycode back to Unicode for reporting and display. This allows you to see results for '例子.邮件' even though the query used the encoded form.
Authentication policies (like DMARC) are evaluated on the encoded domain — DMARC policy enforcement is based on the actual domain as seen in DNS. If a domain uses a non-ASCII character, the policy must be correctly defined in the Punycode form. Otherwise, authentication fails.

Why this matters in practice

Even if the user sees '例子.邮件' in their inbox, the mail server processes it as 'xn--fsq0v38c0e.xn--0zwm56d'. If the DMARC policy is only set on the Unicode version, it won’t apply. That’s why verification tools must handle both forms correctly.

The 5 steps described in “Step-by-step: How non-ASCII domains are verified”, in order.

Without proper Punycode conversion, domains with non-ASCII characters fail to authenticate, leading to delivery issues. This is particularly common in regions like China, Japan, and the Middle East, where many organizations use native scripts in their domains.

The IETF’s RFC 5890 details how IDNA works, ensuring consistent encoding across systems. You can read the standard at https://www.rfc-editor.org/rfc/rfc5890.

At MailTester, we apply this standard process to every domain—whether ASCII or not. It ensures high accuracy across global domains. For high-volume list validation, try our bulk verification tool, which handles all domain forms reliably.

What are the risks of ignoring Punycode translation in DMARC policy evaluation?

If your email verification system skips Punycode conversion for internationalized domains (IDNs), it may wrongly flag valid addresses as invalid—or worse, miss spoofing risks because DMARC policies aren't evaluated against the actual DNS records used by mail servers. This gap can lead to undetected spoofing attempts and deliverability failures, even when the domain appears correct in display form.

Why Punycode matters in DNS and DMARC enforcement

Domains with non-ASCII characters—like café.com or 例子.测试—are converted to Punycode (e.g., xn--cafe-5ya.com) for DNS storage and transmission. Any DMARC policy evaluation must use this encoded form; otherwise, the policy lookup fails, and enforcement doesn’t occur. A domain that looks valid in Unicode might have no DMARC record in its Punycode version, leaving it vulnerable.

For example, a domain like 网站.中国 might resolve to xn--xkrov18e.cn, but if your verifier only checks the Unicode version, it sees no DNS record. That’s not a bad domain—it's just not being validated correctly. The result? An incomplete DMARC assessment, meaning no protection against unauthorized senders using the domain, and possible rejection by receiving servers.

How bad verifiers amplify the risk

Some email validation tools treat non-ASCII domains as syntactically invalid and reject them outright—this is a false negative. The domain might be real, active, and correctly configured in Punycode, but because the tool skips the conversion step, it gets flagged as invalid. This wastes senders’ time and inflates bounce rates, especially for global campaigns.

Meanwhile, if a tool doesn't enforce DNS checks on the Punycode version, it can miss spoofing risks entirely. A malicious actor could register a domain like “paypal.com” using similar-looking characters (e.g., a Cyrillic "а" instead of Latin "a") and, if validation skips Punycode handling, the system may not detect the mismatch. The DMARC policy, if even set, won’t be checked in the correct form, enabling spoofing.

Proper verification requires not just checking syntax, but resolving domains through the actual DNS path—ensuring that DMARC, SPF, and DKIM records are validated against the Punycode version. This is an industry-standard practice, as defined in RFC 3490 and RFC 5890, which govern how internationalized domain names are handled in email systems. RFC 5890 specifically covers the handling of internationalized domain names in the context of DNS-based protocols.

MailTester handles this correctly by automatically translating Unicode domains to their Punycode equivalents during DNS lookup. This means every DMARC policy is evaluated on the real, wire-level domain—providing accurate results whether you're verifying a local Italian address or a Japanese business domain.

For high-volume validations, use our bulk verification tool or integrate the real-time verification API, both of which support full IDN handling with correct Punycode translation to avoid costly false negatives and ensure strong DMARC compliance.

How do leading email verification services handle non-ASCII domains?

You might think a domain like café.com is simple, but email verification tools must handle non-ASCII characters through standardized encoding. The real test is whether the service converts Unicode domains to Punycode before DNS and DMARC checks—because only then can it validate policies and infrastructure accurately. Without this step, even a valid domain can fail verification due to technical mismatches. MailTester does this by default, ensuring alignment with RFC 5890 and industry standards.

Why IDN normalization matters in verification

MailTester converts Unicode domains (like örnek.com) to their canonical Punycode form (e.g., xn--brk3a.com) before any DNS or DMARC lookup.
It checks SPF, DKIM, and DMARC records using the Punycode representation—ensuring policy enforcement matches actual mail server configuration.
Verification results reflect how email servers actually process the domain, not how it appears in a user’s inbox.
Original Unicode form is preserved for display in the user interface, so you see shop.kafe.com while backend checks operate on xn--kafe-1ra.com.
This avoids false negatives from non-ASCII domains failing checks due to encoding mismatches during policy validation.

How this impacts deliverability and inbox placement

When you send email to a domain with non-ASCII characters, your server must resolve the same IDN-to-Punycode mapping as the recipient’s mail system. If your verification tool skips this step, you could send messages to a domain that appears valid but has no actual email infrastructure—because the DMARC policy only applies in the encoded form.

For example, a domain with a correctly published DMARC record in Punycode will be flagged as risky if the tool checks the Unicode version instead. MailTester avoids this by using real-world standards: all DNS lookups follow the IDNA (Internationalizing Domain Names in Applications) specification.

Let’s say you're verifying a list from France or Japan. If your tool doesn’t normalize non-ASCII domains, you’ll miss valid addresses—or flag clean ones as invalid. With MailTester, you’re not just checking an email address—you’re checking whether the domain can actually receive mail, using the same rules that real mail servers follow.

For accurate verification at scale, use bulk email verification, or integrate with tools like Mailchimp, Klaviyo, or SendGrid. Each step ensures you're testing against the actual deployment—not just how a domain looks.

What does a 'valid' verdict mean for non-ASCII domains in email verification?

A 'valid' verdict for a non-ASCII domain means the domain resolves in DNS, has valid SPF and DKIM records, and publishes a DMARC policy—even if it's set to 'none'. It confirms technical readiness for authenticated sending but doesn’t guarantee inbox delivery. The validation uses the Punycode form of the domain, which is how internationalized domains are standardized in DNS.

How verification works with non-ASCII domains

When you verify an email with a non-ASCII domain—like リイクンイ@example.日本—MailTester first converts the Unicode domain into its Punycode equivalent (e.g., xn--fsq050a.example.日本). The entire validation process runs against that encoded form, including DNS lookups, SPF and DKIM checks, and DMARC policy retrieval. The original Unicode display is irrelevant to the technical validation.

Let’s say you’re sending to an address like [email protected]. If the domain uses non-ASCII characters in its IDN (Internationalized Domain Name), the system automatically converts it to its Punycode version before checking. This is how the IETF standardizes email domains for global compatibility (see RFC 5890 and RFC 6531).

What ‘valid’ doesn’t mean

Just because a domain passes validation doesn’t mean the email will land in the inbox. A valid domain only confirms that the infrastructure is set up to support authenticated sending. Other factors—like sender reputation, content, engagement, or ISP filtering—still govern inbox placement.

For instance, a domain with a DMARC policy of 'none' still gets a 'valid' verdict. It’s technically compliant, but it offers no protection against spoofing. This is why you should monitor for policy enforcement, not just existence.

You can use MailTester’s bulk verification to test entire lists with mixed domain types. All domains, including non-ASCII ones, are handled consistently based on real-time DNS lookups and authentication standards. The same API endpoint supports real-time verification with full support for internationalized domains.

For deeper insight, test email deliverability before sending. Our inbox placement tester simulates delivery across major inboxes to confirm whether your message reaches the inbox or gets filtered.

How does MailTester ensure accuracy across non-ASCII and ASCII domains?

MailTester achieves 98.9% accuracy on both ASCII and non-ASCII domains by validating email addresses in real time using SMTP, DNS, and DMARC checks—with full normalization of Internationalized Domain Names (IDNs) via Punycode. This ensures domain character sets are handled consistently, regardless of whether they use Latin, Cyrillic, or other scripts.

Real-time IDN normalization and DMARC enforcement

When you verify an email with a non-ASCII domain—like "почта.рф" or "example.你好"—MailTester automatically converts the domain into its Punycode equivalent (e.g., "xn--80akhbbmbr9b.xn--p1ai") before testing. This is critical because DNS and SMTP systems only process ASCII. Without proper normalization, verification fails even when the address is real.

Our system applies DMARC policy enforcement at this normalized level. DMARC checks are not skipped just because a domain uses non-ASCII characters. Instead, we ensure the DMARC record is resolved in the Punycode form, matching how the domain appears in mail flows. This prevents false negatives caused by IDN mismatches.

According to RFC 5890, internationalized domains must be encoded using IDN-to-Punycode conversion to maintain compatibility across global email systems. We follow these standards precisely to prevent errors in domain matching and validation.

AI-assisted anomaly detection and bulk processing

The in-app AI assistant scans for issues like mismatched IDN forms (e.g., "example.com" vs. "example.कॉम" when both appear in the same list), or DMARC policies applied incorrectly due to script confusion. These are common sources of false validation results.

During bulk verification—whether you're cleaning a list of 100 or 100,000 addresses—we process each email using standardized Punycode forms. This preserves the integrity of your original data while ensuring the verification engine sees the domain exactly as it appears in real email traffic.

For example, if your list includes "user@бренд.рф", we normalize it to "[email protected]" before sending SMTP checks. No matter the script, validation happens in a single, consistent format.

Start testing your lists today with real-time email verification and inbox placement testing:

Bulk verification | Verification API | Inbox placement tester | Integrations | Pricing

Can DMARC policy be applied inconsistently across non-ASCII domains?

Yes—DMARC policy enforcement can fail if a domain uses different forms (like Unicode vs. Punycode) for its records. If SPF is set for the Unicode version but not the Punycode version, authentication breaks, leading to delivery issues. This inconsistency is a known vulnerability, especially for global domains using non-Latin scripts.

Why Unicode and Punycode create mismatched records

Domains with non-ASCII characters (like 阿里巴巴.中国) must encode them in Punycode (like xn--0cr.hk) for use in DNS. But if a sender uses different forms across SPF, DKIM, or DMARC records, DMARC can’t enforce policy uniformly. Let's say you publish SPF for "example.中国" (Unicode) but not for "xn--0cr.example" (Punycode). The DMARC check sees two distinct domains and fails.

This mismatch isn't rare. Internationalized domains (IDN) are common in markets like China, Japan, and the Middle East. According to the IETF’s RFC 5321, email systems must treat the full domain name as a single unit—yet many DNS systems still manage Unicode and Punycode variants separately. That gap enables authentication failures even when the domain is technically valid.

How it impacts email deliverability

When DMARC can’t apply consistent policy, emails get flagged as unauthenticated or low-trust—even if the sender is legitimate. Major providers like Gmail and Outlook may reject or send messages to spam without clear signals. This often shows up as soft bounces or poor inbox placement, especially for brands with global reach.

This issue is especially problematic for automated systems. If your system verifies domains using one form (like Punycode) but the domain’s SPF record applies only to the Unicode form, your verification will pass even though the email won’t deliver. That’s why you need deeper checks than just syntax.

That’s where tools like MailTester come in. Our verification API checks both forms of a domain during DNS inspection and flags mismatches in authentication records. MailTester’s real-time API detects these inconsistencies in advance, reducing delivery risks before you send.

For teams managing global mailing lists, this is critical. A single mismatch in Unicode/Punycode handling can tank deliverability across regions. You can’t rely on a single record form—validity must be cross-verified at the protocol level. Bulk verification helps catch these issues at scale, ensuring every address is truly deliverable.

You can't verify an email address reliably if the domain uses internationalized domain names (IDNs) like Café.com, which encode as xn--caf-9ra.com in DNS. MailTester detects this by comparing DNS records—SPF, DKIM, and DMARC—across both the standard and Punycode forms of the domain. If records only exist in one form but not the other, it flags the address as risky or invalid, catching issues that could lead to spoofing or inbox rejection.

Key checks in IDN verification

MailTester resolves both the Unicode domain (e.g., example.中文) and its Punycode equivalent (e.g., xn--example-08a.com) during DNS lookups for SPF, DKIM, and DMARC records.
It specifically checks for alignment between the domain in the email’s From header and the DNS records it claims to authorize.
If SPF or DKIM records are present only in the Unicode form but not in Punycode (or vice versa), the domain is flagged as risky—indicating a potential mismatch that could be exploited.
DMARC policy enforcement is tested against both encodings; a missing or inconsistent DMARC record across forms raises a red flag for spoofing risk.
When records are found only in one encoding, MailTester issues a 'risky' or 'invalid' verdict, helping prevent sends to addresses that may be spoofed or invalid.

Why this matters for deliverability

International domains are more vulnerable to encoding confusion. For example, a sender might publish SPF records only under the Unicode version while expecting delivery to validate against Punycode—a disconnect that leads to rejection.

According to the IETF’s RFC 5890, IDN handling must be consistent across systems. If your verification tool doesn’t check both forms, you’re leaving a gap where attackers can exploit visual similarity for phishing, or where valid sends get blocked for policy mismatch.

If you’re sending to global lists, you need this check. You can test how your emails would be received with inbox placement testing: MailTester's inbox tester. For large campaigns, bulk verification ensures IDN issues are caught early: verify your list at scale. With real-time API access, you can catch issues before delivery: integrate our email checker API.

What’s the bottom line for email verification with international domains?

Non-ASCII domain characters must be processed as Punycode during verification. Relying on Unicode forms can lead to failed DNS lookups and false negatives.

DMARC policy enforcement fails if Punycode resolution is incorrect. Authentication checks depend on exact DNS mapping—any deviation breaks validation.

Use tools that normalize Internationalized Domain Names (IDNs) correctly and validate domains in real time across all character sets. MailTester handles this with precision, ensuring accurate results for global addresses.

Sources

The number of top domains at DMARC enforcement grew from 233,249 in 2023 to 411,935 in 2026 — a 77% increase driven largely by mailbox-provider sender mandates. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
Google reported 265 billion fewer unauthenticated messages sent to Gmail users in 2024 — a 65% reduction — after its bulk-sender rules took effect, with 500,000+ top domains publishing DMARC records in response. — Google (via MailOver bulk-sender requirements guide) (2024)

Keep reading

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

Frequently asked questions

Does DMARC support non-ASCII email domains?

DMARC does not directly handle non-ASCII characters. It operates on the Punycode-encoded form of domains in DNS records. The policy is enforced based on the encoded domain.

How do email verification tools handle Unicode domains?

Trustworthy tools like MailTester convert Unicode domains to Punycode before DNS and DMARC checks, ensuring validation matches the actual infrastructure.

Why might a domain with non-ASCII characters appear valid but fail verification?

If DNS or DMARC records are published only in the Unicode form and not the Punycode form, resolution fails. Tools using incorrect encoding logic return false positives.

Can a non-ASCII domain have a DMARC policy without being deliverable?

Yes. A published DMARC policy in the correct Punycode form is necessary but not sufficient for inbox delivery. Reputation, content, and sending practices matter too.

Do all email verification tools support international domains?

No. Many tools treat non-ASCII domains as invalid or skip IDN handling, leading to undetected issues. Only tools with full Punycode support ensure accuracy.

What is Punycode, and why does it matter in email verification?

Punycode is the encoding standard that translates Unicode domains into ASCII-compatible strings for use in DNS. It’s essential for validating IDs across global email systems.

How does MailTester handle domains like '例子.邮件'?

MailTester converts the domain to its Punycode form ('xn--fsq0v38c0e.xn--0zwm56d'), validates DNS and DMARC records using that form, and returns accurate results.

What’s the impact of IDN mismatches on sender reputation?

Mismatches between Unicode and Punycode DNS records can expose domains to spoofing, reduce deliverability, and increase blocklist risks.

Can non-ASCII domains be used in SPF, DKIM, or DMARC records?

Only if they are encoded in Punycode. All DNS-level protocols require ASCII-compatible strings, so non-ASCII domains must be converted.

How do I test if my international domain’s DMARC policy is enforced correctly?

Use a verification tool that processes domains in both Unicode and Punycode forms and checks alignment across SPF, DKIM, and DMARC records.