Search...

Unsubscribes

Every broadcast SpiderMail sends to a subscriber audience carries a working unsubscribe, and honouring it is handled for you. This page explains what your recipients see, what happens when they use it, and what you are responsible for.

Why this is not optional

Gmail and Yahoo both require bulk senders to offer one-click unsubscribe and to process it within two days. A sender who does not is not penalised with a warning — their mail goes to spam, including the mail people asked for.

There is a second reason that matters more day to day. Someone who wants out and cannot find the exit marks the message as spam instead, and a complaint costs your domain far more reputation than an unsubscribe does. A visible, working unsubscribe is the cheaper outcome for you.

Before you begin

Nothing to configure. One-click unsubscribe is applied to subscriber broadcasts automatically. You do not add a header, a link, or a footer to make it work.

What your recipients get

Two routes out, and they cover different readers:

::table
Route | Where it appears | Who uses it
One-click | the mail client's own "Unsubscribe" control, next to the sender name | most people, because it is where they already look
The link | the message footer | anyone whose client does not show the control

The first route works because each broadcast carries List-Unsubscribe and List-Unsubscribe-Post headers, which is what tells Gmail and Yahoo to render their own unsubscribe button. That button is more trusted than anything inside the message body, and it is the one most recipients will press.

What happens when they use it

The recipient is taken to a confirmation page, and the unsubscribe is recorded once they confirm or once their mail client posts on their behalf.

Two properties are worth knowing:

  • Viewing the page changes nothing. Some mail clients and security scanners fetch every link in a message. If merely loading the page unsubscribed people, those scanners would quietly unsubscribe your audience for you. Only the confirming action records anything.

  • The suppression is yours alone. It applies to your workspace's subscriber sends. It is not shared with other workspaces, and one workspace's unsubscribes never suppress another's.

Once recorded, that recipient is excluded from future subscriber broadcasts. You do not need to edit a list — the exclusion is applied when the audience is resolved, so it takes effect on the next send whether or not you have refreshed anything.

What you are still responsible for

An unsubscribe mechanism does not, on its own, make a send lawful. You still need a defensible reason to be mailing each recipient in the first place, and the rules differ by jurisdiction and by how you obtained the address.

Two habits that keep this simple:

  • Send to people who asked. Every deliverability feature is downstream of that one.

  • Keep your own record of where an audience came from, so that if anyone asks, the answer exists.

Troubleshooting

A recipient says they unsubscribed but got another message. Check which audience the second message went to. Unsubscribes are recorded against the audience they came from, so a recipient who is on a subscriber list and also reachable through another audience type can still be included in a send built from the other one. If that is not what you intended, remove them at the source.

Someone was unsubscribed and says they never clicked. Their mail provider or a security scanner may have posted on their behalf, which is a normal part of how one-click works. Re-subscribing is a decision for that recipient, not something to reverse on their behalf.

Your test message has no unsubscribe control. The controls appear on subscriber broadcasts, not on individual messages sent through a mailbox. A one-to-one message is not a bulk send and is not treated as one.

What next