WordPress Unicode Email Addresses Land in 7.1 Trunk

I have spent more years than I want to count writing user registration code, password reset flows, customer email logs for WooCommerce, and the occasional “why is this address bouncing” investigation for an international client. Email validation in WordPress is one of those things you stop noticing until it bites you. The rule, quietly, has always been: ASCII only, otherwise is_email() says no and the rest of the stack agrees.

That rule is finally moving. Not in a marketing post, not in a roadmap slide, but in core trunk, behind a real changeset, with a real new class and a real call for testing. If you run a multilingual store, a membership site for users whose names do not fit in A through Z, or any plugin that touches user data, this is the kind of plumbing change you want to read carefully before WordPress 7.1 ships.

The framing matters too. WordPress is twenty-three years old this year, and the boring, slow-burn upgrades — slugs, redirects, revisions, governance, and now Unicode in the email field — are exactly why it still runs the open web. This is one of those upgrades.

What is actually new

On June 10, 2026, Dennis Snell announced on Make WordPress Core that initial Unicode email address support has been merged into trunk in changeset [62482], against the long-running ticket #31992. The post is titled “Call for Testing: Unicode email addresses.” and it is exactly that — a request to hammer the new behaviour before WordPress 7.1.

Three concrete changes ship together:

• is_email() and sanitize_email() now accept non-ASCII addresses such as grå@grå.org, aligning their behaviour with the WHATWG email specification.
• A new class, WP_Email_Address, gives a structural view into an email address — local part, domain part, Punycode decoding — so plugin code can stop guessing with regular expressions. The factory WP_Email_Address::from_string() returns an object with get_ascii_address() and get_unicode_address() helpers.
• Two new filters, wp_is_unicode_email and wp_sanitize_unicode_email, let a site opt out of Unicode acceptance by short-circuiting the new logic if a host needs the old ASCII-only behaviour.

One hard prerequisite: Unicode email support requires the site database charset to be utf8mb4. That has been the WordPress default for years, but inherited installs from the early 2010s may still be sitting on utf8 or worse. If your database is not on utf8mb4, the new code stays out of the way.

This is not coming out of nowhere. In May, agulbra posted the original proposal on Make Core, citing RFC 6530 as the standardization umbrella and noting that the major providers have treated UTF-8 addresses as a de facto norm for years. The June merge is the narrower, conservative slice of that proposal: email addresses for user accounts, not usernames, not slugs, not antispambot(). Those remain on the table for later. The June 2026 developer newsletter also flagged the broader RFC as “in feedback phase” — so plan around what is actually merged, not the full wishlist.

Why it matters for WordPress and WooCommerce people

If you only build English-language brochure sites for English-speaking clients, you can keep scrolling and not think about this for a year. For everyone else — and that is most of us in serious WordPress and WooCommerce work — the email field is the spine of the user record, the order record, the subscription, the invoice, the password reset, and every transactional notification. Anywhere your codebase calls is_email() as a gate, that gate is about to let more traffic through.

The places this lands hardest:

• Custom registration flows. If you wrote a custom signup form and reused is_email() for validation, you will start accepting addresses you previously rejected. That is the design intent. Make sure your downstream consumers — your CRM, your ESP, your billing provider — actually accept them too. Many do not.
• WooCommerce checkout and customer records. The billing email is the customer identity in Woo. Once core accepts müşteri@şirket.tr, the question becomes whether Stripe, PayPal, your tax engine, and your invoice PDF library survive it. Test the full pipeline, not just the form post.
• Logging and search. Anywhere you log “the email” as plain text to a file or a third-party service, you are about to start writing non-ASCII to that destination. Confirm your log shipper, your error tracker, and your support inbox tools render Unicode correctly. This is where I have personally been bitten before.
• Plugin authors. Stop parsing emails with a regex. WP_Email_Address::from_string() is now the safe primitive. The get_ascii_address() helper is your escape hatch for legacy systems that genuinely cannot handle Unicode in the SMTP envelope.

And a note for hosting and DevOps: SMTP itself is the layer where Unicode email gets interesting. Sending email to a Unicode local part requires SMTPUTF8 support end-to-end. Many transactional providers have it, several do not, and some require it to be explicitly enabled per domain. Accepting an address into your database is one decision. Successfully delivering a password reset to it is another decision entirely.

What I would do (or not do) about it

What I would do this month, in this order:

• Pull trunk into a Playground or staging environment and run a Unicode address (grå@grå.org is the canonical test case from the announcement) through every signup, checkout, password reset, and admin user-create path your stack exposes. Note where it works, where it breaks, and where it silently mangles.
• Audit every plugin you ship for raw email regex validation. Replace it with WP_Email_Address in the codepaths that will run on WordPress 7.1+, and keep a fallback for older versions. Do not rip out the old code yet.
• Talk to your ESP and payment provider. If you cannot deliver to a Unicode address, accepting one is just a slow-burning support ticket. Get a written answer.
• If you operate a site that genuinely must stay ASCII-only — a regulated B2B portal, a legacy ERP integration, a specific compliance requirement — write your opt-out now using the wp_is_unicode_email and wp_sanitize_unicode_email filters. Do it before 7.1 lands, not after a user files a bug.
• File a testing report. The whole point of a public call for testing is that core gets real signal before the release branch closes. The proposal explicitly says this is being refined for 7.1.

What I would not do: rewrite anything in production today on the assumption this lands unchanged. It is in trunk, not in a release. Trunk changes. Build the audit, build the staging tests, write the opt-out if you need one, and wait for the 7.1 release candidate before you push real code.

WordPress getting Unicode in the email field eleven years after the ticket was filed is not a flashy story, and that is the point. The quiet, careful upgrades are what keep the platform credible across languages and across decades. We will be testing this on client builds in the coming weeks, and I would encourage you to do the same before 7.1 makes the decision for you.