Email Lists, the Quick SOP

The one-page version. It exists because we keep over-complicating list cleaning and, twice now, nearly binned real members on soft flags. If you read nothing else, read Section 1. The full process, with the two switches, add-ons and compliance detail, is in Email Deliverability, the Whole Process; the click-by-click mechanics are in the Operator Guide.

1. The one rule

Only three kinds of address are ever a permanent no-send:

undeliverable, Bouncer confirms it will bounce (dead mailbox / invalid domain).
disposable, a throwaway address, not a real ongoing contact.
A confirmed opt-out from the club's own platform (real unsubscribe / DND / complaint).

Everything else is a member. You will send to them. The only question is when, not whether.

On a real member list you should keep 98 to 99%+. If your remove pile is bigger than a rounding error, go back and find the soft flag you treated as "dead".

2. Every Bouncer flag except "undeliverable" is a caution, not a verdict

Bouncer throws off lots of little warning flags. Only one of them means the email is dead.

Bouncer flag	What it actually means	What we do
`undeliverable`	Will bounce. Dead.	REMOVE (the only real remove)
`disposable`	Throwaway address	REMOVE
`risky` / `unknown`	Couldn't fully verify (dying ISP domains, etc.)	HOLD, send last
`acceptAll` (catch-all)	Domain accepts anything, mailbox unverifiable	SEND, just not in the first batch
`role` (`mail@`, `info@`, `me@`)	Maybe a shared inbox	HOLD & confirm. On a personal domain it's just a person
`toxicity` 2+	Maybe a spam trap / complainer	HOLD, then let the club's own data decide (Section 3)
`didYouMean`	A recoverable typo (`@gmial.com`)	FIX, never bin
`unsubscribedAt`, `open`, `click` columns	Bouncer's network guesses, not the club's data	IGNORE. Get real opt-outs from the club's platform

3. The golden principle: the club's own data beats the verifier's flag

A verifier can only guess at an address in the abstract. The club's own send history knows whether a real person is behind it. When the two disagree, the club's data wins.

Two real cases taught us this:

Rob Sennett (mail@robsennett.com), Highgate. Bouncer said deliverable, score 100, toxicity 0. Perfect address. But it was flagged role because of the mail@ prefix, and our process nearly binned it as a "shared office inbox". It's a freelance photographer's personal email. A role flag on a personal domain is a false positive. Never auto-remove a role address; hold and confirm.
Cottesmore's 168 "toxic" addresses. We were about to permanently suppress 168 members on a toxicity 3+ score. Cross-checked against Cottesmore's own CRM: 122 were tagged hot or warm and had opened past emails, with no bounce history. Ordinary personal Hotmail and Gmail addresses of active members. A spam trap does not sit in a golf club CRM, tagged hot, opening emails. The toxicity flag was a false positive at scale, the same error as Rob Sennett. The club's engagement data cleared them; we sent.

The test that settles any flagged address: has this contact opened, clicked or replied to the club's own emails, and does the club's own history say it bounced? Engaged and clean = send.

The one exception, no engagement to clear it. On a cold contact or a dormant old database, there is no recent engagement to prove a real human, and dormant addresses are exactly where recycled spam traps live. There, a toxicity-2+ flag stands and the address is suppressed (this is the dormant-list switch: a dormant database suppresses toxicity, an active list does not, different data, same principle, see Email Deliverability, the Whole Process). Engagement overrides the flag where it exists; where it doesn't, the flag holds.

Watch out for crisis-window bounces. A "bounced" tag logged during a deliverability incident is unreliable. When the sending IP is blocklisted, good addresses bounce too (Cottesmore's June bounces were ~54% reputation-blocks, only ~8% genuinely invalid). Don't kill an address for a crisis-window bounce; re-test it once the reputation is clean.

4. The three-wave send

Sort by confidence and send safest first. Between waves, watch one number: hard bounce rate.

Wave 1, deliverable + engaged (the club's "hot"). Safest, sends first.
Wave 2, the rest of the deliverable list.
Wave 3, the hold group (risky, catch-all, role, toxicity-flagged-but-engaged). Folded back in once Waves 1-2 came back clean.

Gate: hard bounce under 1% (target under 0.5%), spam complaints under 0.1%. Under the line, keep going. Over it, pause and diagnose. Drip at ~300/hour, never one big burst. Ignore open rates as a health signal (Apple inflates them); watch bounces and complaints.

5. Two modes: which one am I in?

The full staged, batch-by-batch process is for building or rebuilding reputation. Run it end to end only when it's the first send from a new sending domain, or you're recovering from a deliverability incident (a block or blocklisting).

Once the domain is warm and the list is verified, you're in ongoing mode: send to everyone in one go except the permanent no-sends (Section 1). No re-bucketing, no five campaigns, no hot/warm/cold tiers. Still drip, still glance at the gate. A newsletter to an onboarded club is a ten-minute job, not a project. Re-verify through Bouncer every 6 to 12 months, not every send.

6. The 20-second checklist

[ ] Verify list through Bouncer
[ ] REMOVE only: undeliverable + disposable
[ ] IGNORE Bouncer's open/click/unsub columns
[ ] Pull REAL opt-outs + engagement from the club's platform (this overrides every flag)
[ ] role / toxicity / risky flags on engaged, never-bounced members = SEND, don't bin
[ ] No engagement to clear a toxicity 2+ flag (cold/dormant) = suppress it
[ ] Send in three waves, safest first, bounce rate <1% between each
[ ] Onboarding/recovery = staged. Ongoing newsletter = one send minus the never-sends.
[ ] Re-verify every 6-12 months