How to Clean an Email List: A Step-by-Step Process in Order

To clean an email list, keep the original, then in this order: normalise and deduplicate, apply suppression lists, check syntax, check each domain can receive mail, flag disposable and role addresses, verify mailboxes, separate inactive contacts, decide on risky addresses, and process bounces after every send. Free, certain steps come first; paid and judgement steps come last.

The order matters more than most guides admit. Done in the wrong order you pay to verify people you are not allowed to email, delete good contacts on a guess, or clean once and let the list decay again.

The process at a glance

#	Step	Removes	Cost	Certainty
1	Keep the original	Nothing	Free	n/a
2	Normalise and deduplicate	Copies of the same address	Free	Certain
3	Apply suppression lists	Unsubscribes, complaints, past hard bounces	Free	Certain, and required
4	Syntax check	Malformed addresses	Free	Certain
5	Domain and MX check	Domains that cannot receive mail	Free to cheap	Certain
6	Disposable and role flags	Throwaway inboxes; shared inboxes flagged	Cheap	High
7	Mailbox verification	Mailboxes that do not exist	Paid	High, except catch-all
8	Engagement split	Nothing yet; separates inactive contacts	Free	Judgement
9	Decide on risky addresses	Depends on the decision	Free	Judgement
10	Process bounces after every send	What verification could not see	Free	Certain

1. Keep the original

Save an untouched copy before changing anything, and do all cleaning in a copy. Every later step deletes or rewrites rows. When someone asks why a customer stopped getting emails, the original file and a record of which step removed them is the answer.

2. Normalise and deduplicate

Make every address lower case with no surrounding whitespace, then remove duplicates on that cleaned value. This is free, and it shrinks the list before anything costs money.

Two details catch people out. Spreadsheet trim functions do not remove the non-breaking space that arrives with web-copied addresses: Microsoft's TRIM documentation and Google's Data cleanup page both say so. And lower-casing is safe in practice: RFC 5321 technically permits case-sensitive mailbox names but says exploiting that "impedes interoperability and is discouraged".

Our guide to removing invalid and duplicate emails from a CSV gives tested spreadsheet formulas and a short Python script.

3. Apply suppression lists before anything else

Remove everyone who unsubscribed, complained or hard bounced in the past, regardless of whether their address is valid. This step is about permission, not deliverability, which is why it comes before verification.

Pull suppression lists from every tool that has sent to these people: your email platform, your CRM, your cold email tool. Then remove matches from the working file. A valid address that unsubscribed last year is the worst address on your list, because a complaint costs more than a bounce. Google's sender guidelines set a ceiling of 0.3% for spam complaints reported in Postmaster Tools, with 0.1% as the level to stay under.

4. Check syntax

Drop addresses that are not shaped like an email address. Missing @, two @s, spaces, a comma where a dot should be, a domain with no top-level part. None of these can ever be delivered.

Read the failures before deleting. Some are real addresses with junk attached, such as mailto: prefixes or Name <address> formats, and can be fixed. Do not guess at ambiguous ones: correcting hana o@ to hanao@ or hana.o@ creates an address you never had.

5. Check each domain can receive mail

Look up each domain once and drop addresses at domains that cannot receive email. This is cheap because it runs per domain, not per address, and it is certain.

There are four outcomes. We checked one example of each with dig on 1 October 2026:

Domain	What DNS returned	Meaning
gmail.com	MX records (gmail-smtp-in.l.google.com and others)	Receives mail
example.com	0 .	Null MX: explicitly accepts no mail
nonexistent-domain-zz91x.com	NXDOMAIN	Domain does not exist
neverssl.com	No MX, but an A record	Mail falls back to the A record

The last two rows are where home-made checks go wrong. A "null MX" is defined in RFC 7505 as a single MX with preference 0 and exchange ., meaning the domain accepts no mail; a naive script sees "has an MX record" and passes it. And the same RFC notes that mail software looks "first by looking for an MX record and then by looking for an A/AAAA record as a fallback", so "no MX" does not by itself mean undeliverable.

6. Flag disposable and role addresses

Remove disposable addresses and flag role addresses for a separate decision. A disposable inbox (Mailinator and thousands of similar services) is real but abandoned, so nobody will read your email. Check against a maintained list; our disposable email checker uses one.

Role addresses (info@, sales@, support@) are different. They are often fine for transactional mail and genuine B2B enquiries, and riskier for cold or bulk sends. Flag them rather than deleting, and worth deciding per campaign.

7. Verify mailboxes

Ask each recipient's mail server whether the specific mailbox exists, without sending a message. This is the step that finds the dead mailboxes behind otherwise valid domains, and it is the main cost of cleaning.

Expect three results, not two:

• Valid: the server confirmed the mailbox.
• Invalid: the server rejected it. Remove these.
• Risky (or unknown): the server would not confirm either way, usually because the domain is catch-all.

Run this step last among the removals because it is the one you pay for per address, and every earlier step has made the list shorter.

8. Separate inactive contacts

Split contacts who have not engaged for a long time into their own segment before deciding what to do with them. A verified address can still belong to someone who stopped reading years ago. Those contacts do not bounce, but they lower engagement, and long-abandoned addresses are the raw material for recycled spam traps.

Do not lean on opens alone to define inactive. Apple's Mail Privacy Protection loads remote content in the background when a message arrives, which can record opens nobody made. Clicks, replies and purchases are firmer signals. Give the segment one re-engagement attempt, then suppress those who still do not respond.

9. Decide what to do with risky addresses

Risky is a decision, not a result to ignore. On a catch-all domain, no verifier can confirm a mailbox, so the address may be real or may be a typo that will be accepted and then bounced or silently discarded. What is a catch-all domain covers the mechanics.

Sensible defaults:

• Send to risky addresses only from an established domain, never a new one.
• Send them as a separate segment so their bounces do not hide inside the main send.
• Start small, check the bounce rate, and stop if it is high.

10. Process bounces after every send

Cleaning does not end when the list is sent, because some bad addresses only show up afterwards. Verification works at the SMTP stage, but not all rejections happen there. M3AAWG's Sender Best Common Practices (version 4.0, August 2026) notes that some mail is returned asynchronously, "hours or even days later", and that "B2B mail may have a higher rate of asynchronous bounces".

The same document gives a removal rule for repeated bounces: "generally it is considered a best practice to remove an address from the list if it bounces consecutively at least two times over two weeks or more." Platforms apply their own versions; Mailchimp, for example, cleans an address after 7 soft bounces, or 15 if the contact has engaged before.

Hard bounces for unknown users should be suppressed immediately, and added to the suppression list from step 3 so they never come back on a re-import.

How often to repeat it

Repeat steps 2 to 7 on every new import, and the whole process on any list that has not been mailed for months. There is no universal schedule, because decay depends on your audience. A B2B list loses addresses as people change jobs; a list you mail weekly gets cleaned continuously by bounce processing; a list you mail twice a year does not. How often to re-verify goes into cadences by use case.

What cleaning cannot fix

Cleaning removes dead addresses; it does not create permission. Mailchimp's own help page on list cleaning services warns that cleaning "can hide bigger issues with your audience collection and management procedures", and we agree. If a list was bought or scraped, a clean version of it will bounce less and still draw complaints. Fix collection at the source with confirmed signups and verification at the form.

The takeaway

Clean in the order of cost and certainty: keep the original, normalise and dedupe, apply suppression lists, check syntax and domains, flag disposable and role addresses, then pay to verify what is left. After that come the judgement calls (inactive contacts and risky addresses), and after every send, bounce processing, because some failures only show up later. Run your own domain through the deliverability audit while you are at it, since a clean list sent from a misconfigured domain still lands in spam.