IDNs in From Header Fail DMARC

Why does a non-ASCII domain in the From header cause DMARC failure?

You send a message from a non-English domain like 邮箱.公司, and suddenly your email vanishes into spam or gets rejected. You’ve set up SPF, DKIM, and DMARC—so why is it failing?

The problem isn’t your setup. It’s that internet email standards require the domain in the From header to be ASCII-encoded. When your IDN (like 邮箱.公司) is used directly in the From field, it breaks authentication—because DMARC checks alignment using the ASCII form, not the Unicode IDN. The mismatch causes a failure.

Think of it like sending a letter with a handwritten address in Chinese characters to a post office that only reads English. The content is clear to you, but the system can’t process it. DMARC doesn’t know how to validate a domain it can’t parse in ASCII.

Key takeaways

DMARC validation relies entirely on ASCII representations of domains, not Unicode or IDN forms.
Non-ASCII domains in the From header cause domain alignment failures, even with correct SPF and DKIM setups.
Internationalized domains must be converted to Punycode (e.g., xn--8w8h4c6h.公司) to pass DMARC checks, but sending the Unicode form directly in the From header will always fail authentication.

How do IDNs map to ASCII, and why does that break DMARC?

When you use an internationalized domain name (like 邮箱.公司) in your From header, it gets encoded into ASCII using Punycode—becoming xn--9kro02a9g8164b.com. That ASCII version routes correctly through DNS and SMTP, but DMARC checks alignment using the original domain form, not the Punycode version. The mismatch breaks alignment because SPF and DKIM validate against ASCII, while the From domain remains in Unicode. This causes DMARC failures even if the email is technically valid.

Punycode: The Bridge Between Unicode and Email Infrastructure

Internationalized domain names (IDNs) aren’t readable by DNS or SMTP directly. They’re encoded into ASCII using Punycode before being processed. For example, 邮箱.公司 becomes xn--9kro02a9g8164b.com. This conversion happens at DNS lookup and email routing stages—so technically, the email route is fine.

But here's the catch: DMARC doesn’t use the Punycode form during alignment checks. Instead, it compares the domain in the From header—still in Unicode—to the domains in SPF and DKIM. Since SPF and DKIM use the ASCII version (the Punycode encoding), the domain alignment fails even when all technical components are correct.

Send an email with an IDN in the From header — e.g., sender@邮箱.公司. The email system converts the domain to Punycode for DNS and routing, so delivery works.
DMARC validation begins at the receiver — the validator parses the From domain as it appears: 邮箱.公司, a Unicode string.
SPF and DKIM are evaluated using the ASCII version — both mechanisms use the Punycode-encoded form (xn--9kro02a9g8164b.com), which is different from the Unicode From domain.
Alignment check fails — DMARC requires the SPF or DKIM domain to match the From domain. Since Unicode ≠ ASCII, alignment fails.
Result: DMARC failure — even if the message is legitimate, it may be quarantined or rejected by receivers that enforce strict DMARC policies.

The 5 steps described in “Punycode: The Bridge Between Unicode and Email Infrastructu…”, in order.

Why This Breaks Sender Reputation

Even if your email reaches the inbox, repeated DMARC failures due to IDN handling can trigger reputation issues. Receivers may see repeated alignment mismatches as a sign of spoofing or misconfiguration. This undermines trust, especially for senders using non-English domains.

As RFC 7565 (the specification for IDN handling in email) notes, "The use of internationalized domain names poses challenges for existing standards that rely on ASCII-only representations." This is not a bug—it’s a known limitation in how DMARC and traditional email components intersect.

It’s worth noting that some modern email clients and mail servers are beginning to support Unicode From domains in alignment checks, but adoption is far from universal. Until then, the safest path is to avoid IDNs in the From header if DMARC compliance is critical.

Use a tool like MailTester's email checker to validate sender domains before sending—or use the real-time verification API for automated validation in integrations. This helps catch issues like IDN alignment early.

What happens when a domain in the From header is not in ASCII?

When a domain in the From header uses non-ASCII characters—like 邮箱.公司—it fails DMARC because receiving servers only compare the domain’s ASCII form (punycode) during alignment checks. If the domain isn’t in ASCII, DNS records for SPF or DKIM won’t match, causing authentication to fail even if the message is legitimate. This breaks the chain required by DMARC, resulting in outright rejection by most major inboxes.

Why ASCII is mandatory in email authentication

Email infrastructure, including SPF, DKIM, and DMARC, relies solely on ASCII domain names. The system doesn’t understand Unicode directly—domain names must be converted to ASCII via Punycode (e.g., 邮箱.公司 becomes xn--p8j164c4b4b3331c.com). This conversion happens at the protocol level, but the resulting form must match the exact domain used in DNS records.

If your From domain uses non-ASCII characters, the DNS lookup for SPF or DKIM won’t find a matching record. The receiving server checks alignment between the From domain and the domains in SPF (mfrom) and DKIM (d=), and if they don’t match at the ASCII level, the authentication fails. This is defined in RFC 7645, which specifies how DMARC performs alignment using ASCII representations.

Even good sender reputation can’t override this

DMARC doesn’t care about your sender reputation, email content, or past deliverability. A single authentication misalignment — such as the use of an IDN in the From domain — will cause the entire message to be rejected. Even if you’ve built a strong reputation with Gmail or Outlook, this one technical mismatch will still trigger a fail.

Some mail servers may flag these messages as potential spam or reject them outright. According to a 2022 report by the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), DMARC failures due to domain misalignment are consistently among the top reasons for email rejection in enterprise environments.

Let’s be clear: using non-ASCII domains in the From header is not a best practice—it’s a technical blocker. You can’t rely on DNS workarounds or "good intent" to fix alignment. The system only works if the domains in the From header, SPF, and DKIM all match in their ASCII form.

To catch this before sending, use tools like MailTester’s real-time email checker to validate the full sender chain—including IDN safety and domain alignment—before delivery. It helps uncover these issues early, especially when managing international campaigns or using foreign-language domains.

Can DMARC work with IDNs in the header if the domain is in ASCII?

If the domain in the From header is represented in ASCII—either as a plain ASCII domain like company.com or as its Punycode equivalent (e.g. xn--company-1na.com)—then DMARC can authenticate successfully. The display form of an IDN (like 你好.com) in the user’s inbox is allowed and often shown, but DMARC checks the underlying header using ASCII. Even if the display name or subject contains Unicode characters, the From header must remain ASCII to avoid breaking authentication.

Why the ASCII form matters for DMARC

DMARC relies on DNS records and domain validation, both of which operate exclusively on ASCII-based domains. When a domain in the From header uses UTF-8 characters directly (e.g., 你好.com), the email system must convert it to Punycode before processing. If this conversion doesn't happen correctly—or if the header contains the Unicode form directly—DMARC validation fails because the domain doesn't match the domain in the DNS record.

Let’s say you send from 你好.com. The email client may display that as “你好.com” to users, but internally, the From header must resolve to xn--你好-6ra.com. If your DNS setup doesn’t support this Punycode variant, DMARC will fail. This is why even if your domain is registered as an IDN, you still need to ensure your SPF, DKIM, and DMARC records are set up for the ASCII version.

Display vs. authentication: when things go wrong

Email clients are free to render IDNs in their native form for user experience. Many modern clients support this display formatting safely. However, this is purely visual. The authentication chain—SPF, DKIM, and DMARC—must use ASCII. If any part of the chain uses Unicode in the header, the system cannot resolve it correctly, and the message may be rejected or flagged as suspicious.

According to RFC 6531, which defines internationalized email addresses, the use of IDNs is permitted in display forms but not in the core header fields without proper Punycode encoding. The email standards community recognizes this risk and explicitly requires ASCII in SMTP and DNS processes. Misaligned encoding between the display name and the authenticated header is one of the most common causes of DMARC failures.

Even if your sender reputation and authentication are otherwise strong, a non-ASCII From header can trigger rejection by receiving servers, especially those using strict policies. You can test this with tools like MailTester’s inbox placement tester, which checks for header compliance before delivery.

So, while you can safely use IDNs in display names or subject lines, the From header must remain in ASCII or the correct Punycode. Always verify your domain’s header representation using tools that simulate real delivery environments.

Is there an exception for IDNs in DMARC alignment?

You cannot use internationalized domain names (IDNs) in the From header and expect DMARC alignment to pass. No current implementation—least of all by Google, Microsoft, or Yahoo—supports Punycode-form domains in DMARC checks. The From domain must be ASCII-only, or DMARC alignment fails, regardless of whether the IDN is valid or correctly encoded.

DMARC checks ASCII domains only

DMARC relies on strict domain alignment between the From header and the domain in SPF or DKIM signatures. But all major email providers perform this check using only ASCII characters. Even if a domain like 例子.com is properly encoded as xn--fsq0z14b.com in DNS or headers, the DMARC validator won’t process it. It compares the domain in the From header as-is, and if it contains non-ASCII characters, it’s rejected immediately.

Let’s be clear: no compliant DMARC implementation currently recognizes or validates Punycode forms during alignment. Even if the domain is syntactically correct in DNS and the message is delivered, DMARC alignment will still fail. This is not a bug—it’s by design. The underlying standards (RFC 7672, RFC 6376) require ASCII-only domain comparison for alignment checks.

What happens when IDNs are used in From headers?

When you send from an IDN domain, even if it's correctly encoded in the header, receivers like Gmail and Outlook will fail the DMARC alignment test. This results in your email not being marked as “aligned,” reducing trust signals and increasing the risk of filtering—especially for high-value or time-sensitive messages.

Even if the domain is valid and the message delivers, the lack of alignment impacts inbox placement, sender reputation, and long-term deliverability. You're essentially sending with a domain that looks legitimate but fails the core trust mechanism of modern email authentication.

If you’re verifying email addresses or testing deliverability, using IDNs in the From header will break alignment checks. Tools like MailTester’s inbox placement tester can help expose these alignment failures early by simulating real-world delivery environments across major providers.

While efforts to update the standards are ongoing—such as proposals to support UTF-8 in email headers—none are yet implemented at scale. Until then, stick to ASCII domains in the From header for reliable DMARC compliance and deliverability.

How to fix delivery issues caused by IDN domains in the From header?

You must use only ASCII domains in the From header, even if your brand uses an internationalized domain name (IDN). IDNs in the From field can break SPF, DKIM, and DMARC validation because these protocols operate in ASCII only. If your domain includes non-ASCII characters, use the ASCII equivalent (like punycode) in the actual email header, while displaying the IDN version in the display name or subject line. This ensures compliance with standards and avoids delivery failure.

Fix your From header structure

Replace any IDN in the From header with its ASCII representation (e.g., example.xn--q9jyb4c instead of example.例子).
Ensure that SPF, DKIM, and DMARC records are published and valid for the ASCII domain, not the IDN version.
Use the actual IDN only in human-readable fields like the display name, subject line, or email body — never in the From header field that gets processed by email servers.
Test your domain’s authentication with tools like MXToolbox or Microsoft’s authentication checker to verify SPF and DMARC alignment.
When sending bulk mail, verify that your email list uses properly formatted From headers — you can test this with our email checker or bulk verification before sending.

Why this matters

Many email systems, including Gmail, Yahoo, and Outlook, evaluate the From header against DNS records using ASCII standards. If the domain in the From header isn’t in ASCII format, validation checks fail silently. This leads to low inbox placement, higher spam scores, or outright rejection — even if the content is legitimate.

DMARC requires strict alignment between the domain in the From header and the authenticated domain in SPF or DKIM. Using an IDN in the From header breaks this alignment, even if the IDN is displayed correctly to users.

For example, a domain like 例子.com must resolve to its ASCII equivalent (e.g., xn--q9jyb4c.com) in all technical headers. The display name can still show the original IDN. This distinction is crucial for deliverability.

Use inabox placement testing to simulate how your messages land in real mailboxes. This helps catch issues before they impact your sender reputation.

Can you test whether a domain will fail DMARC due to IDN usage?

Yes — you can test whether a domain will fail DMARC due to IDN usage before sending. Tools like MailTester’s inbox-placement testing simulate real-world email delivery and reveal alignment failures caused by IDNs in the From header. This helps catch issues early, before they lead to blocked messages or damaged sender reputation.

Testing DMARC alignment with IDNs

DMARC requires strict alignment between the From domain and the domains used in SPF and DKIM. When an IDN (like “sörge.com” or “café.com”) appears in the From header, email systems process it in Unicode form. But SPF and DKIM operate on the ASCII-punycode equivalent (e.g., “xn--srg-5ia.com”). This mismatch breaks alignment, causing DMARC failure.

Let’s say you send an email from “café.com” — the message will pass SPF and DKIM using the punycode version, but DMARC sees the domain as “café.com” in the From field. This mismatch triggers rejection. The only way to know if this happens is to test it under real mail server conditions.

MailTester’s inbox-placement testing sends messages through actual recipient inboxes and reports back on delivery status, spam filtering, and DMARC alignment. It detects whether a domain in the From header fails due to IDN usage — without you having to send to a real user first.

The real-time verification API checks whether the From domain is valid in ASCII form and whether it aligns with SPF and DKIM. It returns a clear “valid,” “invalid,” or “risky” verdict based on technical and reputational signals — including IDN issues.

For bulk sends, MailTester’s bulk list verification scans your entire list and flags any addresses using IDN domains in the From header. This prevents entire campaigns from being rejected due to alignment failures. You’ll know which emails pose a risk before they go out.

Learn more about verifying email lists at MailTester’s bulk verification tool. Real-time validation, inbox placement testing, and API integration help you catch IDN-related DMARC problems before they impact deliverability.

DMARC enforcement is strict, and IDN handling is a known pain point. The RFC 6531 specification describes how IDNs should be encoded in email, but implementation varies across mail systems. For details, refer to the IETF’s official documentation on internationalized email RFC 6531.

Why does email-verification matter for DMARC and IDN issues?

You can’t fix DMARC alignment if the From address is invalid, improperly formatted, or uses a non-ASCII domain—common with internationalized domains (IDNs). Email verification catches these issues early, before you send. A single malformed From header can trigger rejection, even if your authentication (SPF, DKIM, DMARC) is technically correct. By validating addresses upfront, you ensure domain-level compliance, reduce bounces, and prevent inbox placement drops tied to sender reputation.

Preventing DMARC Failures Before They Happen

DMARC checks rely on the From header matching the domain in SPF and DKIM. If that domain is invalid, misconfigured, or uses a non-ASCII character that’s improperly encoded (as in IDNs), alignment fails—even if you’ve set everything up right. This is not a delivery issue per se; it’s a validation issue. Let’s say your campaign sends to a user whose From address includes a Japanese or Arabic character. If the email is sent without proper Punycode encoding—or if the domain itself is invalid—DMARC will flag it as a failure, even if the message is otherwise legitimate.

Tools like MailTester’s bulk verification and real-time API help identify these risks before you send. With 98.9% accuracy, MailTester’s system detects invalid addresses, catch-alls, and domains that fail basic SMTP checks. This includes flagging From domains that aren’t actively receiving email, which often means they aren’t properly registered or maintained. Verifying at scale means you catch both technical and policy-level red flags—like domains using non-ASCII characters without proper encoding—before they cost you in deliverability.

Spotting Suspicious Headers with AI-Powered Checks

Modern email verification isn’t just about syntax. The in-app AI assistant in MailTester can analyze entire header structures and flag potential issues—like non-ASCII domains, malformed DKIM signatures, or mismatched From and Return-Path domains—during list hygiene checks. If a From address uses an IDN that wasn’t encoded as Punycode (e.g., example.рф instead of example.xn--p1ai), it may pass syntax checks but still fail DMARC alignment.

While standards like RFC 6531 define how internationalized domains should be handled in email, many email clients and servers still struggle with non-Punycode forms. Even if your infrastructure supports them, third-party filters and blocklists may not. That’s why catching this during verification is critical.

You can test your current sending setup with MailTester’s inbox placement tool—available at inbox placement testing—to see how your messages land across major providers, including how IDN handling affects delivery. It’s one of the few tools that simulates real-world inboxing while checking for compliance issues before you send to real users.

For developers, the verification API at MailTester’s API integrates directly into your send workflow, ensuring every address meets standards—including proper From header formatting—before entering your queue.

How do senders using multilingual brands avoid delivery failures?

You keep your sender domain in plain ASCII, use IDNs only in display names and branding, and align all authentication records (SPF, DKIM, DMARC) with the ASCII version. This ensures email systems can validate your identity correctly, even when the From display name shows non-ASCII characters. Most major inbox providers require this alignment for trust and security, especially in global campaigns.

Key steps to preserve deliverability with multilingual branding

Register and manage your primary sender domain using only ASCII letters, digits, and hyphens (e.g., example.com).
Use IDN domains (like 例子.com) only in public-facing content, such as website URLs, marketing materials, or display names—never in the actual From header or authentication configuration.
Configure SPF, DKIM, and DMARC records exclusively on the ASCII domain. A DMARC policy written for 例子.ком will not apply to example.com, even if the display name uses the IDN form.
Validate every From address before sending to ensure the sender domain in the envelope and header matches the authenticated domain. You can check this with a real-time email verification tool like the MailTester email checker.
Test inbox placement across different regions and clients using an inbox tester that supports IDN display names to confirm the branding appears correctly without triggering spam filters.

Understanding the technical limits of IDNs in email

While display names can include Unicode characters—like Chinese, Arabic, or Cyrillic text—email infrastructure still relies on ASCII for routing and validation. The SMTP envelope (where SPF and DMARC operate) and DNS records require ASCII. This means even if your display name reads البريد@example.com, the actual sender domain must still be example.com for authentication to pass.

For reference, RFC 6531 defines how to handle internationalized email, but real-world inbox providers often don’t support IDN in authentication contexts. The IANA IDN tables define which characters are valid in domains, but that doesn’t mean they’re safe in email headers.

Let’s be clear: using an IDN as your sender domain breaks SPF, DKIM, and DMARC. This creates a gap that malicious senders exploit. You’re not just risking bounces—you’re inviting blocks. Stick to ASCII for the sender domain, use IDNs only in user-facing elements, and verify your address list with a tool that checks both syntax and deliverability—like MailTester’s bulk verification.

What happens when a message fails DMARC due to IDN misalignment?

If your email’s From header uses an internationalized domain name (IDN) that doesn’t match the domain in your DMARC policy, mailbox providers like Gmail, Outlook, or Yahoo will reject, quarantine, or mark the message as spam—even if the content is legitimate. This misalignment triggers a DMARC policy violation, and since DMARC is enforced at the domain level, it doesn’t matter if the rest of your email is clean. The result is a failed authentication check, which harms your sender reputation and can degrade deliverability for all future messages sent from that domain.

Why even valid messages get blocked

DMARC checks align the domain in the From header with the domain in SPF and DKIM signatures. When IDNs—like 例子.郵件—are used, they must be properly encoded in ASCII form (Punycode, like xn--fsq060d.郵件) to pass validation. If the From header shows the Unicode version but the DMARC policy is set against the Punycode version, alignment fails. Mailbox providers treat any DMARC failure as a potential spoofing attempt, regardless of intent.

Even a single failing message can signal poor sending hygiene to providers. If your domain has multiple DMARC failures due to IDN misalignment, it may trigger rate limiting or lead to your entire domain being flagged. This isn't just about one email—it's about trust. Each failure adds to your domain's reputation score, which affects inbox placement across all services.

How to prevent and fix this issue

Let’s be clear: using IDNs in the From address is valid, but it requires strict adherence to technical standards. The domain must be consistently represented in both the From header and your DMARC records. If you're sending to global audiences, ensure your email infrastructure handles IDN encoding correctly—especially if your ESP doesn't support it natively.

You can test your setup with inbox-placement tools that simulate real-world delivery. The MailTester inbox tester checks how messages land across major providers, including whether DMARC or other policies block them. It helps catch IDN issues before you send to customers.

Before sending bulk mail, validate your entire list to avoid sending to domains that might misalign. Use tools like MailTester’s bulk verification to weed out invalid, catch-all, or risky addresses. Ensuring clean data is the first line of defense against authentication failures.

For more on email authentication, refer to the official DMARC specification (RFC 7483) or explore deliverability guidelines from major providers like Microsoft’s Message Transfer Policy or Google’s Gmail security documentation .

Summary: Avoid IDNs in the From header to maintain DMARC compliance

DMARC validates email authenticity using ASCII-based domain names. Internationalized domain names (IDNs) in the From header are not recognized by DMARC, resulting in alignment failures even if the domain is otherwise valid.

Even if your brand uses an IDN, always use the ASCII equivalent (Punycode) in the From header. This ensures consistent alignment between the domain in the From header and the SPF/DKIM authenticated domains.

How to verify and prevent issues

Use MailTester’s real-time API to validate From headers and catch IDN alignment risks before sending.
Run inbox-placement tests to confirm messages land in inboxes, not spam, with full authentication alignment.
Never prioritize visual branding over authentication standards — sender reputation relies on compliance, not design trends.

Sources

52.1% of the world's top 1.8 million domains (937,931 domains) now publish a valid DMARC record, up from 29.1% in 2023. — 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

Can I use a Chinese domain like 邮箱.公司 in my From header?

No — the From header must use ASCII. Use the Punycode version (xn--9kro02a9g8164b.com) only if it's the registered domain, and even then, ensure it passes alignment checks.

Why does DMARC care whether the domain in From is ASCII?

DMARC checks alignment against SPF and DKIM records, which are resolved using ASCII domain names. IDNs are not standard in DNS or authentication headers.

Does changing the display name fix a DMARC issue?

No — changes to the display name or subject don’t fix DMARC failures caused by IDNs in the From header.

Can I have two domains — one IDN, one ASCII — and use both?

Yes, but only the ASCII domain can be used in the From header for DMARC alignment. Use the IDN only for branding, not in authenticated headers.

How do I test if my email will fail DMARC due to IDN?

Use MailTester’s inbox-placement testing to simulate real delivery and detect DMARC alignment failures before sending to real users.

Is Punycode ever safe in an From header?

Only if it matches the domain used in SPF, DKIM, and DMARC records. Misalignment still causes DMARC failure.

What happens if I use an IDN in the From header but it passes SPF and DKIM?

It still fails DMARC alignment, even if SPF and DKIM pass. DMARC is stricter on domain alignment than individual checks.

Do all email providers reject IDN From headers?

Yes — Google, Microsoft, Yahoo, and other major providers enforce ASCII-only domain checks in From headers for DMARC validation.

Can email verification tools detect IDN issues in the From header?

Yes — MailTester’s verification API and bulk list checks flag domains that are non-ASCII in authenticated headers to prevent delivery failure.

Why do some senders still get messages through with IDN From headers?

Because some recipients don’t enforce DMARC strictly — but this is unreliable. High-quality receivers will reject them.

What’s the best way to verify a list with IDN domains?

Use MailTester’s bulk verification to check addresses and headers; it flags non-ASCII From domains and ensures alignment with SPF/DKIM records.

Can I use IDNs in Reply-To or other headers?

No — similar rules apply. Any header that triggers DMARC alignment must also use ASCII domains.