A developer investigation revealed that one user had successfully registered four separate accounts using only legitimate Gmail address variants that all route to the same mailbox: Ivan.Petrov@gmail.com, ivanpetrov@gmail.com, ivan.petrov+shop@gmail.com, and IVAN.PETROV@gmail.com.
Colleagues noticed more user records than actual people in the database. The discrepancy traced back to a single line of code that compared email addresses as raw strings without normalization.
Gmail treats the local part of an address case-insensitively, discards everything after a plus sign, and ignores dots. These rules let one inbox generate an unlimited number of distinct strings that still receive mail at the same destination.
Why string comparison fails
Three common cases break naive equality checks:
- Case differences in the local part or domain
- Plus-addressing suffixes such as +shop or +promo
- Dots inserted anywhere in the local part of a Gmail address
Normalization must be applied selectively. Dots are ignored only for gmail.com and googlemail.com; applying the same rule to other providers would incorrectly merge unrelated mailboxes.
Homograph domain attacks
A separate but related threat appears when domains contain visually identical Cyrillic characters. The string еxample.ru (with Cyrillic е) encodes under IDNA to xn--xample-2of.ru, creating a look-alike address that passes superficial inspection yet points elsewhere.
Recommended implementation
Store two fields: the original address for sending mail and a normalized address for uniqueness enforcement. Perform lower-casing on the entire address, strip plus-suffixes only for Gmail, remove dots only for Gmail, and run every submitted domain through IDNA encoding to detect hidden non-ASCII labels. A simple confirmation email remains the most reliable validator of deliverability.
A diagnostic query can surface existing problems by grouping on the normalized domain and comparing raw versus deduplicated local parts.


