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 email that can reach somebody who never asked for it carries the unsubscribe URL twice — visible in the footer, and in the List-Unsubscribe header so a client can render its own control. That is two kinds of message: a briefing notification, whose link is /p/{token}/block, and a contact request, whose link is /c/{token}/decline. Both answer 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. Undoing it is deliberately asymmetric: it takes an account. The person who placed the block can lift it from their contacts page or by asking their assistant, and nothing the blocked sender can do reaches it. Unblock deletes the pair rather than putting you back in their contacts. Support and the operator path will not lift it for them.
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.
It is reachable only by somebody who was actually sent something, because it rides on a token that arrived in a message: there is no standing block list to edit. What it no longer does is age out. The link used to be measured against the package's own thirty-day expiry, which put the opt-out in the odd position of dying before the reply link did — at day forty you could still answer a message and no longer refuse it. An unsubscribe that expires fails at exactly the moment somebody reaches for it, and finding an old email and following the link is the commonest way one is ever used, so it does not expire now. The page it opens still says who you are about to stop.
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.