SMTPUTF8, Unicode email addresses, security risks, and real-world compatibility.
Email validation seems straightforward. Users enter an email address, the application checks its format, and registration continues.
But what happens when someone registers with müller@example.com?
We recently discussed whether our registration process should allow Unicode characters in the local part of email addresses - the portion before the @ symbol.
At first glance, the answer seems simple. If an email address is permitted by established standards, why reject it?
However, supporting an email address involves more than accepting it during registration.
Email delivery compatibility, authentication workflows, third-party integrations, and security considerations all influence the decision.
What Is SMTPUTF8?
Traditionally, email addresses have primarily used ASCII characters. The SMTPUTF8 extension, defined in RFC 6531, enables internationalized email addresses containing non-ASCII characters.
This allows email addresses such as:
müller@example.comδοκιμή@example.com用户@example.com
An important distinction exists between internationalized domain names and Unicode characters in the local part.
| Email address | Characteristics | Compatibility |
|---|---|---|
john@example.com |
ASCII local part and domain | Widely supported |
user@bücher.example |
Unicode domain | Can use Punycode encoding |
müller@example.com |
Unicode local part | Requires SMTPUTF8 |
δοκιμή@example.com |
Greek local part | Requires SMTPUTF8 |
Internationalized domains can be represented using Punycode, an ASCII-compatible encoding.
However, this approach cannot be used to convert Unicode local parts into equivalent ASCII email addresses.
SMTPUTF8 support is required to transport these addresses.
And that is where compatibility becomes a challenge.
The AWS SES Compatibility Problem
Amazon Simple Email Service (AWS SES) is widely used for transactional emails, including registration confirmations, password resets, and account notifications.
However, AWS SES does not support the SMTPUTF8 extension.
According to its documentation, email address strings must use 7-bit ASCII. Internationalized domains can use Punycode, but Unicode local parts are not supported.
Consider an application that accepts:
müller@example.com
The application might successfully validate the address and store it in a UTF-8-compatible database.
But when it attempts to send a verification email through AWS SES, the request cannot use that recipient address.
The result is a broken registration workflow.
The application accepts an address that its email infrastructure cannot support.
This demonstrates why validation rules must consider the capabilities of external dependencies.
Security Concerns: When Different Characters Look Identical
Compatibility is not the only concern.
Unicode introduces additional security considerations, particularly when visually similar characters belong to different writing systems.
For example, the Latin letter o and Cyrillic letter о look nearly identical in many fonts.
However, they are different characters with different Unicode code points.
Consider these two addresses:
| Email address | Character used | Unicode |
|---|---|---|
support@example.com |
Latin o |
U+006F |
suppоrt@example.com |
Cyrillic о |
U+043E |
In the second address, the letter that looks like "o" is actually Cyrillic.
To a human reader, these addresses might appear identical.
To a computer, they contain different character sequences.
This creates opportunities for homograph attacks, where visually similar characters are used to impersonate trusted identities.
Potential security concerns include:
- Identity impersonation: An attacker controlling a lookalike address could attempt to impersonate a legitimate user.
- Account confusion: Applications displaying email addresses as user identities may make visually similar accounts difficult to distinguish.
- Access control mistakes: Systems relying on poorly designed string comparisons or manually maintained allowlists may handle visually similar addresses incorrectly.
- Social engineering: Lookalike addresses may mislead users, administrators, or support teams.
These issues do not mean Unicode addresses are inherently malicious.
Nor does a lookalike address automatically receive messages intended for another mailbox. The attacker would need control of the address they are using.
However, the risks become particularly relevant when email addresses function as visible identifiers or are used in security-sensitive decisions.
RFC 6530 explicitly discusses confusable characters and homograph attacks in internationalized email addresses.
Why This Matters for Registration and Authentication
Email addresses are rarely used only during initial registration.
They often become part of critical application workflows:
- Account registration and verification.
- User authentication and account identification.
- Password recovery.
- Security notifications.
- Administrative account management.
A failure in any of these workflows can create usability or security problems.
Email verification confirms that someone can receive messages at an address. It does not establish that the address is visually distinct from another user's address or that its owner is trustworthy.
Applications should therefore avoid making authorization decisions based on how an email address appears to a human reviewer.
ASCII-Only vs. SMTPUTF8: Comparing the Approaches
Choosing whether to support Unicode local parts involves several trade-offs.
| Consideration | ASCII-only local parts | SMTPUTF8 support |
|---|---|---|
| Email compatibility | Broad support | Depends on infrastructure |
| Internationalization | More restrictive | More inclusive |
| Implementation complexity | Generally lower | Additional requirements |
| Homograph exposure | Reduced in local parts | Requires additional consideration |
| Third-party integrations | More compatible | Requires verification |
| Testing requirements | Simpler | More edge cases |
Neither approach is universally correct.
For applications relying on providers without SMTPUTF8 support, restricting Unicode local parts may be a reasonable engineering decision.
For applications serving international audiences, supporting SMTPUTF8 may be an important requirement.
The decision should reflect the product's needs, infrastructure capabilities, and security requirements.
Practical Recommendations for Developers
Before enabling SMTPUTF8, development teams should consider several areas.
1. Verify infrastructure compatibility
Confirm that email providers, authentication services, and third-party integrations support internationalized email addresses.
2. Validate the complete registration workflow
Do not assume that successful syntax validation guarantees successful email delivery.
Test verification emails, password resets, and other critical communication flows.
3. Consider Unicode confusable-character detection
Unicode Technical Standard #39 provides mechanisms for identifying visually confusable characters and mixed-script identifiers.
These mechanisms can help applications flag suspicious addresses for additional review.
However, automatically rejecting every mixed-script address may unnecessarily exclude legitimate users.
4. Handle Unicode normalization carefully
Unicode normalization can address certain differences in character representation, but it does not automatically eliminate visually confusable characters.
The Latin o and Cyrillic о, for example, remain distinct.
Applications should avoid blindly replacing, lowercasing, or transforming email local parts, because mailbox interpretation depends on the receiving provider.
5. Keep authentication identities separate
Use stable internal user identifiers for authorization and account relationships rather than treating the displayed email address as a trusted identity.
6. Test security-sensitive edge cases
Include visually similar addresses, different Unicode representations, and internationalized addresses in integration and security tests.
Frequently Asked Questions
Are Unicode email addresses valid?
Yes. Internationalized email standards permit Unicode characters in email addresses under defined conditions. However, syntax validity does not guarantee that every email provider can handle them.
Does AWS SES support SMTPUTF8?
No. AWS SES documentation states that SMTPUTF8 is not supported. Email addresses must use ASCII, although internationalized domains can be represented using Punycode.
Are Unicode email addresses a security risk?
Not inherently. However, visually confusable characters can create impersonation and identity-management risks if applications do not handle them appropriately.
Should applications reject Unicode email addresses?
Not automatically. The decision should consider internationalization requirements, infrastructure compatibility, and appropriate security controls.
Final Thoughts
Email validation is often treated as a simple implementation detail.
In reality, it connects application logic, external services, user experience, and security.
SMTPUTF8 demonstrates how an established standard can introduce practical challenges when infrastructure support is inconsistent.
Unicode lookalike characters add another consideration: two addresses that appear identical to users may represent different identities.
The goal is not merely to accept technically valid input, but to ensure that the application can handle it securely and reliably throughout the entire user journey.
References
- RFC 6531 - SMTP Extension for Internationalized Email (opens in a new tab or window)
- RFC 6530 - Internationalized Email Framework, Security Considerations (opens in a new tab or window)
- Unicode Technical Standard #39 - Unicode Security Mechanisms (opens in a new tab or window)
- Amazon SES - SendEmail API Documentation (opens in a new tab or window)
