Cleaning a mailing list in the browser: syntax, aliases, role inboxes and near-miss domains
A list of email addresses collected over a few years is never tidy. It carries display names, capital letters, the same person written three ways, inboxes that belong to a department rather than a human, throwaway domains from a competition entry, and a handful of addresses one keystroke away from working. This article explains what the cleaner can decide from the text of an address alone, what it deliberately refuses to guess, and how each control on the page changes the outcome.
Where a dirty list comes from
Nobody sets out to build a messy list. It happens because addresses arrive from different places and none of them agree on a format. A signup form gives you a bare address. An exported contacts file gives you Jane Cooper <jane@example.com>. A spreadsheet somebody kept by hand gives you a column with a name in one cell and an address in the next, sometimes with a stray space at the end. A pasted To: field gives you a dozen addresses separated by semicolons.
Then time passes. The same person signs up again with a different capitalisation. Somebody adds a plus tag so they can filter your mail, and their old address is still on the list too. A competition brings in a rush of entries from services that hand out an inbox for ten minutes. A trade show badge scanner turns handwriting into gmial.com.
The cost of leaving all that in place is not just wasted effort. Mailing platforms watch how many of your messages bounce, and a list with a few per cent of dead addresses can get an account throttled or suspended. Sending three copies to one person because you have three spellings of their mailbox is a good way to have them mark you as spam. Cleaning up front is cheaper than repairing a sending reputation afterwards.
What a page in your browser can honestly tell you
This is the point where most email checkers overstate what they do, so it is worth being blunt. Confirming that a mailbox exists means opening a conversation with the receiving mail server: looking up the domain's mail exchanger records, connecting to that server, and starting an SMTP exchange to see whether it accepts the recipient. A web page cannot do any of that. The browser has no way to make those connections, and any site that offers the service is sending your list to a machine of its own that can.
So this tool decides everything from the text of the address and nothing else. That is a smaller job than full verification, but it is not a small job, and it catches most of what is actually wrong with a real list. It can prove an address cannot work: the syntax breaks a rule, the domain is a single word with nothing to look up, the ending is a string of digits. It can prove two entries reach the same inbox. It can recognise a domain from a list of throwaway services, or notice that a domain sits one keystroke away from a very large provider.
What it will never tell you is that a well-formed address is live. sarah.jones@somewhere.com passes every test on the page and may have been closed three years ago. The way to learn that is to send to the cleaned list in a small first batch and watch what comes back.
Getting the list in
Paste into the box marked Addresses in, press Open a file to load a text or CSV file from your device, or drag a file straight onto the box. Nothing is uploaded in any of those cases; the file is read by the browser and the text stays in the page.
The dropdown labelled Reading the list decides how the text is cut up. The default, one address per line or comma separated, splits on line breaks, commas, semicolons and tabs, and it is careful about where it splits. A comma inside quotation marks or inside angle brackets is left alone, so "Wilson, Dan" <dan@example.com> stays in one piece instead of becoming two broken fragments.
The second setting, find every address inside pasted text, ignores structure completely and pulls out anything shaped like an address. Use it for a spreadsheet row where the address sits between a name and a city, for an email header dump, or for a page of prose with addresses buried in it. There is one difference worth knowing: this mode strips punctuation from the end of what it finds, because an address at the end of a sentence usually has a full stop after it that is not part of the address. That means a genuine trailing full stop, which is a real problem worth catching, is invisible in this mode and visible in the other one.
Either way, a display name is peeled off before anything is checked. Jane Cooper <jane@example.com>, "Cooper, Jane" <jane@example.com>, jane@example.com (Jane) and mailto:jane@example.com all reduce to the same address, and the name is kept to one side so it can go back into a CSV export later.
The syntax rules, checked one at a time
It is tempting to test an address with a single regular expression, and almost every one you find on the internet is wrong in one direction or the other. The loose ones accept x@@y.com and a@b. The strict ones reject perfectly legal addresses because somebody assumed nobody uses an underscore, a plus sign, or an ending longer than three letters. Neither kind can tell you what was wrong.
So the check here is written out as a sequence of rules, and the rule that fails is the message you see. Before the @ there must be something, no more than 64 characters of it. It cannot start or end with a full stop, cannot contain two full stops in a row, and cannot contain a space unless the whole thing is wrapped in quotation marks, which is legal and rare. Only the characters email actually permits are allowed, so an ampersand is fine and a comma is not.
There must be exactly one @ outside of any quotation marks. Two is the single most common paste error, and it is reported as such rather than as a vague failure.
After the @, every part between the dots must be one to 63 characters, made of letters, digits and hyphens, and must not start or end with a hyphen. The last part cannot be all digits and cannot be a single character. Non-English characters in the domain are rejected with a note that the xn-- form is what a mail system expects. The whole address must be under 255 characters.
Anything odd but legal survives. A quoted name, a plus tag, underscores, a long modern ending like .photography, a punycode domain: all kept.
Legal, but unable to receive post
Some addresses break no rule and are still useless in a mailing list, which is why they get a bucket of their own rather than being lumped in with the invalid ones.
The clearest case is a single word after the @. root@localhost is a valid address on the machine it was typed on, and it means nothing to the internet, because there is no domain name to look up a mail exchanger for. The same goes for the address that arrives as alex@company when somebody's autocomplete swallowed the rest.
The second case is a trailing full stop. jane@example.com. is technically a fully qualified name anchored at the root of the domain system, and while a mail server may well accept it, signup forms and list platforms routinely refuse it. It is flagged so you can decide.
The third is an address in square brackets, like user@[192.168.0.1]. That form is in the standard and is used inside private networks, but no mail exchanger can be looked up for it and it has no business in a marketing list.
Because these are separated from broken syntax, you can remove them and keep the invalid ones, or the other way round, depending on whether you are cleaning for sending or trying to repair the data.
Two spellings, one inbox
The most interesting duplicates are the ones that do not look like duplicates. Gmail ignores full stops in the part before the @, so p.nair@gmail.com, pn.air@gmail.com and pnair@gmail.com are one mailbox. It treats anything after a plus sign as a tag you can filter on, so pnair+shopping@gmail.com is the same inbox again. And googlemail.com, still used across parts of Europe, delivers to exactly the same accounts as gmail.com.
Put all that together and one person can appear on your list four times with four different strings, and a plain duplicate check will find nothing. Send to all four and they receive four copies of the same newsletter, which is the fastest route to a spam complaint.
The dropdown Count as the same mailbox controls how far the folding goes. The default applies Gmail's rules to Gmail and googlemail addresses only, which is the accurate choice, because those rules belong to Google rather than to email in general. The second setting extends plus tags to every domain: Outlook and Fastmail do treat them as tags, but plenty of company mail systems treat the plus as an ordinary character and the tagged address as a different person. The third setting turns folding off entirely and compares addresses exactly.
The two duplicate buckets are kept apart for a reason. Exact duplicate means the same address appeared earlier, ignoring capitals. Same mailbox, different spelling means the folding rules matched something already on the list. The first is always safe to drop. The second is a judgement call, and the flagged list names the earlier address it collided with so you can check.
Role inboxes
info@, support@, sales@, accounts@, no-reply@, postmaster@: addresses that belong to a job rather than a person. The tool recognises around a hundred of them, including the ones every domain is supposed to run under the internet standards, and it also matches a first segment, so sales.uk@ and support-eu@ are caught as well.
Whether to remove them depends entirely on what you are sending. For a business-to-business announcement, info@ may be exactly the right address. For a personal newsletter, it is usually not: the mail is read by whoever is on shift, forwarded around, and is the address most likely to have somebody press the spam button on behalf of a whole company. Some mailing platforms charge you for them and some list-cleaning services strip them silently.
Because that decision is yours, the role bucket is counted but not ticked for removal when the page opens. You can see how many you have before deciding anything.
Throwaway domains and near-miss spellings
The disposable bucket matches around 150 known temporary-mail services, and it matches their subdomains too, because several of them hand out an unlimited supply of those. Somebody who typed one of these into your form has told you plainly what they thought of the offer. Since the list is built into the page and nothing is downloaded, it cannot know about a service that launched last week, so a clear result is encouraging rather than conclusive.
The typo bucket works differently. Each domain is measured against a list of large consumer providers, counting single-character insertions, deletions, replacements and swapped neighbours. That last one matters: swapping two letters is how gmial.com and gamil.com happen, and a measure that does not count a swap as one mistake misses both. The ending is treated separately from the name, so hotmail.co.uk is compared as hotmail plus co.uk rather than as hotmail.co plus uk, and a short list of fat-fingered endings such as .con, .cm and .co is only ever consulted once the name in front already looks like a big provider. That keeps .co a perfectly good ending for everybody else.
Domains already on the provider list are never accused of being typos, and neither are known disposable ones. Even so, a small company domain that happens to sit one letter away from a giant can be offered a correction it does not want, which is why this bucket is also unticked to begin with and why the suggestion is shown whether or not the address is removed.
The tick box Correct likely typos instead of flagging them changes the behaviour rather than the reporting. With it on, the domain is repaired in place and the corrected address then goes through the duplicate check like any other, which often reveals that the person was already on your list with their address spelled properly. The removal tick for that bucket is switched off while correcting is on, because you cannot both repair and delete the same address.
Deciding what leaves, and what you get back
Each row of the bucket table shows a count and a tick box. An address can sit in more than one bucket at once, and it is removed if any of the buckets it belongs to is ticked. The four that are ticked when the page opens are the uncontroversial ones: broken syntax, unmailable domains, exact duplicates and alias duplicates, plus disposable domains.
The left-hand result box holds the clean list. The dropdown Write the clean list as decides its shape: lower case with the display name removed, which is what most import forms want; exactly as it was typed, which is right when the list is going back where it came from; or the folded mailbox form, which strips Gmail dots and plus tags so that what you store is the canonical inbox. Sort the clean list A to Z is there for eyeballing and for comparing two exports.
The right-hand box lists every address the tool has an opinion about, whether it was kept, corrected or removed, with the reason spelled out in plain English. That is deliberately more than a rejects file: a suggested spelling for gmial.com is no use if you have to delete the address to read it.
Download as switches both boxes between plain text, one address per line, and CSV with a column for each field. Full CSV exports every row that went in, with the address as typed, the address after cleaning, the display name, whether it was kept or removed, the reasons and any suggestion. Print report produces a page showing the date, the counts, what was removed and why, the kept addresses that carry a note, and the full clean list — the thing to sign and file when somebody has to approve culling a list. The date format on that report is selectable between day-first, month-first and the international form.
A worked example
Press Try an example and fifteen addresses appear, each one there to trigger something. Priya Nair <Priya.Nair@Gmail.com> loses its display name and its capitals. priyanair+newsletter@googlemail.com is flagged as the same mailbox as Priya, because the dots come out, the tag is cut and googlemail folds into gmail.
info@orchidlines.com and support@acme.co.uk are counted as role inboxes but kept, since that bucket starts unticked. tom.harris@gmial.com and jo@yaho.com are flagged with the spellings they probably wanted. sarah@mailinator.com and hello@10minutemail.com are throwaway domains, the second one also a role address, and both are removed.
lucy@localhost has no domain to look up. alex@company. ends nowhere. mark@example..com has two full stops in the middle of the domain. ravi kumar@bigfirm.com has a space where none is allowed. MARK@Example.com and mark@example.com are the same address written twice, so the second one goes.
The result is seven addresses kept and eight removed. Tick Correct likely typos and the count of kept addresses stays at seven, but two of them now read gmail.com and yahoo.com. Tick the role bucket as well and the count falls to four.
Limits worth remembering
The biggest one has already been said and is worth repeating: passing every check here does not mean an address works. Treat a clean list as a list with the obvious rubbish taken out, not as a verified one.
The typo suggestions are guesses. They are good guesses for consumer providers and they say nothing useful about a company domain nobody has ever heard of. Read them before applying them, especially if your audience is business rather than consumer.
The disposable list is a snapshot. It covers the well-known services and it will not know about one that started recently.
Alias folding for every domain is a setting rather than a default because it is wrong more often than it is right outside the big providers. If your list is mostly corporate addresses, leave it on the Gmail setting.
And the order of the list matters for duplicates. Whichever spelling appears first is the one kept, so if your export is sorted by signup date with the newest last, consider reversing it before cleaning if you would rather keep the most recent version of a record.
Where your list actually goes
Nowhere. The checks run inside the page, and the only copy that outlives the tab is the one the tool writes into this browser's own storage so that a reload does not throw away your work. Start over deletes that copy and puts the example back.
This matters more for a mailing list than for most kinds of data. A list of customer addresses is personal data under the UK and EU rules, and pasting it into an online validator is a transfer of that data to whoever runs the service, with everything that implies about contracts, retention and where the servers are. Because nothing here contacts a network, the awkward questions do not arise. If you want to satisfy yourself, disconnect from the internet after the page has loaded and clean a list anyway; every check still runs.
