# Should I add an unsubscribe link?

> Yes for bulk and marketing mail — it's required by law and by mailbox providers. SendPing campaigns auto-inject a per-contact link and a List-Unsubscribe header. Transactional opt-out is sender-driven.

**For bulk and marketing email, yes — always.** A clear unsubscribe link is required by anti-spam law (CAN-SPAM, CASL, GDPR) and effectively required by Gmail and Yahoo, which mandate one-click unsubscribe for bulk senders. Just as importantly, it's your best defense against spam complaints: a recipient who can't find the unsubscribe will hit *Report spam* instead, which hurts you far more.

## Campaigns: handled for you

When you send a [campaign](https://www.sendping.co/docs/campaigns/managing), SendPing automatically adds **both** mechanisms to every copy:

- **A per-contact unsubscribe link in the body.** If your HTML already contains an unsubscribe link, SendPing leaves it alone; if it doesn't, a small footer with a working opt-out link is appended — so a campaign can never go out with no way to opt out.
- **A `List-Unsubscribe` header with one-click support** (RFC 8058 `List-Unsubscribe-Post`). This powers the native *Unsubscribe* button Gmail and Apple Mail show next to your name.

When a contact unsubscribes through either path, SendPing marks them unsubscribed and skips them on future sends. See [Unsubscribed contacts](https://www.sendping.co/docs/audiences/unsubscribed).

> **Note:** Because campaigns auto-inject the link and header, you don't need to hand-build unsubscribe handling for marketing campaigns — it works out of the box.

## Bulk mail via `POST /emails`: set a `topic_id`

If you send newsletters or product announcements through `POST /emails` rather than a campaign, tag the send with a [`topic_id`](https://www.sendping.co/docs/topics/overview). That marks it as subscription mail, and SendPing adds the same two mechanisms it adds to a campaign: a per-recipient unsubscribe footer and the RFC 8058 `List-Unsubscribe` header. Recipients do not have to be contacts — the opt-out is recorded against the address.

> **Note:** A topic opt-out is scoped to **that topic**: the address keeps receiving your other email, including receipts and password resets. Only later sends carrying the same `topic_id` skip it.

## Transactional email: sender-driven

Transactional messages sent with `POST /emails` and **no** `topic_id` (password resets, receipts, order confirmations) are **not** automatically given an unsubscribe footer — these are one-to-one operational mails the recipient expects, and a marketing-style unsubscribe is often inappropriate (you can't opt out of your own receipt). It would also be dangerous: an unsubscribe writes a suppression that blocks every later send to that address, so one stray click on a password-reset footer would cut off the recipient's own account recovery.

That means opt-out for transactional mail is **sender-driven**: it's up to you to decide when an opt-out makes sense and to add your own link. If a recipient should be able to stop a given transactional stream, include your own unsubscribe link in the `html` body and record the resulting opt-out as a [suppression](https://www.sendping.co/docs/emails/suppressions) so future sends to that address are skipped.

## Rule of thumb

| Mail type | Unsubscribe link | Who handles it |
| --- | --- | --- |
| Campaign / marketing | Required | SendPing (auto link + List-Unsubscribe header) |
| Newsletter / bulk via `POST /emails` **with** `topic_id` | Required | SendPing (auto link + List-Unsubscribe header, scoped to the topic) |
| Newsletter / bulk via `POST /emails` **without** `topic_id` | Required | You — add a link and suppress opt-outs |
| Transactional (receipts, resets) | Optional / case-by-case | You (sender-driven — SendPing adds nothing) |