Deliverability

Should I add an unsubscribe link?

Yes for bulk and marketing mail — it's required by law and by mailbox providers. MailBlastr 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, MailBlastr automatically adds both mechanisms to every copy:

  • A per-contact unsubscribe link in the body. If your HTML already contains an unsubscribe link, MailBlastr 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, MailBlastr marks them unsubscribed and skips them on future sends. See Unsubscribed contacts.

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`. That marks it as subscription mail, and MailBlastr 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.

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 so future sends to that address are skipped.

Rule of thumb

Mail typeUnsubscribe linkWho handles it
Campaign / marketingRequiredMailBlastr (auto link + List-Unsubscribe header)
Newsletter / bulk via POST /emails with topic_idRequiredMailBlastr (auto link + List-Unsubscribe header, scoped to the topic)
Newsletter / bulk via POST /emails without topic_idRequiredYou — add a link and suppress opt-outs
Transactional (receipts, resets)Optional / case-by-caseYou (sender-driven — MailBlastr adds nothing)