Email Address Internationalization
Email Address Internationalization (EAI) is a Salesforce org setting that allows email addresses to contain non-Latin characters in both the local part and the domain.
Definition
Email Address Internationalization (EAI) is a Salesforce org setting that allows email addresses to contain non-Latin characters in both the local part and the domain. When enabled, the platform validates and accepts addresses like 用户@example.com or josé@empresa.es in any field defined as an Email type, and processes those addresses correctly when sending and receiving mail through the standard delivery channels. Without EAI, email fields silently reject non-ASCII characters and surface a validation error to the user.
The setting matters because real customer data includes addresses in scripts beyond the ASCII range. CRM data imported from systems in China, Japan, Korea, the Middle East, or parts of Latin America regularly contains internationalized addresses, and the absence of EAI causes either silent data loss during imports or hard rejections that break sync jobs. Salesforce ships EAI off by default in most editions because the underlying SMTP infrastructure has historically required ASCII addresses, and enabling it changes how the platform validates every Email field across every object.
What changes when you enable EAI
What EAI changes at the field level
EAI affects every field of type Email across standard and custom objects. With the setting off, validation enforces RFC 5322 with ASCII restrictions. With it on, validation accepts internationalized addresses conforming to RFC 6531 (SMTPUTF8). The change is org-wide, not per-object. There is no path to enable EAI for Contact but not Lead; the setting toggles the entire org.
Sending mail to internationalized addresses
Enabling EAI does not automatically enable internationalized email delivery. The receiving mail server must support SMTPUTF8 (the SMTP extension that lets servers exchange UTF-8 addresses). Most modern providers do, but some legacy on-prem systems do not, and Salesforce will fail delivery silently if the receiver rejects the SMTPUTF8 EHLO. Test delivery against a known address before declaring the rollout complete.
Receiving mail through Email-to-Case and Email Services
The Email Services framework that powers Email-to-Case, Email-to-Salesforce, and custom Apex email handlers accepts internationalized From addresses when EAI is enabled. Existing Apex handlers should already work because the Email service surfaces the From address as a string. Test that any custom code parsing the address handles UTF-8 byte counts correctly, since some legacy Apex assumed ASCII-only strings.
Validation rules and formula fields
Validation rules that check email format using REGEX() need updating when EAI is enabled. The standard ASCII regex pattern will reject valid internationalized addresses. Search the org for validation rules referencing the Email field and update the regex to accept UTF-8 characters, or remove the rule and rely on the platform validation that EAI activates.
Imports through Data Loader and APIs
Data Loader and the REST/SOAP APIs respect the org-level EAI setting. With EAI off, an import with internationalized addresses fails at the row level with a validation error. With EAI on, the addresses load successfully. Plan to enable EAI before any data migration that includes internationalized addresses; flipping the switch after an import does not retroactively validate the existing data.
Marketing Cloud and external sends
Marketing Cloud and other third-party sending platforms have their own EAI settings. Enabling EAI in Salesforce only affects native Salesforce sending. If your marketing team uses Marketing Cloud, Pardot, or another sender, confirm those tools also support SMTPUTF8 before promising customers their internationalized addresses will receive mail.
Reversing the setting
EAI can be disabled, but doing so does not delete or invalidate existing internationalized addresses already in the database. Records remain queryable and updatable through APIs. The change only affects future validation: new addresses with non-ASCII characters will be rejected, while existing ones remain. Audit before reversing; you may end up with addresses you cannot edit through the UI.
Roll out Email Address Internationalization safely
Enabling Email Address Internationalization is a one-toggle change in Setup, but the rollout needs sequencing across validation rules, integrations, and downstream tools. Below is the order that avoids breaking existing data.
- Audit existing validation rules
Search Setup with Setup Search for "Email" and Pattern. Identify every validation rule using REGEX() on an Email field. Document which need updates and which can be retired.
- Audit custom Apex on email parsing
Search the codebase for any Apex that parses From addresses or splits on the at sign. Confirm string handling is UTF-8 safe; update if necessary.
- Check downstream sending tools
Confirm Marketing Cloud, Pardot, and any third-party email tools support SMTPUTF8. Without downstream support, enabling EAI in Salesforce will load addresses that other tools cannot send to.
- Enable EAI in Setup
Setup > Email > Deliverability or Email > Email Internationalization (location varies by release). Check Enable Email Address Internationalization and save.
- Test field-level acceptance
Create a test Contact with an internationalized email and confirm the save succeeds. Test through both the UI and the REST API to confirm consistency.
- Test send and receive
Send a test email to an internationalized address from inside Salesforce. Confirm delivery. Then send a test from an internationalized address into your Email-to-Case or Email Services endpoint and confirm receipt.
- Update validation rules
For each rule flagged in step 1, either update the REGEX to accept UTF-8 or remove the rule. Test the change in a sandbox before applying to production.
The master org-level toggle. Off by default; on means non-ASCII addresses validate as legal email format across every Email field.
Related setting controlling how the platform tracks bounce responses. Internationalized sends may show different bounce categories; review after enabling.
All Email, System Email Only, No Access. EAI works the same at any level, but System Email Only restricts user-initiated sends.
Sends a copy of every outbound email to a compliance address. Confirm the compliance inbox handles UTF-8 addresses in headers before relying on it.
Set a per-user Reply-To. Reply-To addresses must conform to the same EAI setting; with EAI off, internationalized Reply-To addresses are rejected.
- Enabling EAI in Salesforce does not enable internationalized sending in Marketing Cloud, Pardot, or any third-party tool. Each tool has its own setting.
- The receiving mail server must support SMTPUTF8 for delivery to succeed. Some legacy on-prem mail servers do not, and Salesforce will fail delivery silently to those recipients.
- Validation rules using REGEX on email fields commonly use an ASCII-only pattern. These rules will reject valid internationalized addresses; audit and update before enabling.
- Reversing EAI does not delete existing internationalized addresses. Records remain queryable and updatable through the API but may not be editable through the UI after the reversal.
- Some legacy Apex assumed ASCII-only email strings. Audit any custom email parsing code for UTF-8 byte-count correctness, otherwise the parser may truncate or mangle addresses.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the primary benefit of Email Address Internationalization for Salesforce administrators?
Q2. Can a Salesforce admin configure Email Address Internationalization without writing code?
Q3. Why is understanding Email Address Internationalization important for Salesforce admins?
Discussion
Loading discussion…