How to Validate Email Addresses and Clean a Mailing List

Every list of email addresses you inherit is a little bit broken. Someone typed john@@gmail.com into a signup form. A CSV export split one cell into two on a stray comma. A lead vendor handed you jane@gmail with no top-level domain. Before any of that touches a CRM, an outreach tool, or an import script, it pays to run the list through a syntax check and see exactly what fails and why.

That is what the Email Address List Validator does. You paste text — an export, a copied signup column, a support ticket, a Markdown note — or upload a local text file, and it checks each address one row at a time against the rules for email addresses. The whole thing runs in your browser. Nothing is sent to a server, which matters when the list is customer data you don't have the right to upload anywhere.

What "valid" actually means here

The validator checks the shape of an address, not whether it can receive mail. An email address has a known structure: a local part, a single @, and a domain that contains at least one dot so it resolves to a real top-level domain. The tool walks each row and flags anything that breaks those rules, with a short reason attached to the failing row.

Concretely, it catches the common failure classes:

• Wrong number of @ signs. john@@gmail.com has two, so it fails. An address with none fails too.
• A domain with no TLD. bob@localhost and jane@gmail have no dot in the domain, so there is nothing that resolves to a top-level domain. Both get flagged.
• A local part that is too long. The part before the @ is capped at 64 characters; anything longer is rejected with that reason.
• A row a comma broke in half. When a CSV export splits one cell into two, the fragments no longer parse as a single address, and the validator says so.

These are real, mechanical defects. A row that trips any of them was never going to work, and the tool keeps the failing rows visible — with their reasons — right next to the valid ones, so you can go back and fix the source instead of guessing what broke.

Why syntax-valid is not the same as deliverable

Here is the part people skip. A syntactically perfect address can still bounce. nobody@google.com passes every syntax rule — one @, a legal local part, a domain with a dot — and it may well be a mailbox that doesn't exist. Syntax validation tells you the address has the right shape. It does not, and cannot, tell you that the mailbox is real, the domain accepts mail, or the person still works there.

Proving an address is deliverable needs things this tool deliberately does not do: an MX-record lookup on the domain, an SMTP handshake with the receiving server, or a confirmation email. Those steps touch the network and reach outside your browser. This validator is a first-pass filter. It strips out the garbage that would bounce for obvious structural reasons, so your real send — or your paid verification service — isn't wasting attempts on john@@gmail.com. Treat a clean result as "the shape is correct," never as "this person will receive my email."

A worked example

Say a teammate hands you this pasted column:

alice@example.com
john@@gmail.com
JANE@Example.com
jane@gmail
bob@localhost
alice@example.com
mallory@sub.example.co.uk

Run it through the validator and the per-row report reads like this:

| Input | Valid | Reason | |---|---|---| | alice@example.com | yes | OK | | john@@gmail.com | no | more than one @ | | JANE@Example.com | yes | OK | | jane@gmail | no | domain has no dot / missing TLD | | bob@localhost | no | missing TLD | | alice@example.com | duplicate | already seen above | | mallory@sub.example.co.uk | yes | OK |

Four rows survive the syntax check, three are flagged, and one is a duplicate. From there you can keep unique rows only, sort the normalized output, and switch the export between CSV, JSON, Markdown, SQL IN, a TypeScript union, or plain lines — whichever artifact the next step needs. The flagged rows stay in view so you, or whoever owns the source data, can correct them rather than silently dropping them.

Cleaning a mailing list in practice

The first time I did this on a vendor lead list, I expected a handful of bad rows. The export had about 4,000 addresses; roughly 200 failed syntax outright — double @ signs from a form bug, a cluster of rows where a comma in someone's company name had shifted the email into the wrong column, and a long tail of @gmail and @yahoo with no .com. None of those would have delivered. Catching them before the import meant the CRM didn't choke on malformed rows, and my later deliverability check ran against a list that was already structurally sound. The reasons column was the useful part: I could hand the source owner an exact list of what to fix instead of a vague "your file has problems."

A practical order of operations:

1. Paste or upload the raw list. Copied web text often carries hidden whitespace, so a separate normalize pass helps before you dedupe.
2. Read the reasons. Don't just count the failures — the reason tells you whether it's a typo (@@), a missing TLD, an over-long local part, or a split cell. Each implies a different fix.
3. Keep unique rows and sort, so the output is stable and diff-friendly.
4. Export the right format. Keep an audit trail by downloading CSV or Markdown with line numbers rather than copying only the final list — that way you can trace any address back to its source row.

If your job is narrower, the focused tools split the work apart. Pull addresses out of messy text with the Email Address Extractor, standardize casing and whitespace with the Email Address Normalizer, collapse repeats with the Email Address Deduplicator, or reshape a clean list into another format with the Email Address List Converter. When you're chasing domains rather than full addresses, the Domain Name Extractor does that one job. And if the upstream file is the problem, the Text File Cleaner handles the whitespace and stray-character cleanup before any of the above.

The takeaway

Syntax validation is the cheap, fast, offline first pass: it confirms each address has one @, a legal local part, and a domain with a dot, and it names the typos that don't. It will not tell you the mailbox exists — that's a separate, network-bound check you run after the list is structurally clean. Used in that order, you stop wasting deliverability attempts on rows that were never valid in the first place, and you hand back a list with every failure explained.

---

Made by Toolora · Updated 2026-06-13