Unsubscribe: the requirement that protects your sending

A recipient who wants your email to stop has two buttons available. One is your unsubscribe link. The other is the spam button in their mail client, and it is closer, larger and more familiar.

Those two actions have very different consequences for you. An unsubscribe removes one address and tells the mailbox provider nothing. A spam complaint tells the provider that mail from your domain is unwanted, and that judgement is applied to the mail you send everybody else — including the people who do want it.

Google's sender guidelines put a number on the tolerance: keep the spam rate reported in Postmaster Tools below 0.30%, and the accompanying guidance is to stay under 0.10%. Those are small fractions. On a list of ten thousand, thirty complaints is the ceiling and ten is the target, which means a handful of frustrated readers per send is enough to matter.

So the case for an easy, obvious unsubscribe is not politeness. It is that every reader you make work for it is a reader who may take the more damaging option instead.

The phrase is widely misunderstood as 'the link in your footer should only take one click'. The requirement is more specific and it lives in the message headers, not the body.

A List-Unsubscribe header tells the mail client where an unsubscribe request should go. Paired with List-Unsubscribe-Post, described in RFC 8058, it lets the client offer its own unsubscribe control — the small link Gmail shows next to the sender name — and submit the request directly, without the reader visiting your site at all. That is the mechanism being required.

Two consequences follow. First, a mailto-only List-Unsubscribe header does not satisfy it, because it does not support that direct submission. Second, the header does not replace the visible link: Google's guidelines ask for a clearly visible unsubscribe link in the message body as well. The two serve different readers — one who trusts their mail client's control, and one who scrolls to the footer looking for yours.

Google applies its bulk-sender requirements to senders of 5,000 or more messages a day to personal Gmail accounts, with the rules taking effect in February 2024. Yahoo introduced matching requirements on the same timeline, and other major providers have since aligned.

Two details in that threshold catch people out. Volume is counted across a primary domain, so mail from subdomains rolls up rather than being counted separately — splitting a campaign across three subdomains does not put you under the limit. And once a domain has been classified as a bulk sender, it is treated as one going forward rather than reassessed downward on a quiet week.

For a smaller sender the formal threshold is not the interesting part. Nothing about the filtering logic consults your volume before deciding where to put a message, and the signals it reads — complaints, engagement — behave the same at five hundred messages as at fifty thousand. The requirement is a floor for large senders and a good description of the expected standard for everybody.

Both Google's and Yahoo's guidance expect an unsubscribe request to be processed within two days. That is a genuinely short window if any part of your process is manual, and it is the reason unsubscribes should be handled by the sending system rather than by somebody reading a mailbox.

The request also has to actually work without conditions attached. Requiring a login before someone can unsubscribe fails, because the reader who wants out is frequently the reader who never had an account or cannot remember the password. Asking them to confirm twice, presenting a multi-step wizard, or making them find their address and re-type it all convert an unsubscribe into a spam complaint at a predictable rate.

Asking why they left is fine, provided it comes after the request has been honoured. 'You have been unsubscribed. If you have a moment, we would like to know why' is a survey. 'Tell us why to complete your unsubscribe' is a condition, and it is the version that generates complaints.

A meaningful share of unsubscribes are not rejections of your business but of your frequency. Somebody who signed up for occasional news and receives four messages a week is leaving over volume, and offering a genuine alternative retains some of them.

A preference centre does that: fewer messages, specific topics only, a pause for a period, or a single monthly summary instead of individual sends. Each of those is a real option a reader might prefer to leaving entirely.

The failure is making it the only exit. If the unsubscribe link leads to a page whose options are all forms of staying subscribed, with the actual opt-out placed last in small text, the page is an obstacle wearing the costume of a choice, and it does not satisfy the one-click requirement either — that path bypasses your pages entirely by design. The workable arrangement is a plain unsubscribe that works immediately, with the alternatives offered alongside it rather than in front of it.

Record every unsubscribe: the address, the timestamp, and how the request arrived — header, footer link, or reply. This costs nothing and answers the two questions that come up later.

The first is a dispute. If somebody says they opted out and are still receiving mail, the log is what distinguishes a system failure from a second signup, and it is the only evidence either way.

The second is a re-import. An unsubscribed address that is merely removed from a list will come back the next time somebody uploads an older spreadsheet, and the person will receive mail they explicitly declined — which is the fastest route from unsubscribe to complaint. A permanent suppression list prevents that, and it has to survive migrations: when you change providers, the suppression list moves with the subscriber list or the move is incomplete.

Treat suppression as a record of decisions people made rather than as a list of addresses you failed to keep. Framed that way, it is obvious why it should outlive any tool you use.