Verify Email with Unicode: API for International Addresses in 2026

Why Unicode email addresses fail with basic verification tools

You send a campaign to customers in Japan, Germany, and China. The local part includes names like “märchen@”, “jörg@”, or even “王@exemple.邮箱”. It works when you test yourself—but your email delivery tool says it’s invalid. Why?

Most email verification tools still treat email addresses as if they were 1990s ASCII-only code. They don’t recognize that Unicode is now standard for global email. When an address uses non-English characters in the local part or domain, these tools fail—just because they lack RFC 6531 support.

That’s not a bug. It’s a legacy design flaw. Systems built before Unicode’s widespread adoption can’t process characters like é, ö, 王, or 例子. They mark valid international addresses as invalid. The result? False negatives. Blocked sends. Lost customers. A growing list of clean data you’ve labeled as garbage.

Key takeaways

• Basic email verification tools reject valid Unicode email addresses due to a lack of RFC 6531 support
• Non-ASCII characters in the local part (e.g., é, ö, 王) or domain (e.g., 例子.邮箱) are often incorrectly flagged as invalid
• An email verification API that supports RFC 6531 is required to accurately validate international email addresses

What is a Unicode email address? A technical breakdown

Unicode email addresses use non-ASCII characters—like 中文, 你好, or ü, ß—in the local part (before @) or domain part (after @), such as 好@例子.邮箱 or jürgen@könig.de. They’re valid under RFC 6531, which extends SMTP to allow UTF-8 encoding. Without full compliance, email systems can’t verify, route, or deliver these addresses correctly—leading to bounces, failed sends, or silent delivery failures.

How Unicode email addresses work under the hood

Before RFC 6531, email addresses were limited to ASCII characters (A–Z, 0–9, ., -). That meant non-Latin scripts had to be encoded using punycode—a workaround that obscured the actual readability of addresses. Today, RFC 6531 allows UTF-8 directly in both the local part and domain, so users can register and receive emails using their native language.

For example, 好@例子.邮箱 is a fully valid email address when delivered using an SMTP server that supports UTF-8. The local part (好) and domain (例子.邮箱) are transmitted in UTF-8, not punycode. But this only works if every component in the email delivery path—MTA, validator, sender—supports full RFC 6531.

Why most email verification systems fail here

Most email verification tools still default to ASCII-only validation. They reject non-ASCII inputs entirely, treat Unicode addresses as invalid, or fail to parse them during SMTP checks. This isn’t due to poor algorithms—it’s due to incomplete implementation of RFC 6531.

Let’s be honest: if your email verification API doesn’t support RFC 6531, you’re not verifying Unicode addresses. You’re just blocking them. That means you’re missing out on real users, especially in markets with non-Latin alphabets—China, Germany, Scandinavia, and beyond.

Even if your API returns “valid,” it may not properly test delivery. That’s why it's vital to use a tool that both recognizes and verifies Unicode addresses end-to-end. MailTester’s email verification API implements full RFC 6531 support, so you can validate Unicode addresses with confidence—down to the actual SMTP exchange.

The IETF document defining these standards, RFC 6531, confirms UTF-8 support at the protocol level. But support in practice varies widely. Make sure your verification system isn’t part of the problem.

How MailTester’s API handles Unicode email addresses reliably

You can verify Unicode email addresses like user@公司.中国 or mari@café.com with confidence using MailTester’s API. It processes UTF-8 encoded addresses fully compliant with RFC 6531, validating syntax, DNS records (MX, SPF, DKIM), and SMTP behavior—without rejecting non-ASCII parts. This means valid internationalized emails are caught, and invalid ones are flagged accurately, no matter the script.

Unicode Support Built into the Core

Let’s be clear: not all email verification tools support Unicode in the local part or domain. Many still treat non-ASCII characters as invalid early in the process. MailTester’s API doesn’t. It follows RFC 6531, the standard for internationalized email, ensuring UTF-8 is handled properly from start to finish.

This means domains like 世界.中国 or emails like joë[email protected] aren’t rejected simply because they contain non-ASCII characters. The API checks the actual DNS records—like MX and SPF—for these domains, just as it would for standard ASCII addresses.

Real-world examples: a user signed up with mari@café.com. The API doesn’t fail at the first non-ASCII character. It resolves the domain, checks the MX record, validates the server behavior via SMTP, and returns an accurate verdict.

Why This Matters for Deliverability

If your list includes international addresses, skipping Unicode verification means losing real subscribers—or worse, sending to invalid ones. That harms sender reputation and increases bounce rates. With MailTester, you catch these cases early.

You’re not just validating syntax. You’re testing whether the address works end-to-end. This includes checking for catch-all setups, temporary failures, and greylisting—just like a real mail server would.

For example, a verified Unicode address that is actually a catch-all still gets flagged as “risky”—not ignored. That’s crucial when you're sending to global audiences. Our real-time API integrates easily into your signup, onboarding, or data-cleansing pipeline, giving you immediate feedback on every address, no matter the language.

When you send to international domains, you want confidence. Not guesswork. MailTester’s compliance with RFC 6531 ensures that validation isn’t a filter to break real internationalized email—but a tool to protect your deliverability.

The technical path of a Unicode email through verification

You enter an email like joël@nörd.de — with Unicode in the local part or domain. The system doesn’t reject it. Instead, it normalizes the characters to UTF-8, checks syntax against RFC 6531, queries DNS using IDNs, verifies SMTP delivery, and returns a verdict based on real behavior. No guesswork. No false positives. Just accurate validation across global email standards.

How Unicode emails are processed step-by-step

1. Input: Unicode in local part or domain You submit an email like piñata@café.com. The system recognizes non-ASCII characters. No error — it's valid in modern mail systems.
2. Encoding: UTF-8 normalization per RFC 6531 The address is converted to UTF-8 and normalized. This ensures consistent handling across systems. For example, é becomes U+00E9, not a variant form. This step prevents subtle mismatches in DNS or SMTP.
3. Syntax check: Internationalized email conformance The system validates structure using rules from RFC 6531. It checks allowed characters, position rules, and domain format. If user@domain has invalid sequences, it’s flagged early.
4. DNS query: IDN-aware record resolution MX, SPF, and TXT lookups use Internationalized Domain Names (IDNs). The system converts domains like café.com into punycode (xn--caf-8wa.com) before querying. This ensures you're checking the correct server, not a misinterpreted domain.
5. SMTP handshake: Unicode handled transparently The verification engine initiates an SMTP session with the target domain using UTF-8 support. Many modern SMTP servers (including those used by Gmail, Outlook, and iCloud) accept Unicode addresses. If they do, the connection proceeds — no rejection due to non-ASCII content.
6. Final verdict: Valid, invalid, catch-all, or risky The result reflects actual delivery behavior. A valid status means the address is accepted and the server responds. invalid means a hard bounce or syntax flaw. catch-all means any address is accepted. risky indicates temporary failures or known abuse patterns.

Why this process matters for deliverability

Many tools fail at step 4 — treating café.com as a DNS error because they skip punycode conversion. Others don’t verify SMTP behavior, leading to false positives. With MailTester, you get true end-to-end validation. Test it yourself: try our real-time API or verify a full list via bulk verification.

How Unicode affects deliverability and sender reputation

Unicode email addresses—those with non-ASCII characters in the local part or domain—can be silently blocked or misrouted by mail servers that don’t properly support internationalized email (IDN). Even with correct SPF, DKIM, and DMARC, unverified Unicode addresses risk inbox placement failures, leading to reputational harm. Only a full-stack email verification solution that handles Unicode from end to end can prevent this damage.

Why Unicode addresses break silently

Not all mail servers interpret Unicode in email addresses the same way. Some reject them outright, others route them incorrectly, and some treat them as suspicious. The problem isn’t always failure to deliver—it’s often a quiet drop into spam folders or a delayed bounce. Without proper verification, you won’t know if the address is valid, just broken.

When Unicode domains or local parts aren’t verified before sending, your sender reputation takes hits from undeliverable messages. Even a single bounce from a malformed or invalid Unicode address can trigger rate limiting or filtering. This is especially true with large-scale sends where patterns of failure are analyzed by ISPs.

Complete verification is the only defense

Standard email checks often strip or reject Unicode entirely, leading to false positives. Valid Unicode addresses like joël@example.äpple.com look like invalid syntax to basic tools. But they’re real—IDNs are defined in RFC 6531, and major providers support them.

Let’s be clear: authentication (SPF, DKIM, DMARC) doesn’t fix delivery for invalid or non-routable Unicode addresses. It only proves you sent the message. It does nothing for inbox placement if the address doesn’t resolve or if the server doesn’t support IDN. That’s why you need verification that covers the full stack: syntax, domain validity, mailbox existence, and Unicode correctness.

Only tools that test across the full pipeline—like our email verification API—can catch issues with Unicode local parts or domains before they harm your sender reputation. Our system validates addresses using standards-compliant checks, including full IDN support, so you avoid sending to non-functional or malformed addresses.

Even if your campaign uses non-English domains or names, verification ensures deliverability isn’t sacrificed on the altar of inclusivity. With over 98.9% accuracy, MailTester handles edge cases like Unicode in both local and domain parts—because sending to real, valid addresses is only possible with real, validated data.

Common pitfalls when validating Unicode email addresses

You might think an email with non-ASCII characters like français@exämple.com is just an edge case—but it’s not. Many APIs fail these addresses because they don’t properly normalize Unicode, encode IDNs in DNS queries, or handle UTF-8 encoded local parts and domains. This leads to false negatives, wasted sends, and lost revenue. Let’s walk through where things go wrong—and how to avoid them.

Invalid normalization before parsing

• Unicode allows multiple forms to represent the same character (e.g., é as U+00E9 or U+0065 U+0301). If your API doesn’t normalize these before parsing, it may flag a valid address as invalid.
• Some libraries assume ASCII-only input, failing to apply Unicode normalization (NFC or NFD) before parsing the email. This misreads valid addresses as malformed.
• Always ensure your validation pipeline applies RFC 5891 and RFC 8266 standards for handling Unicode identifiers. See RFC 5891 for how to properly process Internationalized Domain Names (IDNs).

DNS issues with IDN encoding

• When validating a domain like exämple.com, the DNS query must use Punycode (e.g., xn--exmple-7ua.com). If your API makes direct queries using non-Punycode labels, it fails silently.
• Some validation services perform DNS lookups without converting the domain to IDNA2008-compliant format, leading to false negatives even if the domain exists.
• Test your API using real IDN domains—e.g., café.com. If it returns "invalid" without Punycode conversion, it’s unreliable.
• Use tools like MxToolbox to verify IDN resolution independently before trusting any validation result.

False results from overly aggressive scrubbing

• Some APIs strip or reject non-ASCII characters outright before validation. A valid address like user@bücher.de gets rejected simply for containing a ü—even though it’s standard.
• Others assume only ASCII domains are valid, ignoring that over 90% of new top-level domains support IDNs.
• Never assume that a non-ASCII character means an invalid address. Let the standards guide validation, not heuristics.
• For example, info@höll.de is valid if the domain resolves—just because it uses German umlauts doesn’t make it wrong.

MailTester's email verification API handles these cases correctly—supporting full Unicode normalization, IDN encoding in DNS lookups, and preserving non-ASCII parts throughout validation. Unlike many tools that fail silently on non-ASCII inputs, it applies industry-accepted standards directly. You can test validation quality with our inbox placement tester or verify full lists using bulk verification.

How to use MailTester’s real-time verification API with Unicode

You can verify Unicode email addresses in real time using MailTester’s API by sending a JSON request to the /verify endpoint with the full email address in UTF-8. The API parses and validates the local part and domain—including non-ASCII characters—and returns a clear verdict: valid, invalid, catch-all, or risky, with detailed reasoning. This works for both single checks and bulk workflows, and your purchased credits never expire.

1. Send the Unicode email in UTF-8 format. Encode the full email address (local part and domain) using UTF-8 before making the request. This is required because Unicode is not valid in raw SMTP unless properly encoded. The RFC 6531 standard defines how Unicode is supported in email addresses, and MailTester follows it strictly.
2. Use the /verify endpoint with a JSON payload. Submit a POST request to https://mailtester.com/api-email-checker with the email in the body, like: {"email": "user@пример.рф"}. No need to pre-encode the domain—MailTester handles the standardization internally.
3. Receive a structured response with a verdict. The API returns a JSON object with the result field set to one of: valid, invalid, catch-all, or risky. Each includes explanation notes—for example, why a catch-all was detected, or if the domain has no MX record.
4. Leverage bulk or real-time verification. You can verify single addresses in real time for UI interactions, or upload large lists via the API for batch processing. The same rules apply: UTF-8 input, instant results, and no time limit on credits.
5. Integrate across your stack. Use the API with tools like Mailchimp, HubSpot, SendGrid, or Klaviyo via dedicated integrations at https://mailtester.com/integrations. This ensures every outbound email—Unicode included—starts with a verified address.

How Unicode emails work in practice

Unicode domains (like café@example.com or 你好@世界.中国) are increasingly common, especially in global outreach. They’re permitted under RFC 6531, which extended email syntax to support non-ASCII characters. However, not all systems handle them correctly—this is where verification matters. A failed MX lookup or a malformed domain parsing step can cause bounces, even if the address is technically valid.

MailTester’s API validates the full sequence: DNS record lookup, SMTP handshake simulation, and Unicode normalization. It tells you not just whether the address exists, but whether it will receive mail reliably. You get clear guidance on whether a domain supports delivery, or if it’s a catch-all (where you can’t be sure the user is real).

Beyond the API: testing delivery

Verifying an address isn't the same as confirming inbox placement. For that, test live emails using our inbox placement tool. This checks how likely your message is to land in the inbox—not the spam folder—across providers like Gmail, Outlook, and Yahoo.

The combination of real-time verification and inbox testing gives you full confidence in your global email list, whether the address is in English, Cyrillic, or Han characters.

What each verification verdict means for Unicode addresses

When you verify an email with Unicode characters in the local part or domain, a "Valid" result means the address is real and deliverable, even with non-ASCII characters. "Invalid" means syntax is broken or the domain doesn’t exist. "Catch-all" means all emails to that domain are accepted — common on shared hosts. "Risky" flags domains with poor reputation, weak authentication, or abuse history. These verdicts apply to Unicode domains (like 🌐.example.com) and local parts (like jü[email protected]) just as they do to ASCII ones — but only if they’re properly encoded and supported by the receiving mail server.

Understanding Verdicts for Unicode Email Addresses

Unicode email addresses are valid under modern standards (RFC 6531, RFC 6532), but their delivery depends on the receiving server’s ability to process them. Not all systems support them equally, so verification must account for both syntax and real-world deliverability. You can’t assume an address with non-Latin characters is valid just because it passes syntax checks.

Many older systems reject Unicode addresses entirely, so even a "Valid" verdict doesn’t guarantee delivery on every server. The RFC 6531 specification defines the standard for UTF-8 in email, but real-world implementation varies. You should validate addresses at scale using tools built for modern standards — like MailTester's email verification API, which handles UTF-8 domains and local parts correctly in both real-time and bulk verification.

Email lists with Unicode: Clean them with MailTester’s bulk verification

You can upload any CSV or Excel file with international email addresses—whether they use emojis like 🌐.com, Chinese domains like 例子.网址, or Cyrillic characters—and MailTester will verify them properly. It checks syntax, MX records, and delivers real-time feedback on validity, catch-all status, and risk, even for non-ASCII parts. The result? A clean, accurate list ready for sending.

How it works: a step-by-step process

1. Upload your list in CSV or Excel format. MailTester accepts any valid email format, including those with Unicode in the local part (before @) or domain part (after @). This means it handles addresses like café@例子.网址 or user@🌐.com without breaking.
2. Run full verification using our API-powered engine. We validate DNS records, check for catch-all setups, test deliverability, and confirm inbox placement—no matter if the domain uses international characters. This process follows RFC 6531 for email address internationalization, ensuring standards-compliant checking.
3. Review results in real time. You’ll get a breakdown of each email: valid, invalid, catch-all, or risky. Invalid addresses are rejected. Catch-alls are flagged as potentially usable but high-risk. Risky addresses may be valid but have poor deliverability signals.
4. Download your cleaned list. Keep only the valid addresses, or filter out risky and catch-all entries. This reduces bounce rates, preserves sender reputation, and improves deliverability across global audiences.

Why this matters for global outreach

Unicode domains are growing. As of 2023, over 1,000 internationalized domain names (IDNs) were active globally, and their use is increasing in markets like China, Russia, and the Middle East. Sending to unverified Unicode addresses risks bounces, spam traps, and blacklisting. Without validation, you’re guessing—sometimes with serious consequences.

MailTester handles these complexities transparently. Unlike basic tools that reject non-ASCII addresses, we support full Unicode email standards. This is especially critical when working with customers in regions that use local languages in email domains. For a deeper look at email standards, see the RFC 6531 specification on internationalized email.

For teams that need to automate this process, our email verification API integrates directly into workflows. You can verify addresses on the fly, or use bulk verification for large datasets. We also offer inbox placement testing to see how your messages land in real inboxes across providers.

With 98.9% accuracy on verified addresses, MailTester helps you send reliably—no matter what language or domain format you're targeting. Start with 100 free verifications at our pricing page. Credits never expire.

Integrations: Bring Unicode verification into your workflow

You can verify Unicode emails in real time within your existing tools—Mailchimp, HubSpot, Klaviyo, or SendGrid—using MailTester’s email verification API. It checks validity, catch-all status, and deliverability at signup or before sending, blocking invalid or risky addresses before they hurt your sender reputation. This keeps your global lists clean and improves inbox placement across markets using non-Latin scripts.

Real-time validation at every touchpoint

• Use MailTester’s email verification API to validate Unicode emails (like 例え@example.日本) during user signup—before they enter your CRM or email service.
• Integrate with Mailchimp, HubSpot, Klaviyo, or SendGrid via pre-built connectors to automatically flag or reject invalid Unicode addresses in real time.
• Let the API return clear verdicts: valid, invalid, catch-all, or risky—so you know exactly what to do with each address.

Keep global lists clean, avoid bounces, improve delivery

• Block disposable domains, role accounts (e.g. [email protected]), and malformed Unicode addresses before they join your list.
• Verify entire lists in bulk using MailTester’s bulk verification tool, which includes deep checks for SMTP reachability, domain reputation, and syntax validity across Unicode domains.
• Test how your messages land in real inboxes with inbox placement testing—confirming your emails appear in primary folders, not spam, even with non-ASCII content.
• Unicode domains require specific handling. RFC 6531 defines how email systems should process UTF-8 in the local and domain parts; MailTester follows these standards to ensure accurate verification.
• Use your 100 free verifications to test the API with actual Unicode addresses from your market—no expiration, no pressure to commit.

Global email use is rising—over 4.5 billion people now send or receive email daily. Ensuring your systems accept and verify Unicode addresses isn’t optional. It's basic compatibility.

With MailTester, you’re not just validating syntax—the system checks whether the address can actually receive mail, even when it uses characters like 日本, مُحَمَّد, or Παναγιώτης. That’s how you maintain trust, avoid blacklists, and deliver reliably across regions.

Why Unicode support matters for global email marketing

98.9% accuracy across real-world data—including non-ASCII addresses—means fewer bounces, fewer wasted sends, and higher conversion rates. This isn't theoretical. It’s how you maintain deliverability at scale with global audiences.

Without Unicode support, valid international emails are rejected or treated as invalid. That means losing customers from regions where Unicode domains like 官方.中国 or お問い合わせ@サービス.de are standard. A single missed address can cost you revenue and trust.

Our email verification API handles Unicode in both the local part and domain. Send confidently to any valid address, anywhere in the world. You’re not just checking syntax—you’re verifying real people.

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)

Keep reading

• Email verification and list hygiene for deliverability (complete guide)
• How to Validate Email Deliverability After Infrastructure Changes
• How to Sync Opt-Out Requests Across Brands into One Verification System
• Email Delivery Risk from Misconfigured CNAMEs on Verification Subdomains
• Trustworthy Email Verification with Disclosed Seed Network Info

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

Frequently asked questions

Can you verify email addresses with non-Latin characters?

Yes. MailTester supports full Unicode email addresses, including non-ASCII local parts and domains, following RFC 6531.

Why does my email list include invalid Unicode addresses?

Many tools reject or fail to parse Unicode, leading to incorrect results. Only UTF-8-compliant verification works.

Does MailTester support domain names like café.com?

Yes. Domains with IDNs (Internationalized Domain Names) like café.com or 邮箱.中国 are fully supported.

How accurate is your Unicode verification?

MailTester achieves 98.9% accuracy, validated across global datasets, including international email addresses.

Can I verify Unicode addresses in bulk?

Yes. Upload a list with Unicode emails—it will be processed in bulk with full integrity and no data loss.

What happens to catch-all Unicode domains?

They are flagged as catch-all so you can assess the risk of sending to many addresses at once.

Is MailTester’s API suitable for international businesses?

Yes. It’s built for global use cases, supporting all legitimate Unicode email formats worldwide.

Do credits expire with MailTester?

No. Purchased credits never expire, so you can verify Unicode addresses anytime.

How do I start verifying Unicode emails?

Begin with 100 free verifications. No credit card required. Use the API or upload a list.

What’s the difference between Unicode and IDN email addresses?

IDN refers to domain names with non-ASCII characters; Unicode enables full email addresses with non-ASCII local parts or domains.

Why can’t I send to emails with emojis or special characters?

Most systems reject such addresses unless they support UTF-8 encoding per RFC 6531. MailTester ensures compliance.

Does MailTester detect disposable Unicode emails?

Yes. The tool identifies disposable domains—including non-ASCII ones—and flags them as risky or invalid.