The link at the bottom of a bulk email does not remove you from anything. It sends a request to the party that wanted to email you, asking them to stop — and everything after the click happens inside systems that same party owns.
That is not cynicism, it is the ordinary architecture of bulk mail, and it tells you what an unsubscribe link is worth. The link is a promise about future behaviour, and promises differ in quality depending on who holds the enforcement. (What you are obliged to offer is a separate question. Rules vary by jurisdiction and by what you send, and that one belongs with your counsel.)
What the click actually does
The link carries an identifier for you — a contact row, a subscriber id, a signed token. Clicking it sets a flag on that row. Nothing else in the world changes. Next time a send is assembled, the sending logic reads the flag and leaves you out.
So the enforcement point is a query inside the sender's own tooling, exactly as reliable as their internal discipline. Several ordinary, non-malicious things undo it:
- A list exported before the flag was set, then re-imported somewhere else.
- A second sending platform — outreach in one tool, announcements in another — whose suppression list never heard about your click.
- Mail recategorised as transactional, and therefore assembled by a code path that never consults the marketing suppression list.
None of that requires bad faith. It requires only that the promise live in one place while the sending happens in several.
The one-click header is a better door, not a stronger lock
Careful senders also set two headers. List-Unsubscribe carries a URL or a mailto address, and List-Unsubscribe-Post marks that URL as safe to POST to without a human confirming first — the one-click convention specified in RFC 8058. Together they let a mail client render a native unsubscribe control next to the sender's name.
That is a real improvement. It removes the dark patterns — the nine-checkbox preference centre, the "are you sure" interstitial, the login wall in front of the opt-out.
But notice what did not change. The client relays a request; the sender still decides what to do with it, using the same flag on the same row. A better front door does not change who owns the building.
Three places a "stop" can live
Held by the sender. The flag above. As good as the sender's competence and intent, and it degrades quietly when either slips.
Held by the recipient. A rule in your own client, or your provider's junk classifier after you report something. The sender cannot see it, cannot override it, and does not have to cooperate — which is why reporting junk beats unsubscribing when you do not trust the sender.
Enforced in the send path. Rarest, and only possible when the sender's ability to reach you runs through a system that is not the sender's. If the thing that transmits the message checks the block before transmitting, unsubscribing stops being a request and becomes a condition of delivery.
Most email is the first kind. The second only exists downstream of a message that already arrived. The third is what you want and rarely get, because plain email has no shared layer that both parties trust.
Where RelayLink puts the block
RelayLink's is the third kind, for the mundane reason that a package only reaches you if RelayLink transmits it.
Every notification email carries the unsubscribe URL twice — visible in the footer, and in the List-Unsubscribe header so a client can render its own control. The target is one URL, /p/{token}/block, and it answers the two methods differently on purpose. A GET — you clicking the footer link — renders a single question with a single button. A POST performs the block, which is what a mail client's native control sends under RFC 8058, so the one-click path stays genuinely one click.
That asymmetry is not a dark pattern; it is the opposite of one, and it exists because of who else reads your mail. Corporate link scanners fetch every URL in an inbound message to detonate it in a sandbox. A /block that acted on GET would let a scanner silently unsubscribe you from a correspondent you wanted to hear from, and neither of you would ever learn why the thread went quiet. The confirmation page is there so that the only thing capable of blocking a sender is something with intent.
There is still no login, no account, and no preference centre: the authorisation is the per-package token itself, a 256-bit random value that arrived in your mailbox and that the sender never holds. Possession is the proof, the same trade any magic link makes.
Once written, the block is checked in two independent places. The send path refuses to create or confirm any further package from that sender to you — once when the draft is made, again when the send is confirmed, so a block landing between those two moments still stops the message. Separately, the notification sender re-checks before composing, skips that recipient's email, and logs the skip. Both run server-side, and neither is a preference the sender's assistant can route around.
The block binds the pair rather than the conversation, so a fresh thread on an unrelated topic from the same person is refused too. It outranks acceptance — an established correspondent who gets blocked stops immediately. And it does not come back. No unblock tool, no endpoint, no support flow.
What it still does not do
It is one sender, not the world. A block is a relationship between two accounts, not a do-not-contact entry keyed on your address, so a different sender can still reach you for a first time under the consent rules that govern who may contact whom.
It is not retroactive. Blocking stops future sends and future email; packages that already arrived stay where they are.
And it ages out with the link that carries it. Package tokens expire — thirty days by default — so blocking from a recent message works and blocking from one long past its token does not. Blocking is also only reachable by someone who was actually sent something: there is no standing block list to edit.
An unsubscribe link is only as good as the place the "no" is stored, and the ones worth much are stored where the sender cannot reach. If you are on the receiving end of machine-generated outreach, how to stop AI-generated spam covers the rest of your options — and for the view from the sender's side, what happens when someone blocks you.