What is email normalization?

Two operations are always safe: trim surrounding whitespace, and lowercase the domain. Domains are case-insensitive by specification, and the whitespace is a paste artifact.

Beyond that it gets provider-specific. Gmail ignores dots and plus tags. Outlook.com honors plus tags but treats dots as part of the name. Yahoo uses a hyphen for tagging instead of a plus.

Keep both forms in your database. The canonical key is for matching and deduplication; the original string is what you actually send to.

Over-normalising has a real failure mode. Strip dots at a company using first.last@ and you merge two colleagues into one contact, which is worse than the duplicate you were trying to remove.

Say a form submission arrives as John.Smith+Promo@GoogleMail.com with a space on each end. Here's how a matching key gets built from it, one step at a time.

You trim the whitespace, then lowercase the domain to get googlemail.com. Next you map that domain to gmail.com, since Google treats the two as the same mailbox system. Because the domain is now known to be Gmail, apply Gmail's rules: drop everything from the plus sign to the @, lowercase the local part, and remove the dots. The key is johnsmith@gmail.com.

Now run j.smith@acme.example through the same function. You trim, lowercase the domain, and stop there, because you don't know how Acme's mail server treats dots or plus signs, so the local part stays as typed. A function like this is a short table of per-provider rules, and any domain that isn't in the table gets only the two safe steps.

Deduplication is the obvious use for your key, and suppression is the one that matters more. Say John unsubscribes as john.smith@gmail.com, and six months later a partner list brings him back as johnsmith@gmail.com. A suppression check on raw strings lets him through, and you've now mailed someone who opted out. Comparing keys on both sides catches it.

Trial abuse is the other place you'll want it. One person can generate thousands of Gmail variants that all land in one inbox. Counting signups per key, instead of per raw string, shows that pattern immediately.

Text encoding adds a quieter problem. The same accented character can be stored as one code point or as a letter plus a combining mark, and the two forms look identical while comparing as different. Normalize text to a single Unicode form (NFC is the usual choice) before you build the key, and convert internationalized domains to their xn-- form so that both spellings of one domain produce the same result.