No, WordPress still doesn’t store Unicode email addresses on user accounts, and the core code that briefly allowed it was reverted before release. The PHPMailer updates in WordPress 6.9 already let a site send mail to those addresses, so WordPress can deliver to an address it refuses to save. If you build plugins or run a store with international customers, that gap lands on you.
The proposal itself is worth a read. Make WordPress Core published a request for comment in May on Unicode in email addresses, usernames and slugs, eleven years after ticket 31992 first raised it. It came with a new WP_Email_Address class, replacement helpers for is_email() and sanitize_email(), and a deliberate restriction to utf8mb4 databases. Then the comment thread changed the outcome. Matt Mullenweg argued the surface area and the security implications meant it belonged in a community plugin, and the changes were backed out in changeset 62829. So this is plugin territory now, while the rest of the email world moves toward RFC 6530.
Why Unicode email addresses got pulled back out
I think the revert is defensible, and the reason is an old assumption: for the entire life of the plugin directory, code could treat an email address as single-byte US-ASCII. Every strlen() call, the byte-by-byte hex escaping in antispambot(), and every hand-rolled validation regex was written that way, and core can’t audit all of it before flipping a default. Add confusable characters, two spellings that normalize to the same address, invisible characters, and tables that can’t hold four-byte characters without corruption, and you get compatibility breakage that would surface slowly across the plugin ecosystem. The one design choice I’d keep from the proposal is the utf8mb4 gate, because it’s cheap to check and it turns silent corruption into a no-op.
Where your own code breaks first
The first place I’d look is sanitize_email(). It strips every character not on its allowlist, so a valid UTF-8 local part comes back gutted or empty, and your error message then tells someone their real address is invalid. strlen() is next, because it counts bytes, which means length checks on multibyte addresses go wrong in both directions. And if you push customer emails into an ESP or CRM through their API, that integration is where a UTF-8 address shows up even though core won’t store it. The sending side did change in 6.9, and the email reliability fixes are worth revisiting if you missed them.
The fix that holds up
The tempting fix is a filter on is_email that returns the string untouched. It doesn’t hold, because sanitize_email() still runs afterward and strips the characters you just validated, and because the database may mangle whatever survives. If one of your integrations needs Unicode email addresses, normalize before comparing and count characters instead of bytes:
function bbioon_normalize_email( $email ) {
$email = trim( $email );
if ( function_exists( 'normalizer_normalize' ) ) {
$n = normalizer_normalize( $email, Normalizer::NFC );
if ( is_string( $n ) ) {
$email = $n;
}
}
return $email;
}
// bytes vs characters: strlen() lies on UTF-8
$chars = mb_strlen( bbioon_normalize_email( $address ), 'UTF-8' );I’m not sure normalizer_normalize is available everywhere, since it needs the intl extension, which is why the check is there. Treat it as best-effort normalization, and keep ASCII validation anywhere an address ends up in a mail header you don’t control.
What to check today
Two checks are worth ten minutes. Open Site Health, Info, Database, and confirm the character set is utf8mb4, or run wp db query 'SHOW VARIABLES LIKE "character_set_database";' from WP-CLI. Then grep your own code for byte-level assumptions: grep -rn 'strlen(' . on any path that touches an email. If you’d rather hand this kind of audit off, for a store or a plugin that handles customer emails, it’s the sort of work I take on.
