What to do with 4,000 emails you collected and never mailed

The list has been sitting there for eighteen months. Waitlist signups from the launch that slipped two quarters, a CSV a co-founder exported from a conference badge scanner, the newsletter you ran for a while in 2024 and a tab called leads_final_v3 that nobody can account for. Four thousand rows. Someone suggests mailing it and the room goes quiet, because everyone half-remembers that mailing it is the kind of move that gets you blacklisted, without knowing exactly why.

The instinct is right and the reasoning is usually wrong. A few unsubscribes are not the risk. What you are risking is your sending domain — the domain in your from-address, which is very likely the same domain that sends password resets and receipts. Gmail and Outlook mark it down in a way that takes weeks to undo, filtering your transactional mail throughout. That's the thing to be afraid of. It's also entirely avoidable, because the failure mode is a single big send and nobody is making you do a single big send.

Every column you might sort on — signup date, source tool, job title — is less important than one question: what did this person actually do to end up in this file? That question splits the list into four buckets, and the buckets get treated very differently.

The rule underneath the table: if you cannot write down what the person did to get on this list, you do not send to them. That rule will delete more of the file than you want it to. Do it anyway, because the fourth bucket is where spam traps live — addresses that mailbox providers and anti-spam organisations operate specifically to catch senders using data they didn't collect. Hitting one is a serious negative signal. They never arrive alone. Orbit's list hygiene policy guide covers the trap taxonomy and the acquisition paths that produce them.

The law sits on top of this and varies by where the recipient lives, not where you do. The EU and UK expect consent with a record of it, plus the soft opt-in carve-out for existing customers. Australia's Spam Act 2003 requires consent, real sender identification and an unsubscribe honoured within five working days. The US CAN-SPAM Act is the permissive one — no prior consent required, opt-outs honoured within ten business days — and that permissiveness will not save you, because Gmail is not a regulator and applies its own thresholds to everyone regardless of jurisdiction.

Google publishes sender guidelines for bulk senders — anyone sending more than 5,000 messages a day to personal Gmail accounts. Two numbers in them matter here: keep your spam complaint rate below 0.3%, and aim to stay under 0.1%. Yahoo published matching requirements at the same time. Both are enforced by filtering, not by a letter.Source · GoogleEmail sender guidelinesGoogle's published sender requirements, including the 0.3% spam-rate limit and 0.1% target that took effect for bulk senders in February 2024.support.google.com/a/answer/81126

Run those against your spreadsheet. On a 4,000-address send, 0.3% is twelve complaints. Twelve people out of four thousand, on a list that hasn't heard from you in eighteen months, hitting a button that is sitting right next to Archive. Under 0.1% means four. That's the whole margin. It is not much, which explains why the single-blast approach fails in a way that feels sudden — you were never far from the line to begin with.

The second risk is bounces. An eighteen-month-old list has addresses whose owners have changed jobs, closed accounts, or died — and some of those dead addresses have been recycled by providers into traps. A high hard-bounce rate on a first send is a strong signal to a mailbox provider that you did not collect this list yourself, because senders who mail their own list continuously never accumulate that many dead addresses at once. You fix this before sending, not after. Bounce handling is the mechanism in full.

Verify the addresses. A bulk verification service (Kickbox, ZeroBounce, NeverBounce and similar all do this) checks each address for syntax, domain validity and mailbox existence, then returns a status per row. Drop everything it marks invalid, and drop the role accounts — info@, sales@, support@ — because they route to whoever is on the rotation, and whoever is on the rotation didn't sign up. Verification costs a few cents per thousand and it is the cheapest insurance in this entire post.

Authenticate the domain. SPF, DKIM and DMARC are the three DNS records that let a receiving server confirm mail claiming to be from you actually is. Google and Yahoo both require them of bulk senders, and an unauthenticated cold send is filtered before anyone has a chance to complain about it. Check what you have with the SPF checker and the DMARC record builder; the authentication guide explains what each record is doing.

Put the unsubscribe everywhere. One-click unsubscribe in the message headers — the RFC 8058 mechanism Google's guidelines require of bulk sendersSource · IETFRFC 8058: Signaling One-Click Functionality for List Email HeadersThe specification behind the List-Unsubscribe-Post header that mailbox providers use to render a one-click unsubscribe.www.rfc-editor.org/rfc/rfc8058. Then a visible, plain-language link near the top of the body, not only in six-point grey at the bottom. On a cold list this is a deliberate trade: you are choosing unsubscribes over complaints. That is the right trade every time. An unsubscribe removes one person. A complaint moves your rate toward twelve.

Now the actual plan. Send in increasing slices with gaps between them, warmest bucket first. Decide the stop thresholds before the first slice goes out. A workable shape for four thousand addresses, of which perhaps 2,400 survived triage and verification:

Watch four things after each slice, and read them in this order: hard bounces, complaints, unsubscribes, clicks. The stop rules I'd write down — and these are decision rules I'm asserting, not constants anyone has measured for your list — are: hard bounces above 2% on a slice means stop and re-verify, because the data is worse than you thought. Any complaint at all on a 200-address slice means slow down and reread the email, because on a slice that small the rate is meaningless and the absolute count is the signal. Unsubscribes are allowed to be high; on a cold list, 2–3% unsubscribing on the first send is the mechanism working, not failing.

That small-slice arithmetic is worth sitting with, because it's where people talk themselves into trouble. One complaint on a 200-send is 0.5% — already above Google's 0.3% line — and it is also just one person having a bad morning. Neither reading is safe on its own. Judge small slices on absolute counts and on whether the pattern repeats in the next slice. Judge the rate once you've sent to a thousand or more.

The Orbit Reputation Recovery skillis the playbook for the case where you've already sent the big blast and the numbers came back bad — triage order, what to pause and how long the domain takes to recover. Worth reading before you need it.

The first send to a cold list should not be your best campaign. Its job is not conversion, it's separation: finding the few hundred people who still want to hear from you and letting everyone else leave cleanly. A pitch makes both outcomes worse.

So: plain layout, few or no images, from a real person's name and a first line that says exactly where and when you got the address. "You joined the beta waitlist in March 2025. It took us a lot longer to open it than we said it would." Then what has changed, in two sentences. Then one clear choice: stay on the list, or leave, both one click. Do not bury the leave option. The people who take it were going to complain instead, and the two are not comparable: an unsubscribe removes one row, a complaint moves the one number Gmail is watching.

Then the artefact this whole post is for. Before slice one, write a file — call it cold-list-plan.md — with five things in it: the row counts in each provenance bucket after triage, the addresses you deleted and why, the four slices with the dates you'll send them, the stop thresholds and the name of the person who decides whether slice three goes ahead. That last line is the one that matters. A plan with thresholds and no named decision-maker becomes a plan where everyone assumes someone else is watching the numbers.

After the reset send, whoever didn't engage goes into a sunset process — two more attempts at most, then permanent suppression — and that process becomes a standing rule rather than a one-off cleanup. That's the whole point of doing this properly: you should never have another eighteen-month-old spreadsheet, because the rules that handle this one keep running.

The single sentence to take away: if you can't write down what a person did to get on this list, deleting their row is cheaper than sending to it. That will feel like throwing away pipeline. It's throwing away the reason your December launch email lands in spam.