Dots in Gmail addresses: safe deduplication boundaries
Google states that dots do not update the destination for consumer Gmail addresses. That is a provider-specific behaviour, not a universal rule for email. Applying it to every domain can merge different recipients and damage a contact database.
Open the relevant free tool →Gmail’s dot rule has a defined scope
Use the exact provider boundary
For an ordinary @gmail.com address, dotted variants can reach the same account. Google details that work, school and other organization addresses can differ. A custom domain using Google mail infrastructure should not automatically be normalised as if it were gmail.com. Check the actual address domain, not the app a person uses to read their mail.
Preserve the original destination
Even when variants are equivalent at the provider, keep the spelling the user supplied in the source record. If you want a duplicate-analysis identifier, store it separately. This makes the transformation auditable and lets you explain why two rows were grouped without losing their original entries.
Separate exact duplicates from possible aliases
An exact-duplicate remover should make a narrow promise. A more aggressive provider-aware cleanup pass should show its rules and preview the affected rows before merging. Include the source, consent state and most recent interaction in that review. Two records reaching one mailbox can still represent different subscriptions or contexts in your application.
Do not use normalization as ownership proof
Recognizing two variants does not establish who controls them. A user should still complete the application’s confirmation flow for ownership-sensitive actions. Avoid showing another account’s existence or private details when a normalised address collides with an existing record. Resolve collisions through a deliberate account policy rather than a surprising form error.
Test the cleanup output
Before applying a rule to a large CSV, run a small sample and compare input and output row counts. Keep a report of which rows were grouped and why. Verify that non-Gmail domains remain unchanged. Preserve suppression information so a cosmetic address variation does not reactivate a contact who previously opted out through your system.
Worked example
For provider-aware analysis, keep columns like original_email, comparison_key and normalization_rule. Do not replace the original_email column with the comparison identifier.