How to Fix Invalid Email Addresses in a CSV Before You Send

The short answer: fix the shape first, then judge the address

An “invalid email” in a CSV is not one problem. It is at least five different problems wearing the same label: a typo in the syntax, a missing or extra character added during export, a domain that no longer exists, a mailbox that was closed, and an address that was never real in the first place. Treating them as one bucket — delete everything a checker flags — throws away recoverable leads and keeps some worthless ones. The reliable workflow is boring and sequential: fix the shape of the address first, remove the duplicates and junk you can prove are junk, sort what remains into clear categories, and only then decide what to send to, what to hold back, and what to delete. This guide walks through that sequence with a worked example, the exact checks to run in order, and the mistakes that turn a clean-up into a deliverability problem.

Step 1: Work on a copy and count everything

Save the original file untouched and work on a copy named with the date, for example leads-2026-10-18-working.csv. Record the starting row count. In the worked example used throughout this guide, a partner webinar export contains 4,820 rows. Every step below reports how many rows it changed or removed, so the final count can be reconciled: 4,820 in, a known number removed for known reasons, and no silent losses. If you cannot explain a change in the row count, stop — a filter is still on, a sort moved one column without the others, or an export truncated the file. Run the file through the free CSV Cleaner first to trim stray spaces, drop completely empty rows, and normalise the column layout before you judge any single address.

Step 2: Fix the mechanical errors you can prove

Mechanical errors have a correct answer you can verify from the row itself. Look for leading or trailing spaces (“ jane@acme.com ”), a trailing comma or full stop copied from a signature, doubled characters such as @@ or .com., spaces inside the address, and missing top-level domains where the company column and a web search confirm the obvious completion. In the example file, this pass fixes 117 addresses: 62 with stray spaces, 31 with a trailing punctuation mark, 14 with gmail.con or gmal.com style domain typos where the intended provider is unambiguous, and 10 where the address was split across two columns by a stray comma and can be rejoined exactly. Do not “fix” a name typo on a guess — jonh@ might be John, Jon or a different person entirely. Flag guesses; correct only certainties.

Step 3: Check the syntax properly

A syntactically valid address has exactly one @, a non-empty local part with no spaces, and a domain with at least one dot and a plausible ending. That sounds trivial, yet exports routinely contain addresses such as jane@acme, jane@@acme.com, @acme.com and jane@acme..com. A simple pattern check catches these without sending anything or querying any server. In the example, 48 rows fail syntax outright after the mechanical fixes. Move them to a separate “repair” tab instead of deleting them: 19 turn out to be recoverable from another column — the same person appears in a second list with the address written correctly — and the remaining 29, with no second source, are the first genuine deletions. Our guide to how to clean CSV files covers the general staged process this step sits inside.

Step 4: Separate role, disposable and risky addresses — do not delete them automatically

Role addresses such as info@, sales@, support@ and admin@ are valid mailboxes; they are simply shared. For a B2B list they are usually lower value than a named person, and some sending platforms restrict them, but deleting them by reflex removes the only contact you have for many small companies. Tag them as role and decide by campaign: in the example, 203 role addresses are kept for a general newsletter and excluded from a personalised outbound sequence. Disposable domains — temporary inboxes created for one signup — are different: they almost never read a second message, so exclude them from sending and count them separately (41 in the example). Catch-all domains, which accept mail to any local part, cannot be confirmed either way at the address level; hold them for a small, separate first send rather than mixing them into your main batch, where a cluster of bounces would be hard to read.

Step 5: Dedupe after fixing, never before

Order matters. If you deduplicate before fixing spaces, case and punctuation, Jane@Acme.com, jane@acme.com and jane@acme.com. look like three different people. Lower-case the whole address column, trim every cell, apply the mechanical fixes, and only then deduplicate on the cleaned address. In the example this removes 156 duplicates that a first-pass dedupe had missed 61 of. Use the Duplicate Remover or your spreadsheet’s remove-duplicates on the single cleaned column, and keep a removal list — the duplicate row sometimes holds the better phone number or job title, so merge the richest fields before discarding the extra row.

Step 6: Read bounces like a report, not a verdict

After a first careful send, hard bounces (mailbox does not exist, domain does not exist) should be removed permanently and never re-imported from an older list — re-adding suppressed addresses is a common reason teams bounce at the same rate every quarter. Soft bounces (mailbox full, server temporarily unavailable, message too large) deserve two or three attempts across different days before you give up. Keep a suppression list as its own file with three columns — address, reason, date — and check every future import against it before sending. In the example campaign the first send to the cleaned 4,200-address list produced a 1.1% hard-bounce rate, compared with 6.8% on the previous uncleaned send to a similar list; the difference was not a magic checker, it was the staged work above.

Common mistakes

• Deleting everything a free checker flags. Cheap checks mostly test syntax and domain records; they cannot know whether a mailbox exists, and they flag catch-all domains as unknown, not invalid.
• Guessing corrections. Changing mike@acme-corp.com to acme.com because it “looks right” invents data. Flag it, verify it from a second source, or leave it out.
• Cleaning once and never again. People change jobs and mailboxes close continuously; a list that was clean in January is measurably stale by October. Re-run the mechanical and syntax passes on every import.
• Losing the audit trail. If you cannot say how many rows each step removed and why, you cannot tell a cleaning success from a truncated export.

A 15-minute checklist you can reuse

1. Copy the file; record the starting row count.
2. Trim spaces, drop empty rows, normalise case in the email column.
3. Fix only provable mechanical errors; log how many.
4. Run a syntax pass; move failures to a repair tab and recover what a second source confirms.
5. Tag role and disposable addresses; decide per campaign instead of deleting by default.
6. Deduplicate on the cleaned address; merge the richest duplicate fields first.
7. Check the import against your suppression list; export the final count and reconcile it against step 1.

Do that, in that order, and “invalid email” stops being a vague warning and becomes a small set of named, countable decisions — which is all good data cleaning ever is. For the wider hygiene picture, including how often to repeat this, see our email list hygiene and deliverability checklist.