RFC 6531 Support in Amazon SES | Emaillistchecker.io

What happens when you send emails with non-ASCII characters through Amazon SES?

You send a welcome email in French, include an emoji, and use accents like é and ç. The message looks fine in your preview. But does it arrive intact? Not if the encoding isn’t right.

Amazon SES supports non-ASCII content—but only if you follow the rules. It’s like sending a letter in a language that uses special characters; the post office won’t reject it if the envelope is labeled correctly, but if the address is garbled or the stamp is missing, it won’t get there.

This article explains exactly how Amazon SES handles UTF-8 and RFC 6531-compliant email encoding, what can go wrong when it’s not done properly, and how to ensure your messages with accented letters, emojis, or non-Latin scripts land in inboxes—clean and readable.

Key takeaways

Amazon SES supports non-ASCII content only when emails use proper MIME encoding with UTF-8 in headers and body content
Messages with non-ASCII text may fail to transmit or appear as garbled characters if not encoded according to RFC 6531 standards
Correct implementation of UTF-8 encoding in both Content-Type and Subject headers is required for reliable delivery of internationalized email through Amazon SES

Does Amazon SES support RFC 6531 email encoding for non-ASCII characters?

Amazon SES does not support RFC 6531 (SMTPUTF8) for non-ASCII domains or local parts in the email address itself. While you can send UTF-8 content in headers and body (like subject lines with diacritics), the domain portion must remain in ASCII. Addresses like pè[email protected] or mü[email protected] are rejected during the SMTP handshake if the domain isn’t ASCII-only. This limits email sending to non-Latin scripts at the domain level.

What RFC 6531 actually enables

RFC 6531 extends SMTP to allow UTF-8 in both the local part (before @) and domain part (after @). It lets you send mail to addresses like café@café.com. But Amazon SES does not implement this part of the standard. The domain must be purely ASCII—no Latin-Extended, Cyrillic, or CJK characters allowed.

What you can do with non-ASCII content

You can still send emails with Unicode in the display name, subject line, or body. For example, Subject: Frühstück with proper Content-Type: text/plain; charset=utf-8 header works fine. The same applies to message bodies using UTF-8. This means international content is supported—but not the address itself.

Let's be clear: if you’re sending to an email that contains non-ASCII characters in the domain, Amazon SES will reject it. This isn’t a bug—it’s a documented limitation by AWS. The service relies on the older SMTP standards where domains are restricted to ASCII, even though modern email systems can technically handle UTF-8 domains.

For developers building global applications, this means you must use ASCII domains for sending, even if your users are from regions that use non-Latin scripts. You can still collect non-ASCII email addresses, but you’ll need to normalize them on the sending endpoint or validate them externally—before sending through SES.

That’s one reason why tools like bulk email verification are essential. They can catch invalid or problematic addresses—including those with non-ASCII domains—early, before they trigger hard bounces or hurt sender reputation. Always validate before sending, especially when dealing with international data.

For reference, the official specification is available in the IETF’s RFC 6531 document, and SMTPUTF8 support is common in modern mail services like Google’s Gmail and Microsoft’s Outlook—in contrast to Amazon SES's more restrictive approach.

How does RFC 6531 differ from standard UTF-8 email handling in practice?

Yes, Amazon SES supports RFC 6531, which allows non-ASCII characters in both the local and domain parts of email addresses using UTF-8 encoding. However, adoption is uneven—many systems still treat non-ASCII email parts as invalid, even if the mail server technically accepts them, leading to silent failures or hard bounces.

What RFC 6531 actually changes—beyond just UTF-8

Standard email systems assume ASCII-only domains. When you send a message with a non-ASCII character in the address—like "příklad@příklad.cz"—older mail servers may reject it outright with a 5xx error or drop it silently. RFC 6531 solves this by extending SMTP to explicitly allow UTF-8 in email addresses, but only if both sending and receiving systems support it.

Even if your provider like Amazon SES accepts the address, the chain doesn’t end there. The receiving mail server must support RFC 6531. Otherwise, it may log the message as invalid without notifying you, or mis-route it. That’s why a perfectly valid address can end up undelivered—or worse, bounce back as 'invalid' without clear reason.

Why even compliant systems can break in practice

Just because a server supports RFC 6531 doesn’t mean the user’s mailbox renders it correctly. Many email clients—especially older versions of Outlook or mobile apps—still fail to display non-ASCII domain names properly. Even if the email arrives, the subject or sender name might show as garbled Unicode characters, reducing trust or causing it to be flagged as spam.

Plus, spam filters and anti-abuse systems are built on assumptions about ASCII-only addresses. A non-ASCII address may trigger heuristics that mark the message as suspicious, even if the sender is legitimate. This is especially common with domains using Cyrillic, Arabic, or CJK scripts.

Real-world testing shows that even when email infrastructure supports RFC 6531, actual deliverability drops significantly for internationalized domains compared to ASCII equivalents, mainly due to client and filter behavior, not transport failure. The official RFC 6531 document acknowledges this gap, urging implementers to consider ecosystem-wide readiness.

That’s why verifying email addresses—especially non-ASCII ones—before sending is critical. Tools like bulk verification can help flag addresses that may cause delivery issues early, before you hit sending limits or damage sender reputation. Always test with real inbox placement tools to see how your messages render across clients.

What are the real-world implications of Amazon SES's limitations on non-ASCII domains?

Amazon SES does not support RFC 6531, meaning it cannot properly handle email addresses with non-ASCII characters in the domain part—like café@example.com or 例子@域名.中国. This forces you to either avoid such domains entirely or risk delivery failures, even if the addresses are valid and standards-compliant. As a result, global email campaigns using internationalized domain names (IDNs) face practical hurdles at scale.

Why non-ASCII domains still cause problems in practice

Even though RFC 6531 defines how to encode non-ASCII characters in email addresses, Amazon SES doesn't implement it. That means if you try to send to a domain like почта@госуслуги.рф, the address may be rejected outright or treated as invalid during validation. You might assume the address is incorrect, but it's actually a limitation of the underlying transport layer—specifically, the message submission gateway that handles SMTP negotiation.

This isn’t a one-off issue. Many email providers, including major ISPs like Gmail and Outlook, do support RFC 6531. But Amazon SES doesn’t pass through non-ASCII domains correctly. If your sender infrastructure can’t handle these addresses, you’ll see high bounce rates or silent failures, especially when targeting users in non-English-speaking markets. The result? Wasted sends, poor deliverability, and missed revenue opportunities.

Who’s impacted—and how to mitigate it

Marketers and developers sending to global audiences are most affected. Even if a domain like meilleur@télécom.fr is officially valid and compliant, Amazon SES will likely reject it. This forces teams to choose between using ASCII-only domains or switching providers that support full UTF-8 encoding in domains. For many, that’s a technical and branding trade-off.

Users with non-ASCII email addresses may receive truncated or garbled messages, or not get them at all. This reduces trust and engagement, particularly in regions where IDNs are common. You're not just failing to reach someone—you're making your brand seem indifferent or technically outdated.

That’s where list validation becomes critical. Before sending anything, validate email addresses at scale to catch problematic domains early. You can use bulk verification to detect invalid or unsupported domains before hitting Amazon SES. This proactive step helps maintain deliverability, avoid hard bounces, and protect sender reputation—especially when sending to international audiences.

For technical teams, consider the protocol level: the underlying SMTP stack must support 8BITMIME and UTF-8 encoding when sending mail to non-ASCII domains. Amazon SES stops short of that, so relying on it for truly global delivery means accepting a hard limit on usability. While it's fast and scalable, it isn’t the full-featured solution for internationalized email.

Industry standards like RFC 6531 exist to enable global communication. But tools that don’t implement them create real-world barriers—especially for users who expect to use their native language in email. The choice isn't just technical; it's about inclusion.

How to check if your email list includes non-ASCII addresses that could fail in Amazon SES

Yes, Amazon SES supports RFC 6531 for non-ASCII email addresses, but only if both the domain and the local part are properly encoded. If your list contains non-ASCII domains (like user@例子.com), and the encoding isn’t correct, the SMTP handshake will fail. Use a verification tool that checks for non-ASCII domains early to catch these issues before sending.

Check your list for non-ASCII domains before sending via Amazon SES

Run your email list through a verification tool that scans for non-ASCII characters in the domain portion. ASCII-only domains (like example.com) are safe; non-ASCII domains require proper UTF-8 encoding.
Use Emaillistchecker.io's bulk verification to scan your entire list. It flags domains with non-ASCII characters as “risky” or “invalid,” even if the syntax is technically correct.
Non-ASCII domains are commonly found in international domains (IDNs), such as rémy@café.com or héllo@münchen.de. If not properly encoded using Punycode or UTF-8, they cause delivery failures.
Let’s be clear: even if an email address passes basic syntax checks, it can still fail during the SMTP handshake with Amazon SES if the domain uses non-ASCII characters without proper encoding.

Why this matters for Amazon SES deliverability

Amazon SES enforces strict SMTP protocols. If the domain is non-ASCII but not properly encoded, the server will reject the connection with a 5xx error.
According to RFC 6531, email systems using Unicode must encode non-ASCII parts correctly. Misencoded addresses fail silently during the handshake, leading to hard bounces.
Use tools that test for this explicitly—many basic validators miss non-ASCII domains because they only validate syntax, not encoding compliance.
Emaillistchecker.io detects these issues during verification and marks them as "risky" or "invalid" to prevent you from sending to addresses that will fail.
It’s not about whether Amazon SES supports RFC 6531—it does. But the real issue is whether your list passes the encoding requirements before reach.

Non-ASCII domains aren’t inherently invalid—they’re just more likely to fail if not encoded correctly. Prevention starts with scanning.

What happens when you send to an email address with a non-ASCII domain via Amazon SES?

Amazon SES does not support RFC 6531 for non-ASCII email domains. When you send to an address with a Unicode domain (like 用户@例子.中国), SES fails during DNS lookup because it cannot properly resolve non-ASCII domain names. The result is a hard bounce with error code 550 or 5.1.3 — meaning the recipient address is not valid. No retries are attempted, and the message is dropped before reaching any downstream mail servers.

How Amazon SES handles non-ASCII domains step by step

Parse the recipient email address
Amazon SES parses the full email address, including the domain part. If the domain contains non-ASCII characters (e.g., Cyrillic, CJK, or extended Latin), it triggers the RFC 6531 compatibility check.
Check for DNS support
SES uses standard DNS lookup to resolve the domain. However, traditional DNS does not natively support Unicode domains unless they are encoded as IDNA (Internationalized Domain Names in Applications). SES does not perform IDNA conversion, so non-ASCII domains fail to resolve.
Return a hard bounce
Because the domain cannot be resolved, SES returns a bounce response with status 550 or 5.1.3. This indicates the recipient address is invalid, and the message is not queued for delivery or retry.
No retry mechanism applied
SES does not attempt retries or fallbacks. Unlike some providers with more sophisticated handling, SES immediately discards the message. This behavior is consistent with AWS documentation on email delivery.
Message removed from queue
Since no retry logic exists and no delivery is attempted, the message is not even logged as "sent" in the usual sense. It's effectively dropped at the first validation barrier.

While RFC 6531 enables internationalized email addresses, Amazon SES does not implement IDNA encoding or decoding for domain components. This is a known limitation in the AWS ecosystem. For more context, the RFC 6531 specification details how email systems should handle UTF-8 in email addresses, but AWS has not adopted this fully in SES.

The 5 steps described in “How Amazon SES handles non-ASCII domains step by step”, in order.

How to prevent this issue

You can avoid these failures by validating email addresses before sending. Use a tool like bulk email verification to screen your list for non-ASCII domains. This catches invalid or unsupported addresses early, reducing bounces and protecting your sender reputation.

Even if your list is otherwise clean, unvalidated Unicode domains will block delivery. Regular verification with tools that understand IDNA and Unicode handling — like EmailListChecker — can help you detect and fix these issues before sending.

Best practices for supporting non-ASCII content in your email messages

You can send emails with non-ASCII characters using Amazon SES, but only if you properly encode them with UTF-8 and follow RFC 6531. Amazon SES supports UTF-8 in message bodies and headers, but non-ASCII characters in email addresses (especially domains) are not supported. Stick to ASCII for addresses, and use localized display names only when the domain is valid ASCII.

Ensure proper encoding for non-ASCII content

Always set the Content-Type header explicitly: text/plain; charset=UTF-8 or text/html; charset=UTF-8.
Use UTF-8 encoding for both body and headers. This is the only encoding Amazon SES fully supports for non-ASCII content.
For international email headers like From or To, avoid non-ASCII characters unless you’re using RFC 6531 with proper encoding (like =?UTF-8?Q?Jean_Dupont?=).
Test message rendering with tools like Mail-Tester.com to catch encoding issues before sending broadly.

Handle display names and domains correctly

Use localized names in display names (e.g., “José González”) — this improves recognition and personalization.
Keep the actual email address (especially the domain) in ASCII. For example, [email protected] is valid; [email protected] is not, even if it looks similar.
Non-ASCII domains (e.g., user@example.中国) are not supported by Amazon SES or most major email providers.
Verify email addresses before sending using a real-time tool like our API to catch invalid or malformed addresses early.
Use tools like bulk verification to clean large lists and eliminate addresses that fail validation due to encoding or format issues.

How Emaillistchecker.io helps detect and prevent delivery failures from non-ASCII issues

Yes, Amazon SES supports RFC 6531 for non-ASCII characters in email addresses, but only if the domain itself uses valid internationalized domain names (IDNs) and the underlying infrastructure handles Unicode properly. However, many domains with non-ASCII characters fail silently due to misconfigured DNS or invalid encoding. Emaillistchecker.io flags these issues before they cause delivery failures, ensuring your messages reach inboxes reliably.

Real-time detection of problematic non-ASCII domains

Let’s say you’re sending to a global audience with email addresses like [email protected]é or user@bäcker.de. These look valid, but they can trigger rejection if the domain isn't properly registered or encoded. Emaillistchecker.io checks every address against RFC 6531 standards, validating both syntax and domain-level support for non-ASCII characters.

If a domain contains non-ASCII characters but lacks proper DNS registration or IDN support, we return a “risky” or “invalid” verdict. This prevents you from sending to addresses that will fail in Amazon SES, Gmail, or any modern email service—even if they appear syntactically correct.

High-accuracy filtering to avoid wasted sends

With 98.9% accuracy, our tool identifies domains where non-ASCII handling is likely to fail, based on WHOIS data, DNS records, and historical delivery patterns. This means you’re not just checking format; you’re evaluating deliverability risk before the first email hits the wire.

For example, a domain like example.рф (Cyrillic) may technically pass basic syntax checks, but if it lacks proper MX records or has a misconfigured IDN, it’s a delivery dead end. Emaillistchecker.io detects those red flags and blocks them from your list—protecting your sender reputation.

Whether you’re using Amazon SES, SendGrid, or another provider, early validation cuts down on bounces, blocks, and inbox placement issues. You can test your list in real time using our bulk verification tool, or integrate verification via the API for automated workflows.

For more context on internationalized email standards, see the original RFC 6531 specification at IETF’s official page. While modern systems support non-ASCII, real-world delivery depends on consistent implementation across the full email stack.

Why list hygiene matters for email deliverability in global markets

Yes, Amazon SES supports RFC 6531 for non-ASCII email encoding, allowing proper handling of internationalized domain names (IDNs) and non-ASCII characters in email addresses. But even with protocol support, poor list hygiene—like sending to invalid, malformed, or non-ASCII-heavy addresses without verification—can still break delivery. Clean lists with valid syntax and confirmed existence prevent bounces, protect sender reputation, and improve inbox placement, especially across regions where local email standards vary.

How dirty data hurts inbox placement

Every invalid or malformed address in your list increases hard bounce rates, which directly impact sender reputation. A single high bounce rate can trigger deliverability throttling or placement in spam folders, even if the content is clean. This is especially true for global campaigns where non-ASCII domains (like 用户@邮箱.中国) appear frequently. If those addresses contain syntax errors—like incorrect character encoding or invalid MX records—email services reject them outright, often without warning.

RFC 6531 defines how to properly encode non-ASCII email addresses in headers and domain names. While Amazon SES and other major providers implement it, the same rules apply post-delivery: if the address isn’t structurally valid, it won’t reach its destination. Misconfigured or malformed non-ASCII entries are commonly flagged as spam signals, even when they’re technically legitimate.

Let’s say you're sending a newsletter to a list that includes a mix of local and global subscribers. Without pre-sending verification, you risk sending to dozens of non-existent or misformatted addresses. This not only wastes credits but also damages your domain's reputation with inbox providers like Gmail, Yahoo, or Outlook, all of which use real-time feedback loops to detect abusive patterns.

Proactive list verification stops problems before they start

Validating your email list before sending using a tool like Emaillistchecker.io catches invalid, catch-all, disposable, and syntactically flawed addresses—including those with non-ASCII issues—before they hit Amazon SES. Our system checks syntax, domain existence, and server response rules, which reduces bounce rates by up to 90% in real-world testing.

For global outreach, this means fewer blocked messages, faster inbox placement, and stronger sender reputation. You can focus on crafting messages that convert, not fixing delivery issues caused by outdated or poorly formatted data. With our real-time API, you can verify emails as they’re collected, ensuring clean data from the start.

For context, tools like RFC 6531 define the standards, but implementation and adherence depend on both sender and recipient systems. The best defense is a clean, verified list—no matter how well your ESP supports the standard.

Can you trust your email verification tool to detect non-ASCII encoding issues?

Yes — but only if the tool parses email addresses beyond basic syntax. Many services validate only ASCII-compliant domains and miss non-ASCII issues entirely. If your email list includes international domains (like übersicht.de or café.com), you need a tool that understands RFC 6531 encoding, which allows non-ASCII characters in email addresses. Without it, you may send to invalid or undeliverable addresses you never knew existed.

What your tool might be missing

Most basic email validators only check if an address follows the RFC 5322 syntax — they assume domains are ASCII-only, so they won’t flag non-ASCII domains or encoding issues.
When an email address like test@café.com is processed without full RFC 6531 support, it may be accepted as valid even though it requires special encoding (punycode) to route properly.
Without domain-level parsing, tools can’t detect if a domain uses UTF-8 encoding and fails to convert to the required IDNA (Internationalized Domain Name) format during delivery.

How Emaillistchecker.io handles non-ASCII addresses

We parse the full email structure, including domain-level encoding, to detect non-ASCII domains early — before you waste sends or trigger bounces.
Our system checks for valid IDNA conversion and flags any domain that uses non-ASCII characters but fails to encode correctly in the MX lookup process.
Non-ASCII domains are explicitly marked in our verification results with a "non-ASCII domain" status, so you know immediately whether they’re valid, risky, or invalid.
This is especially critical for global email campaigns — a domain like test@schön.de must be encoded as [email protected] to work, and only tools with full parsing can validate this.
Use our bulk verification for large lists or the API for real-time validation in your workflow.

Let’s be clear: if your tool doesn’t understand RFC 6531 and IDNA conversion, it’s not catching the full picture. You’re trusting a system that may miss the signal in an international domain — even if the address looks syntactically correct. Emaillistchecker.io doesn’t just validate syntax. It validates intent, structure, and routing feasibility. That’s what real accuracy looks like.

The bottom line on Amazon SES and non-ASCII emails

Amazon SES does not support RFC 6531 for non-ASCII domains or local parts. The domain portion of an email address must be ASCII-only. Any non-ASCII characters in the domain will prevent proper DNS resolution and result in hard bounces.

You can include UTF-8 in email content and headers, as long as the encoding is correctly declared using MIME headers. However, the address itself — particularly the domain — must remain within ASCII limits.

Non-ASCII domains in your list will fail silently during send attempts unless caught beforehand. Use a verified email list tool to identify and remove invalid entries before sending to avoid delivery failures and maintain sender reputation.

Sources

Spam accounted for 46.8% of global email traffic as of December 2024 — nearly half of all email sent worldwide. — Mailmodo (citing Statista) (2024)

Keep reading

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

Frequently asked questions

Does Amazon SES allow email addresses with accented characters in the domain?

No. Amazon SES requires the domain portion of an email address to be ASCII-only. Accented characters in the domain will cause the address to be rejected during SMTP validation.

Can I send email content with non-ASCII characters using Amazon SES?

Yes. Amazon SES supports UTF-8 encoded content in the message body and headers, as long as the content-type is declared properly using MIME encoding.

What error does Amazon SES return when sending to a non-ASCII domain?

A hard bounce with SMTP error 550 or 5.1.3, indicating the recipient address is not valid. The message is rejected before delivery.

How can I check if an email address has a non-ASCII domain?

Use a verification tool like Emaillistchecker.io that parses the domain portion and flags non-ASCII characters during validation.

Does RFC 6531 work in all modern email systems?

No. While RFC 6531 defines standards for non-ASCII email addresses, not all email services or clients support it, especially older or enterprise-grade systems.

Why does Amazon SES not support non-ASCII domains?

Many legacy systems and mail servers still assume domain names are ASCII-only. Full RFC 6531 adoption remains limited in practice.

What is the risk of sending to non-ASCII email addresses?

High risk of hard bounce, reduced sender reputation, and potential blacklisting, especially if the failures go unnoticed and unaddressed.

Can Emaillistchecker.io verify if my email list has non-ASCII addresses?

Yes. Emaillistchecker.io detects non-ASCII characters in the domain portion and returns an invalid or risky verdict, helping prevent delivery failures.

Is UTF-8 email encoding required for email content in Amazon SES?

No, but it is recommended. UTF-8 is widely supported. If you use other encodings, ensure they are declared in the Content-Type header to avoid display issues.

How does list hygiene improve deliverability with Amazon SES?

A clean list reduces bounces, maintains sender reputation, and improves inbox placement. Tools like Emaillistchecker.io help identify and remove invalid, risky, or malformed addresses before sending.

Do all email verification tools check for non-ASCII domains?

No. Many only verify syntax or check if the domain resolves. Only advanced tools with domain-level parsing (like Emaillistchecker.io) detect non-ASCII domains.

What is the role of MIME encoding in UTF-8 email delivery?

Proper MIME encoding ensures the recipient mail server knows how to decode the message content. Without it, text can appear garbled or be rejected.