The same person, three rows, three different strings
Your list is bigger than the number of people on it, and somebody has noticed a customer getting the same campaign twice. You've already run an exact string match, and it evidently missed something.
It's also a billing question. A mailbox represented three times is three charges at most vendors, three sends, and three chances to annoy one person.
The order the work happens in
Lowercase and trim the whole column
Domains are case-insensitive by specification, so two rows that differ only in capitals are one address. That alone resolves a surprising share of a merged file.
Normalize the Gmail and Googlemail forms
Google ignores dots in the local part and everything after a plus sign, and googlemail.com is the same mailbox as gmail.com. Four apparent addresses collapse into one.
Handle plus addressing carefully elsewhere
Most providers support it, but not all, and a few treat a plus as an ordinary character. Normalize it for the big providers and leave the rest alone rather than guessing.
Look for alias domains at the same company
Plenty of businesses route an old domain and a new one into the same mailbox. An MX record pointing at the same host is the clue.
Merge the history onto one surviving record
Keep the oldest consent date and the most recent engagement. Delete the wrong row and you lose the evidence that you were allowed to mail this person.
What each result means here
The same four results and their flags, read against this job. A catch-all worth keeping in one situation is one to exclude in another.
| Result | What to do with it |
|---|---|
| Valid | Keep one row. The verdict does not decide which one survives, your history does. |
| Invalid | Check the other forms of the same address before removing. One variant failing can mean a typo in that row alone. |
| Catch-all | No help with duplicates. A domain accepting everything accepts every variant equally. |
| Unknown | No help either. Deduplicate on the normalized string rather than on the verdict. |
| Role flag | Role addresses genuinely are shared mailboxes, which is a different kind of duplicate and usually one to keep. |
| Disposable flag | Remove all variants together. |
How you know it is finished
A normalized match across the whole file returns no collisions, and every surviving record carries the oldest consent date and the most recent activity from the rows it absorbed.
What this does not fix
Duplicates are never billed here, so an unnormalised file costs you nothing extra in credits. It still costs you the reconciliation afterwards, which is why the normalizing step is worth running first anyway.
Questions people ask
Does jane.smith@gmail.com differ from janesmith@gmail.com?
Not at Google. Dots in the local part are ignored, so they both reach the same mailbox. Treating them as separate people is one of the most common sources of duplicate sends.
Should I normalize plus addressing for every provider?
For the major ones, yes. A few providers treat a plus as an ordinary character, so a blanket rule can merge two genuinely different mailboxes. Handle the big providers explicitly and leave the long tail alone.
Which duplicate record should survive?
The one whose history you need: your oldest consent record, carrying the most recent engagement data merged onto it. The address string is the least important part of that decision.
Try it on the file in front of you
100 free checks a month, no card. Addresses we could not get an answer on come back labeled as unknown, and those are not billed.