**TL;DR:** A workflow for unsubscribe links in transactional mail: use the RESEND_UNSUBSCRIBE_URL placeholder, understand the difference between marketing opt-out and transactional suppression, and never let an unsubscribe kill receipts the user still needs. Handle unsubscribe in transactional mail 1. Receipts, password resets, and security alerts are transactional and must still reach the user; newsletters and promos are marketing and must honor unsubscribes.

## Handle unsubscribe in transactional mail

1. Include the `{{{RESEND_UNSUBSCRIBE_URL}}}` placeholder in marketing and product-update mail so every recipient gets a working one-click unsubscribe. Resend replaces it with the real link at send time. Docs: https://resend.com/docs/dashboard/broadcasts/send-broadcast-with-api
2. Decide per email type whether it is transactional or marketing before you write the footer. Receipts, password resets, and security alerts are transactional and must still reach the user; newsletters and promos are marketing and must honor unsubscribes.
3. For mail that sits in the middle, like onboarding tips, add an unsubscribe link even though you could argue it is transactional. The spam-folder cost of a complaint dwarfs the cost of one lost subscriber. Docs: https://resend.com/docs/knowledge-base/should-i-add-an-unsubscribe-link
4. Scope unsubscribes by topic where you can. A user who unsubscribes from the newsletter should keep receiving product announcements unless they opt out of those too; contact topics give you that granularity.
5. Never implement unsubscribe by deleting the contact. Deleting loses the opt-out record, and a re-imported address starts receiving mail again. Update the contact or the topic preference instead.
6. When a marketing unsubscribe arrives, also check the suppression list state. An unsubscribe stops your broadcasts; a complaint or bounce stops everything at the Resend level. Your code must respect both.
7. Test the footer in staging by sending to yourself and clicking through. A placeholder that renders literally in the received mail means the send path did not process it, and real users will see the raw text.

## When to use this

- This covers exactly what the title says: Add unsubscribe handling to Resend transactional mail the right way.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Add; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.

## Compatibility

- Not pinned to a specific version; follows current Add behavior.

## Edge cases

- A user who unsubscribes from the newsletter should keep receiving product announcements unless they opt out of those too; contact topics give you that granularity.