Email Deliverability, the Whole Process

Start here. This is the one process we use to send any club's email list, whether it's a live member base, a newsletter list moving over from another tool, or an old dormant visitor database. There is not a separate process for each. There is one backbone, and two simple questions decide how careful we have to be.

If you only take one thing from this page: it is the same job every time. The only things that change are how new the sending address is, and how alive the list is.

For the 20-second cleaning cheat sheet, see Email Lists, the Quick SOP. For clicking the actual buttons, see the Operator Mechanics. This page is the why and the which mode am I in.

---

The backbone (always true, every club, every send)

1. Authenticated subdomain. Always a subdomain (mail.theclub.co.uk), never the club's root domain, with SPF, DKIM and DMARC passing before the first send. Marketing sending never touches the club's corporate email reputation.
2. Verify and clean the list (Bouncer). The only permanent no-sends are undeliverable, disposable, and a confirmed opt-out from the club's own platform. Everything else is a real contact. On a member list you keep 98 to 99%+. Full rules in the Quick SOP.
3. The club's own data beats the verifier's flag. A soft flag (toxicity, role, risky) on a contact who opens the club's emails is a false positive. We hold, check against the club's engagement history, and send. This is the lesson that nearly cost Cottesmore 122 real members.
4. Send the most engaged first, then widen. Warmest contacts generate the positive signal that builds reputation. Segment on the club's real clicks and replies, never on opens.
5. Drip, never burst. Around 300 per hour across daytime hours. One big blast is what pattern-matches to abuse. Cottesmore's four full-list blasts in ten days is what broke it.
6. Watch three gates, ignore opens. Spam complaints, hard bounces, accepted rate. Apple Mail inflates opens 40 to 50%, so opens are noise. See The gates.
7. Judge by signals, not the calendar. Climb when the gates stay green, pull back the moment one turns red. Hertsmere doubled its planned ramp because day one came back clean. Never hard-code a schedule.
8. Once warm, just send. When the domain is warm and the list was verified recently, an ordinary newsletter is one send to everyone minus the permanent no-sends, dripped. A ten-minute job, not a project.
9. Re-verify every 6 to 12 months. Not every send. Between times, the platform's own bounce and opt-out handling keeps the list clean.
10. Compliance backbone. Signed DPA before any data moves, written import instruction saved, data minimised, the club's real opt-outs carried across and honoured from day one. We are the processor; the club is the controller.

Everything below is just: which mode does this backbone run in today?

---

The two switches

Two questions decide the mode. They are independent, so answer both.

Switch 1, how warm is the sending domain?

• Already warm (has sent cleanly before, no recent incident) → Ongoing mode. Send to everyone minus the permanent no-sends, dripped. No tiers, no ramp. Done.
• Brand new (never sent) → Warm-up mode. Run the staged ramp: engaged first, widen as the gates hold.
• Damaged by an incident (a block, a blocklisting, a bounce spike) → Recovery mode. Same staged ramp, plus the incident add-on.

You only ever run the full staged ramp once per domain: the first time it sends, or after an incident. After that it's warm, and you're in ongoing mode for good.

Switch 2, how alive is the list?

• Actively mailed and consented (a live member base, or a newsletter list that's been getting regular emails, whatever tool it came from) → the relationship is warm. No re-permission. The club already has engagement data, so that data clears soft flags. You're only being careful because the sending address is new, not the relationship.
• Genuinely dormant (nobody has mailed it in roughly 12 to 18 months, or there's no evidence it was ever a consented list) → the opt-in has gone stale and dead addresses have turned into spam traps. Add a re-permission step ("still want to hear from us?") to the coldest tier, then sunset anyone who stays silent. With no recent engagement to clear them, soft flags here stand.

The dividing line is dormancy, not "member vs visitor." A 10,000-person visitor newsletter that goes out every month is warm and needs no re-permission. A neglected member list nobody has emailed in two years might. Judge the list by how recently it was actually mailed, not by what it's called.

---

The two optional add-ons

These bolt onto warm-up or recovery mode only when they apply. They are not separate processes.

Add-on A, platform migration

The club is moving off another sending tool (an old golf-management platform, or a tool like Mailchimp). Before the first send:

• Prime, then Prove. While the old system is still live, send one announcement from it introducing the new sending address and asking members to save it as a contact. This rides the old tool's existing trust and is the single highest-leverage thing we do.
• Re-pull real engagement from the old tool (its own open and click history) to build the send tiers. Don't rely on the verifier's guesses.
• Keep the first fortnight plain, mostly text, one call to action, written from a named person, inviting a reply. A reply is the strongest positive signal a new domain can earn. Full newsletter design returns once reputation is established.

Add-on B, incident recovery

The domain's reputation is damaged (Cottesmore, Spamhaus SBL). On top of the staged ramp:

• Diagnose the authentication and the block first. Rebuilding volume on a still-broken setup just digs the hole deeper.
• Don't trust crisis-window bounces. When a domain is blocked, good addresses bounce too (Cottesmore's incident bounces were ~54% reputation blocks, only ~8% genuinely invalid). Re-test a bounced address once the reputation is clean; don't bin it.
• Rebuild over weeks, gated on results. Hold at each stage until it stays clean, using the 7-days-under-1%-bounce recovery gate before widening.

---

Membership is the highest-stakes version, not a different one

Members run the exact same process. They just get the most conservative dial settings and never a skipped check, because the stakes and the margins are the tightest we deal with:

• Small lists, tiny error budget. A member list is often 500 to 2,000. One spam complaint on a 500-person send is 0.20%; two is 0.40%, past the 0.30% line where Google and Yahoo start rejecting mail outright. There is almost no room for error.
• It's usually the club's corporate domain. The member sending subdomain sits under the same root as the secretary's own address and the board's. A dented reputation hits their 1-to-1 email, not just the newsletter.
• It's the core revenue relationship. A renewal email in the junk folder is lost money and lost trust.
• It's the most strictly judged. Members notice, complain, and expect recognisable, well-run communications.

So on a member list: run the full careful version, never cut a corner, and when a flag is ambiguous, hold and confirm rather than guess. A big dormant visitor list is the opposite risk profile (higher risk to the domain from dead weight, but more forgiving per contact). Same process, different stakes.

---

The gates

Read these daily during any ramp, from the sending infrastructure's own event data (not the in-platform dashboard, which only shows opens and clicks). Climb slowly, drop fast.

Ignore open rates as a health signal. When a signal turns red, pause, diagnose, and only resume when it's clean. Tell the club before changing the plan.

---

The worked examples (our own projects)

Three real projects, three different cells of the same process. Proof it's one backbone with switches.

---

The whole thing in one decision

1. Is the domain warm? Yes → just send (ongoing mode), you're done. No → staged ramp.
2. Why isn't it warm? New domain → warm-up. Incident → recovery + add-on B.
3. Is the list actively mailed, or dormant? Active → no re-permission, engagement clears flags. Dormant → re-permission + sunset, flags stand.
4. Migrating from another tool? Add Prime then Prove.
5. Is it a member list? Then it's the highest-stakes version. Most conservative settings, no cut corners.

Everything else, the cleaning rules, the gates, the drip, the compliance, is the same every time.