WordPress 7.1 Unicode Emails Put Old Validation Rules on Notice

On May 22, 2026, WordPress Core published its proposal to extend Unicode support in email addresses. By June 10, 2026, that had moved into active WordPress 7.1 testing: the developer roundup said the first 7.1 testing calls had already started, and the Make WordPress Core front page published a specific call for testing on Unicode email addresses. At that point, this stops being an abstract standards discussion. It becomes a practical maintenance question for any business running WordPress in production.

The core patch is probably not where the time goes. The time goes into everything around it that quietly assumed email addresses would always be US-ASCII. WordPress is explicit about the risk surface: validation, sanitization, storage, normalization, visually confusable characters, and extension code that has never had to deal with multibyte email data before. If your site passes email addresses through custom forms, account logic, masked displays, exports, or third-party systems, that is where the paid cleanup work starts.

The core change is no longer hypothetical

This is not a fringe plugin experiment. The related Trac ticket, #31992, has been open for eleven years and now sits on the WordPress 7.1 milestone in Core's Formatting component. The May 22 proposal says WordPress 6.9 already updated PHPMailer so WordPress can send to Unicode addresses, but user accounts still could not use or store them. The June 10 testing update goes further: is_email() and sanitize_email() now accept non-ASCII email addresses when the site's database charset is utf8mb4, and validation is being aligned with the WHATWG rules browsers apply to <input type=email>. Core is also adding a new WP_Email_Address class so plugins and themes can work with the local and domain parts directly instead of guessing from raw strings.

That matters because WordPress is not just broadening what it accepts. It is also signaling that older parsing and validation habits are no longer reliable enough. The testing call keeps an escape hatch as well: if a third-party integration cannot handle Unicode email addresses properly, teams can remove the new filters and stay ASCII-only for now. That is sensible engineering. It also tells you exactly where the risk sits.

Why legacy validation turns into cleanup work

The May 22 proposal is unusually plain about what can go wrong. Sites that cannot store full UTF-8 safely may fail to save valid email addresses. Existing plugin, theme, and filter code may start receiving characters it previously treated as impossible. Simple byte-oriented logic can break in subtle ways: the proposal specifically warns that strlen() gives the wrong kind of answer for multibyte strings, and it calls out antispambot() as an example of code built around older ASCII-oriented assumptions. It also flags normalization, visually confusable characters, and non-visible characters as real concerns.

That is why this becomes a cleanup job rather than a quick toggle. In most commercial WordPress builds, email handling is spread across several layers. A browser validates an address, JavaScript may validate it again, PHP checks it on the server, WordPress stores it, templates mask it, account logic compares it, and then the value gets pushed into a CRM, ESP, checkout flow, SSO bridge, or export job. WordPress frames the risk as plugin code and third-party services. In business terms, CRM hand-offs are an obvious part of that surface, even if the original fault starts in a small helper function that still assumes ASCII.

Where the first failures usually show up

The first place to look is storage. WordPress is clear that database support matters. If the site cannot store and retrieve full UTF-8 safely, valid addresses can be rejected or corrupted. The proposal says that needs to be communicated clearly because otherwise site owners and end users will just see confusing signup failures. The June 10 testing call narrows intended support to sites using utf8mb4, which is a sensible guardrail, but somebody still needs to verify the actual environment instead of assuming it is fine.

The second problem is disagreement between systems. WordPress is aligning validation with browser behavior so Core and an email input field agree. That sounds minor, but it changes behavior if your site still has custom validators, home-grown sanitizers, or third-party code enforcing older ASCII-only rules. A registration form can accept an address that legacy business logic rejects later. A sync job can refuse data that WordPress has already stored. The cost is usually not in changing Core. It is in finding every point where those rules no longer match.

The third problem is identity logic. The proposal warns that equivalent-looking strings can be treated as different if code paths do not agree on normalization. It also raises the issue of visually confusable characters. That matters anywhere a business deduplicates leads, merges user records, checks suppression lists, or compares one stored address to another. You do not need a security incident to create a mess here. Inconsistent comparison rules are enough.

What a serious audit looks like before 7.1

Map every intake point that can create or update an email address. The June 2026 developer roundup makes this relevant anywhere code validates, stores, masks, or compares emails.
Verify storage capability before broader acceptance reaches live forms. The proposal is clear that full UTF-8 storage is a prerequisite for handling these addresses safely.
Review custom validation and sanitization around Core functions. The testing note confirms that is_email() and sanitize_email() change behavior under the right database conditions.
Replace byte-oriented helpers and home-grown parsing. WordPress is adding WP_Email_Address precisely so extension code can stop inferring structure from raw strings.
Check comparison, masking, and deduplication rules. Normalization and confusable characters can create bad matches, missed matches, or duplicate records.
Inspect every downstream hand-off. The June 10 testing call explicitly tells teams to check third-party integrations and notes that Unicode email support can be disabled temporarily if those integrations are not ready.

The practical business decision

The sensible response is neither panic nor denial. WordPress itself presents the broader Unicode work as worthwhile, and the June testing guidance is careful about preserving fallback behavior where older systems still need ASCII-only input. It also notes an important limit: WordPress' own sender address and return-from address still need to remain US-ASCII compatible. This is a targeted change for WordPress user accounts, not a blanket rule saying every mail-related field in every system can suddenly become Unicode overnight.

But the timing matters. On June 10, 2026, WordPress stopped treating Unicode email handling as a distant idea and started asking plugin and theme teams to test real 7.1 behavior. That makes this the cheaper window to audit assumptions on purpose. The expensive window is later, when registrations fail, integrations disagree, or production data needs to be cleaned up after the new rules have already met live traffic.

This is the kind of work Greg can make manageable. The useful service is not a vague standards lecture. It is a focused review of where a WordPress stack validates, stores, masks, compares, and syncs email addresses, followed by practical fixes in custom code and fragile integrations before live signups, CRM hand-offs, or export jobs turn into a data integrity problem.