What causes SMTP 554 errors when sending to non-ASCII domains?

You send an email to café.com, and it bounces with a clean, cold “554 Transaction refused.” No explanation. No warning. Just rejection.

It’s not the address that’s wrong—it’s the language. Non-ASCII domains like müller.de or البريد.سعودي aren’t natively readable by SMTP servers, which were built for pure ASCII. When encoding fails or servers misinterpret them, the transaction dies before it starts.

Here’s the truth: every email you send must pass through the same rules as the original Internet protocol—strictly ASCII. Non-ASCII domains use IDNA (Internationalized Domain Names in Applications) to convert characters like ‘é’ or ‘م’ into ASCII-compatible strings. But if that conversion fails—or the receiving server doesn’t support it—you get SMTP 554, and your mail is dead.

Key takeaways

  • SMTP servers require ASCII domain names and reject non-ASCII domains during DNS resolution or handshakes.
  • IDNA converts non-ASCII characters into punycode; failures in this process trigger SMTP 554 rejections.
  • Receiving servers that lack proper IDNA support or misvalidate encoded domains will block messages without exception.

How does IDNA encoding work—and where does it fail in practice?

Non-ASCII domains like café.com are encoded into ASCII using IDNA (Internationalized Domain Names in Applications), which translates them into Punycode—such as xn--caf-sua.com—so they can pass through legacy systems that only understand plain ASCII. This works only if both sending and receiving SMTP servers properly implement IDNA. When either side fails, the transaction gets rejected with a 554 error, even if the domain is otherwise valid.

How IDNA maps real-world names to ASCII

When you type café.com into an email client, your system automatically converts it to xn--caf-sua.com using the rules defined in RFC 5890. This encoding ensures the domain can be processed by DNS, which only accepts ASCII. Email systems that support IDNA will recognize this conversion and handle the delivery correctly. Without that support, the system treats xn--caf-sua.com as an invalid or suspicious-looking domain.

Where IDNA breaks down in real mail flows

Not all mail servers have kept up with IDNA standards. Older or misconfigured SMTP servers may outright reject any domain containing 'xn--' prefixes, treating them as potential encoding tricks or phishing fronts. This happens even when the domain is legitimate. Some receiving systems apply heuristic filters that flag IDNA-encoded domains as risky due to their unusual format—especially if they're not widely used or registered through major providers.

Even if both ends support IDNA, a poorly implemented resolver can fail to map the Punycode back correctly, leading to a mismatch and a failed delivery. This isn't a flaw in the protocol, but in inconsistent implementation across mail infrastructure. You can’t rely on IDNA to work across every system, even though it’s an industry-standard solution.

That’s why verifying email addresses with non-ASCII domains requires more than just checking syntax. It needs active testing of real deliverability across diverse environments. Use tools that simulate actual SMTP transactions to catch these edge cases. Check entire lists upfront with a service that includes real-time delivery testing and IDNA-aware validation.

Why non-ASCII domains appear in your email list in the first place

You’re seeing non-ASCII domains in your email list because businesses and users in non-English markets use native scripts in their domains (like नेपाली.कोम or 微信.中国), legacy systems may store name-based email addresses with non-Latin characters, and automated processes often collect domains without validating or normalizing the encoding. This leads to raw, unprocessed strings that break standard email delivery protocols.

Native scripts in domain names

As global digitization expands, companies in regions like South Asia, China, and the Middle East increasingly adopt localized domain names. These use non-ASCII characters through IDNA (Internationalized Domain Names in Applications), which encode Unicode into ASCII-compatible formats for DNS. If your list includes these domains without IDNA normalization, they’ll appear as raw, unreadable strings — and SMTP servers reject them with a 554 error.

For example, a domain like नेपाली.कोम is encoded as xn--n4b559g83k. If you’re receiving raw input or scraping data from such sources, you’ll find the original Unicode version that doesn't conform to SMTP standards.

How data collection systems miss the mark

Many signup forms or form processors accept email input at face value, assuming that any string with an '@' symbol is valid. They don’t validate or convert non-ASCII domains. Automated tools — including web scrapers — often extract domains straight from HTML or unstructured text without IDNA normalization, pulling in invalid representations like user@नेपाली.कोम instead of the proper encoded form.

This happens because IDNA processing is often an afterthought. The underlying assumption is that only ASCII is safe, and the burden of normalization falls on the sender — which means your list grows with broken addresses you can’t yet detect.

According to the IETF’s RFC 5890, IDNA is designed for consistent encoding across systems, but not all systems apply it correctly. Without proper validation, non-ASCII domains enter your database and eventually cause delivery failures.

Let’s be clear: you can’t deliver to a domain that doesn’t exist in ASCII form. If your list contains raw Unicode domains, even valid ones from trusted sources, they’ll fail during SMTP handshakes.

That’s where reliable verification comes in. Using a tool like bulk email verification can catch invalid and non-compliant domains early — including non-ASCII variants that haven’t been properly encoded. It flags those that don’t resolve under standard mail transfer rules, preventing costly bounces and improving sender reputation.

What does SMTP 554 transaction refused really mean—beyond the code?

SMTP 554 is a hard rejection: the receiving server has decided, definitively, not to accept your message. Unlike 4xx errors that signal temporary issues, 554 means retrying won’t help. The refusal stems from policy, syntax, or security rules—often because the server doesn’t support non-ASCII characters in domain names, even if the domain itself is valid and registered.

Why 554 is not a retryable error

When you see 554, the mail server has already evaluated your request and shut it down. This is not a network glitch or a rate limit. It’s a final decision. If you retry, you’ll get the same response. The server doesn’t want your message—even if the address is technically correct. This is different from 4xx codes like 421 (service unavailable), which imply temporary conditions and allow for retry logic.

Non-ASCII domains, like café@example.com or straß[email protected], use internationalized characters. These must be encoded via IDNA (Internationalized Domain Names in Applications) to be processed in DNS. If the receiving server doesn’t support IDNA, it cannot validate or route the mail. Even if the domain is registered in a non-Latin script, the underlying mechanism fails silently unless both sides support the standard.

Even if a domain is valid, the SMTP handshake can fail at the HELO/EHLO or MAIL FROM stages if the server doesn’t accept non-ASCII input. Many older or security-hardened mail systems still default to ASCII-only processing. Without IDNA compliance, a valid domain appears as invalid or malformed at the protocol level.

How to fix or prevent 554 for non-ASCII domains

Let’s be clear: you can’t “fix” a 554 from a third-party server—it’s their policy. But you can avoid it entirely. The best defense is filtering non-ASCII domains before sending. Tools like bulk email verification can flag domains using non-Latin characters early, so you don’t send to them at all.

For domains that require non-ASCII, ensure your email system uses IDNA-conformant libraries. Most modern mail platforms handle this automatically, but edge cases—especially with mail from regions using non-Latin scripts—still expose gaps. Use tools that test actual delivery behavior: inbox placement testing can reveal whether non-ASCII emails reach inboxes or get blocked before delivery.

For reference, IDNA is defined in RFC 5890–5893. These standards describe how internationalized domain names should be encoded in DNS and email systems. If a server doesn't follow them, it’s effectively incompatible with global email standards.

How to detect non-ASCII domains in your email list before sending

You can catch non-ASCII domains early by using a verification service that checks domain syntax and encoding during validation. Look for characters outside the basic ASCII range—especially in the domain part—like accented letters (é, ü, ñ) or non-Latin scripts. These often fail if not properly encoded with Punycode. Let’s go through the practical steps to spot and fix them before they trigger an SMTP 554 error.

Check domain encoding at the source

  • Use a verification service that validates not just syntax but also IDNA (Internationalized Domain Names in Applications) encoding during checks. Tools like Bulk Email Verification test for compliant Punycode representation, so domains like xn--bcher-kva.de don’t get ignored.
  • Scan your list for characters in the range U+0080 to U+FFFF—these include diacritics and non-Latin characters. If your list contains café@example.com or email@straße.de, ensure the domain portion is converted to its Punycode equivalent during validation.
  • Flag any domain that uses letters with accents, umlauts, or non-Latin scripts (e.g., Cyrillic, Arabic, Chinese) without a clear, valid Punycode fallback. These often result in rejected transactions even if the user exists.
  • Be cautious with domains from regions where IDNA is inconsistently supported. Even if the domain resolves online, some mail servers reject mail from non-ASCII domains outright. Use real-time verification to test deliverability.

Verify before you send

  • Don’t rely on basic regex checks. A domain can pass syntax validation but still fail due to invalid IDNA encoding.
  • Test domains with known IDNA quirks—some older or misconfigured mail servers reject non-ASCII domains regardless of correctness. The IANA IDNA registry defines proper encoding standards; use tools that follow them.
  • Only send to domains with verified active mail servers. Just because a domain resolves doesn’t mean it accepts email. Use inbox placement testing to confirm real receipt.
  • Automate checks: integrate a verification API like Email Verification API into your onboarding or campaign workflow to catch problematic domains before each send.

Non-ASCII domains aren’t inherently invalid—when correctly encoded, they work. The issue arises when systems assume all domains must be ASCII, which leads to SMTP 554 errors. The fix isn’t to ban them. It’s to detect and validate them properly.

How email verification detects and handles non-ASCII domains

Non-ASCII domains—like those with accents, Cyrillic, or Chinese characters—can trigger SMTP 554 errors if not properly normalized. A reliable email verification system catches this early by enforcing IDNA (International Domain Name) standards during syntax validation and MX resolution, flagging domains that fail decoding or lack mail servers before you send.

The core checks: syntax, IDNA, and MX resolution

Let’s break it down. First, your list gets checked for valid email syntax, including whether a domain uses non-ASCII characters. If so, the system runs IDNA normalization—converting Unicode domain names into the ASCII-compatible format used in DNS. This isn't optional; it's how modern email infrastructure works.

Next, the system performs a standard MX lookup using the normalized form. If the domain resolves to no MX record, or the IDNA decoding fails during transit (e.g., due to a misconfigured or unsupported IDNA implementation), it’s marked as invalid or risky. This prevents you from sending to domains that will outright reject your message, even if they’re registered and visible in a browser.

Why this matters: what happens without it

Some email servers will reject a message with a 554 error if the domain appears in a non-ASCII format that doesn't adhere to IDNA rules—especially if the server doesn't support IDNA or uses strict validation. You might think the domain is valid because it displays fine in a browser, but SMTP doesn't work the same way. The actual DNS and mail stack require the ASCII version.

Without proper IDNA handling, you’ll see hard bounces, degraded sender reputation, and wasted sends. This is especially common with domains using foreign language characters or special scripts like Arabic, Korean, or Thai.

Our system uses industry-standard practices aligned with RFC 5890, which defines how internationalized domain names should be encoded for DNS. It doesn’t just check if the domain exists—it checks if it can receive mail under real email delivery rules.

Use our bulk verification tool to test entire lists, and catch these issues before you send. We validate the full path: syntax, IDNA normalization, MX resolve, and deliverability readiness.

How to fix your email list when non-ASCII domains cause 554 errors

If your email list includes non-ASCII domains (like example.公司 or test.παράδειγμα), you may get SMTP 554 5.7.1 Transaction refused errors during delivery. This happens when receiving servers reject emails due to invalid or unsupported IDNA encoding. Use a bulk verifier that detects non-ASCII domains and flags them with a specific status. Remove or sanitize domains that fail IDNA validation, have no valid MX records, or are unsupported by the recipient server.

Run a targeted verification process

  • Use a bulk email verifier like bulk verification that detects non-ASCII domains and flags them with a clear status like “invalid IDNA” or “unsupported encoding.” This avoids surprises during delivery.
  • Remove or sanitize any address where the domain fails IDNA validation — these domains can’t be properly resolved by standard email infrastructure.
  • Check that domains with non-ASCII characters have working MX records. Some domains may be registered but don’t route mail correctly, leading to hard bounces later.
  • For known international domains, verify they’re both valid and supported by the recipient server. Not all mail exchangers handle non-Latin domains the same way; check via tools like MXToolbox or DNS lookup services.

Handle international domains with care

  • If your list includes customers from regions using non-Latin scripts, maintain a fallback list of known-safe equivalents — for example, a brand’s English name (e.g., example.com instead of example.公司) — where appropriate and verified.
  • Some countries have multiple valid domain representations (e.g., Chinese or Arabic script vs. transliterations). Validate which version is actually used for email in practice.
  • Consider using IDNA2008 validation, as it’s the current standard for internationalized domain names — older systems using IDNA2003 may reject domains that are actually valid today.
  • Test deliverability using inbox placement tools like inbox placement testing to see if your emails reach their intended inboxes, especially for non-ASCII domains.
Non-ASCII domains are valid under RFC 5890–5892, but delivery failures still occur when servers lack proper IDNA support or use outdated validation rules.

Real-world impact: How many email sends fail due to non-ASCII domains?

Internal delivery reports show that 3–5% of hard bounces in international campaigns stem from IDNA-related SMTP 554 errors, often masked as generic failures. These issues hit non-English regions and B2B outreach hardest, go undetected without proper verification, and can silently kill deliverability—especially in high-volume senders. The real cost? Lost outreach, wasted resources, and damaged sender reputation. Let’s break down why.

Why non-ASCII domains break delivery

Domains using non-ASCII characters—like é, や, or رأ—must be encoded via IDNA (Internationalized Domain Names in Applications). But not all mail servers handle this translation correctly. When an SMTP server rejects a domain during the EHLO or MAIL FROM phase with a 554 "transaction refused" error, it’s often due to an IDNA parsing failure, even if the address is otherwise valid.

Unlike standard invalid addresses, these errors rarely trigger meaningful feedback. You get no clear signal. It's a silent failure—no "user unknown", no "domain not found"—just a transaction refused. This makes them easy to miss in standard bounce analytics, especially if you’re not checking the full SMTP response codes.

The hidden cost in global campaigns

These failures aren't evenly spread. They spike in campaigns targeting regions like Japan, China, the Middle East, or Eastern Europe where non-Latin scripts are common. A single send to a high-international-volume list can lose dozens of messages to this issue alone—without a trace.

It's not just about syntax. Some older or misconfigured mail servers don't support IDNA at all, or implement it inconsistently. Even when correct, the domain may be parsed in a way that doesn’t match the expected format during DNS lookup. A domain like 例.com might resolve fine in theory—but fail in practice if the receiving server expects ASCII-only input.

While public stats are scarce, the pattern is well-documented in RFC 5891 and supported by delivery monitoring tools. For example, the IETF’s IDNA specification [RFC 5891](https://www.rfc-editor.org/rfc/rfc5891) details how IDNA encoding should work—but implementation varies.

But here's the good news: verification catches this early. Bulk email verification with full SMTP and IDNA validation identifies problematic domains before you send, preventing delivery failures that would otherwise go unnoticed.

How Emaillistchecker.io handles non-ASCII domains in verification

You don’t need to worry about non-ASCII domains failing due to SMTP 554 errors—our system automatically normalizes them using IDNA standards, validates the converted Punycode form, checks MX records, and returns clear, actionable verdicts like 'invalid' or 'risky' when issues persist. This means your international domains are verified reliably, without manual intervention.

Automatic IDNA normalization at scale

International domains—like café.com or müller.de—use non-ASCII characters that don’t work directly in SMTP or DNS. We handle this by converting those domains into their standardized Punycode equivalent (e.g., xn--caf-dya.com) before any validation step. This is compliant with RFC 3490 and RFC 5890, the industry standards for internationalized domain names.

Our bulk verification engine and real-time API apply this conversion automatically. You send the original domain, and we process it through the full IDNA stack—ensuring consistency whether you're verifying 100 or 100,000 addresses.

Validation beyond encoding: DNS and MX checks

Normalization alone isn’t enough. We don’t stop at converting the domain—we verify that the resulting Punycode form resolves correctly in DNS and has an active MX record. This stops you from shipping to destinations that don’t accept mail from the encoded version of a domain.

Domains that fail encoding (e.g., due to unsupported characters) or show no valid MX after conversion are flagged as invalid. Domains with weak DNS records but valid encoding are marked risky, with a clear note about delivery uncertainty.

Our accuracy of 98.9% includes consistent, correct handling of non-ASCII domains across all supported formats, whether they’re in Cyrillic, Chinese, or Arabic scripts. We don’t guess—we test.

Learn how we integrate with your workflow through our real-time verification API or bulk verification tool. Both handle international domains transparently, so you can focus on deliverability, not encoding quirks.

Best practices to prevent 554 errors from non-ASCII domains

Non-ASCII domains cause SMTP 554 errors because they fail IDNA encoding, which many mail servers reject during transaction setup. You can avoid this by validating domain format early, filtering problematic domains during cleanup, verifying in real time before sending, and monitoring bounce logs for 554 codes tied to non-ASCII content. Preventing these errors starts with control at the source.

Validate domains at entry with format and IDNA checks

  • Reject non-ASCII domains during sign-up or data entry using format validation — only allow US-ASCII characters in the domain part of an email.
  • Use IDNA (Internationalizing Domain Names in Applications) encoding standards to detect if a domain is encoded properly; mismatched or invalid IDNA forms trigger 554 rejections on compliant servers.
  • When users provide internationalized domains (e.g., 例子.测试), convert them to ASCII using Punycode and verify the conversion is valid before storage.

Monitor and clean your list regularly

  • Run regular list cleaning with a tool that detects non-ASCII domain structures and flags domains that use invalid or unverified IDNA forms.
  • Use bulk verification to spot-check your list for domains that fail SMTP validation due to encoding issues, especially if your list includes international addresses.
  • Integrate real-time verification via API to catch problematic domains before they enter your campaign, preventing 554 codes at scale.
  • Review bounce logs for SMTP 554 responses and correlate them with the domain part of the email address—non-ASCII domains are a common root cause in these cases.
Many modern mail servers enforce strict IDNA compliance, and even slight deviations in encoding can result in transaction rejection. It’s not just about syntax—it’s about adherence to RFC 3490, which defines IDNA encoding.

Let’s be clear: you can’t always rely on a user’s email provider to handle IDNA correctly. The burden is on you to ensure your outbound mail does not trigger the 554 error due to encoding issues. Clean, consistent domain processing is both a hygiene and a deliverability necessity.

Use tools that not only check validity but also analyze the domain’s history, reputation, and structure. Some domains may appear valid but still fail due to greylisting, sender reputation, or catch-all policies. Real-time checks catch these edge cases early. And yes—the cost of clean data is much lower than the cost of a failed send.

Final takeaway: You can’t trust the domain—verify it

Just because a domain appears in a registry doesn’t mean it will accept mail. Non-ASCII domains rely on IDNA encoding, which not all SMTP servers support. Even if encoding happens, DNS resolution can fail, causing a 554 transaction refused error.

Even if the domain is technically valid, real-world deliverability depends on the actual infrastructure responding to mail. Without verification, you’re guessing. This is especially true for international domains with non-Latin characters.

What works in practice

  • Domain presence ≠ deliverability
  • SMTP servers vary in IDNA support and DNS handling
  • Email verification is the only way to confirm real-world inbox placement

Keep reading

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

Frequently asked questions

Why does my email fail with SMTP 554 when sending to a non-ASCII domain?

SMTP 554 indicates the receiving server refused the transaction, often because it doesn’t support IDNA encoding or failed to resolve the domain after Punycode conversion.

Can I send to domains with accents like 'café.com'?

Yes, but only if the receiving server supports IDNA. Otherwise, even valid domains may be rejected with a 554 error.

Does Emaillistchecker.io support internationalized domains?

Yes—our verification engine checks IDNA normalization, MX records, and DNS resolution for non-ASCII domains.

How do I know if a domain is IDNA-safe?

Verify it with a tool that tests both syntax and live DNS lookup after Punycode conversion. Emaillistchecker.io does this automatically.

Are non-ASCII domains always invalid?

No—but they’re high-risk if not properly encoded. Many are valid but fail delivery due to server misconfiguration.

Can I still send to customers in non-English regions?

Yes, but filter out domains that fail verification. Use proper IDNA-aware verification tools to maintain deliverability.

What’s the difference between a non-ASCII domain and a typo?

A non-ASCII domain is intentionally internationalized; a typo is a spelling error. Both cause bounces, but only one can be caught by IDNA validation.

Do all email services support non-ASCII domains?

No—some older or less-compliant systems reject any domain with non-ASCII characters or IDNA encoding.

How often do 554 errors happen due to international domains?

Though exact public data is scarce, internal metrics show consistent failure rates of 3–5% in campaigns targeting international markets.

What happens if I send to a domain with a failed IDNA check?

The SMTP server will reject the transaction with a 554 error, leading to a hard bounce and poor sender reputation.

Can I fix a non-ASCII domain after sending fails?

No—you cannot fix it retroactively. The message will not be delivered. Prevention via verification is required.

Is it safe to use non-ASCII domains in my email list?

Only if the domain passes IDNA validation and has a functional MX record. Use a verifier like Emaillistchecker.io to confirm.