How to clean your email list (and why it protects your domain)

Cleaning a list means removing four different things, and they need four different methods. Addresses that cannot receive mail, addresses that can but should not be mailed, addresses you have already been told to stop mailing, and duplicates of addresses you are keeping. A verifier only addresses the first, imperfectly, and it is getting worse at it as the large providers stop answering recipient probes honestly. The protection this buys your domain is real: every invalid address is a hard bounce, and hard bounce rate is one of the few signals every mailbox provider agrees on.

What cleaning removes, and the order the stages have to run in

Run the cheap deterministic stages first, because each one shrinks the list the expensive stage has to process.

1. De-duplicate against a normalised key. Free, and it removes the class of error where the same person receives the same sequence twice from two imports.
2. Reject the structurally impossible. Pure string work against the size limits in the SMTP standard. No network calls.
3. Resolve the domain. One DNS lookup per distinct domain, not per address. A list of 20,000 contacts across 4,000 companies is 4,000 lookups, not 20,000.
4. Probe the mailbox, where probing still returns information. This is the slow, rate-limited, increasingly unreliable stage, and by this point it is running against a much smaller set.

Then a fifth stage that is not verification at all: removing addresses that are deliverable and should still come off the list.

Stage one: normalise before you de-duplicate, and know what you are throwing away

The domain half of an address is a DNS name and is case-insensitive. The local part is not. RFC 5321 section 2.4 is explicit: "The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts." The same RFC adds that exploiting that case sensitivity "impedes interoperability and is discouraged", which is why lowercasing the whole address is safe in practice and wrong in theory.

The de-duplication trap is more aggressive normalisation. Gmail ignores dots in the local part and treats everything after a plus sign as a tag, so [email protected] and [email protected] reach the same person. Almost no other provider behaves that way. Applying Gmail's rules to every domain merges distinct people at any provider that treats dots as significant, and you will not find out, because the symptom is a contact who silently never gets mailed.

Normalise the domain to lowercase always. Apply provider-specific local-part rules only to that provider. Keep the original string in a separate field so a merge is reversible.

Stage two: the size limits that are actually in the standard

Validating an address by regular expression is a trap, because the grammar in RFC 5322 permits quoted local parts containing spaces and almost any character. Chasing full grammar conformance produces an expression nobody can maintain and rejects valid addresses.

Validate against the size limits instead, which are unambiguous. RFC 5321 section 4.5.3.1 sets them:

• Local-part: 64 octets maximum.
• Domain: 255 octets maximum.
• Path: 256 octets maximum, counting the angle brackets.
• Command line: 512 octets, and text line: 1000 octets.
• A server must accept a buffer of at least 100 recipients in one transaction.

An address exceeding any of those cannot be delivered by a conforming server, which makes rejection safe. Beyond that, check for the structural impossibilities: no @, more than one unquoted @, an empty local part, a domain with no dot, a domain ending in a hyphen. Everything cleverer than that costs more than it returns.

Stage three: does this domain accept mail at all

One dig per distinct domain, and three outcomes worth distinguishing.

dig MX example.com +short

A list of mail exchangers. Normal. Move on.

A single line reading 0 . — preference zero and a bare dot. This is the null MX defined in RFC 7505, and it is a domain publishing that it accepts no mail whatsoever. It is one of very few definitive negatives in this whole subject: every address at that domain is undeliverable. RFC 7505 says a server rejecting on it "SHOULD use a 556 reply code (Requested action not taken: domain does not accept mail) and a 5.1.10 enhanced status code". Delete the whole domain from the list, not just the address in front of you.

No answer at all. Then check for an address record, because RFC 5321 falls back to the implicit MX — a domain with an A or AAAA record and no MX is mailed at that address directly:

dig A example.com +short

No MX and no address record means the domain cannot receive mail. That is a second definitive negative, and it catches typo domains and dead companies in one pass.

This stage is worth running on its own even if you never probe a mailbox, because it is fast, it costs nothing, it needs no third party, and its negatives are certain rather than probabilistic. The free email checker runs it without a terminal.

Stage four: the SMTP probe, and why it is quietly stopping working

The probe opens a conversation with the domain's mail exchanger and asks whether it will accept a specific recipient, without ever sending a message. Four commands, in order:

1. EHLO probe.yourdomain.com — identify the connecting host. Use a hostname that resolves, on infrastructure that is not your sending infrastructure.
2. MAIL FROM with an empty reverse path, written as a bare pair of angle brackets. RFC 5321 reserves that empty path for notifications, so the transaction cannot itself generate a bounce loop.
3. RCPT TO with the address under test. This is the command whose reply carries the whole verdict.
4. QUIT without ever issuing DATA. Nothing is delivered.

The interesting reply is the one to RCPT TO.

• 250 — the server says it will accept mail for that recipient.
• 550 5.1.1 The email account that you tried to reach does not exist. — Gmail's wording for a genuine unknown recipient. A clean negative.
• 450 4.2.1 — a temporary refusal, most often greylisting. Not a verdict. Retry later or record it as unknown.
• 252 — the server cannot verify in real time. RFC 5321 section 3.5.3 specifies this reply for exactly that situation, and it means nothing has been established.

Four things have made this stage far less useful than the tooling around it implies.

Acceptance at the edge. The large providers increasingly accept every recipient at the perimeter and make the real routing decision afterwards, generating an asynchronous bounce if the mailbox does not exist. Against such a domain, 250 for a real address and 250 for an invented one are the same answer, so the probe has told you nothing.

Greylisting and tarpits. Deliberate delays that turn a verification run into hours and produce temporary failures indistinguishable from a slow server.

Reputation cost to the prober. Opening thousands of connections that never send mail is behaviour blocklists score, so bulk probing damages the reputation of whatever IP does it. This is why probing at scale belongs on infrastructure that is not the infrastructure you send from.

Catch-all domains. A domain configured to accept every recipient returns 250 universally by design. That is not a verifier failing; it is the domain answering truthfully that it accepts everything, and what a catch-all domain means for deliverability is a separate decision about whether to mail it at all.

A verifier that reports "valid" for a catch-all domain is guessing. One that reports "unknown" or "accept-all" is telling you the truth, and the honest verdict is the more useful product.

The addresses that are deliverable and should still come off

Verification cannot help here. These are judgement calls encoded as rules.

Role accounts. RFC 2142 reserves mailbox names for organisational functions rather than people: postmaster, abuse, security, noc, hostmaster, webmaster, plus the business set info, sales, marketing and support. Every one of these is a shared inbox with no single owner. Two of them are actively hazardous: abuse@ and postmaster@ route to the people whose job includes reporting senders, and RFC 5321 section 4.5.1 requires that postmaster be accepted, so it will never bounce and never reply.

Spam traps. Spamhaus describes three kinds. Typo traps are "email addresses with a misspelled domain name similar to legitimate mailbox provider domains" — catchable by checking the domain against the common misspellings of the large providers. Recycled traps are "email addresses that were once valid but are now no longer used", which is why suppressing long-dormant hard bounces permanently matters. Pristine traps are the hard case: addresses that were never valid for anybody, published only where a scraper would find them. They are deliverable, they have no distinguishing feature, and no verifier can detect one. The only defence is not acquiring them, which means not buying scraped lists.

Prior complainers and unsubscribes. Non-negotiable, and the reason the next section exists.

Long-dormant contacts. Judgement. There is no audited public figure for how fast a B2B list decays, and anybody quoting you a monthly decay percentage is describing their own data at best. Rather than apply a borrowed number, measure your own: track the hard-bounce rate of each import cohort by age and you will have a real curve for your own market within two quarters.

Suppression is a permanent structure, not a delete

Deleting a contact does not suppress them. The next CSV import resurrects the address, the sequence enrols them again, and a person who asked to be left alone gets mailed a second time — which converts a lost lead into a complaint.

Suppression needs to be a separate store with four properties:

• Workspace-wide, not per campaign or per list. The person opted out of you, not out of one sequence.
• Keyed on the normalised address, with an optional domain-level entry for the case where an organisation asks to be removed entirely.
• Consulted at enrolment and again at send. A contact suppressed between enrolment and the third follow-up must not receive the third follow-up.
• Carrying a reason and a timestamp. Hard bounce, complaint, manual unsubscribe, one-click unsubscribe. You will need to answer "why is this person suppressed" a year later, and the answer determines whether they can ever be re-added.

Autocloz auto-suppresses hard bounces and complaints at workspace scope and re-checks suppression at send time rather than only at enrolment, so a mid-sequence unsubscribe stops the remaining steps. The free plan covers 5 users and 10 mailboxes with that suppression store and the bounce monitoring included — start free if the current setup is a spreadsheet column.

The arithmetic of a bounce rate on a small batch

Bounce rate is a proportion measured from a sample, and small batches produce intervals wide enough that most reactions to them are reactions to noise. Two bounces out of fifty delivered messages reads as 4.0%, and its 95% Wilson confidence interval runs from 1.1% to 13.5%. On that evidence you cannot distinguish a clean list from a badly contaminated one.

Two consequences. Do not treat a bounce rate as a signal below roughly a hundred sends. And when you do react, react to the right class — a hard bounce is a permanent rejection at the recipient address and a soft bounce is a temporary condition such as a full mailbox, and treating them identically deletes valid contacts. Autocloz pauses a campaign whose bounce rate crosses a configured threshold and applies no threshold below a 100-send sample for exactly this reason.

If the rate is genuinely high, the fix is upstream of the campaign rather than inside it: verification at import, re-verification before a large send to an aged cohort, and permanent suppression of everything that has already bounced hard. The full bounce-reduction sequence covers the ordering.

What list cleaning cannot do, and what Autocloz does not do

Cleaning cannot repair a domain that has already accumulated complaints and hard bounces. It changes what happens next; it has no mechanism to retract a spam report already filed or a bounce already recorded.

It cannot detect a pristine spam trap, for the reason above — the address is deliverable and looks like every other address on the list.

It cannot make a verifier certain against a provider that accepts everything at the edge, and any tool reporting high confidence on such a domain is reporting confidence it does not have. Vendors whose core product is address verification, of the kind compared on the Hunter comparison page, face the same wall for the same reason.

And it cannot make an unwanted message welcome. A clean list of people with no reason to hear from you produces low bounces and high complaints, which is a worse outcome than the dirty list, because complaint rate weighs more heavily with every provider than bounce rate does.

Autocloz specifically: it verifies on import, auto-suppresses hard bounces and complaints, flags catch-all domains as unknown rather than as valid, and monitors the sending domain's SPF, DKIM and DMARC alongside the email sending stack. It does not sell contact data or bundle a lead database, so the list you clean is one you brought. It cannot see whether an address belongs to a real person who wants your email. And it does not report a confidence figure for an accept-all domain, because there is no honest one to report — the deliverability checker will say so plainly rather than pick a number.