Do transactional emails need an unsubscribe link? The Gmail and Yahoo rules, applied to application mail
The 2024 Gmail and Yahoo sender requirements made one-click unsubscribe mandatory for bulk senders, and left developers unsure whether a password reset now needs an opt-out. It does not, but the reasoning matters, and the other requirements apply to every message you send.
No. The Gmail and Yahoo one-click unsubscribe requirement applies to marketing and subscribed messages, and a receipt, password reset or security alert is neither. Notification mail a user could reasonably stop wanting, such as digests, is subscribed mail and should carry it. The authentication, alignment and 0.3% complaint-rate rules apply to every message.
In February 2024, Gmail and Yahoo began enforcing a shared set of requirements for anyone sending them more than 5,000 messages a day. Most of the list was hygiene the industry had been recommending for a decade: authenticate, align, keep complaints down. One item was new enough to cause confusion, and it is still causing it: one-click unsubscribe is mandatory.
Developers read that and asked a reasonable question. Does a password reset now need an unsubscribe link? A receipt? A login alert?
The short answer
No. Both receivers scope the unsubscribe requirement to marketing and subscribed messages. Transactional mail, a message one person triggered and is expecting, is explicitly outside it. Nobody subscribed to their own password reset, and giving them a button to stop receiving security alerts would make the alerts worse at their one job.
The confusion comes from the word bulk. The requirements apply to bulk senders, meaning anyone over the volume threshold, but the unsubscribe rule within them applies to a category of message. A sender can be over the threshold and send nothing that needs the header.
The longer answer: what counts as subscribed
The line is not always where developers draw it. Ask of each message type: would a reasonable user want to stop receiving this, without stopping using the product?
| Message | Needs one-click unsubscribe? | Why |
|---|---|---|
| Password reset, magic link, OTP | No | Requested, single-use, security-critical |
| Receipt, invoice, order confirmation | No | Record of a transaction the user made |
| Security alert, new device login | No | Stopping these harms the user |
| Comment reply, mention notification | Yes | A preference, and one people turn off |
| Daily or weekly digest | Yes | Subscribed by definition, however useful |
| “Your trial ends in 3 days” | Yes | Lifecycle marketing, whatever the template is called |
| Product update, new feature announcement | Yes | Marketing |
The bottom four rows are where applications get it wrong, because they are sent by the same code path as receipts and the team thinks of them as “notifications”. A receiver does not see your code path. It sees a message a user might want to stop, with no way to stop it, and the user finds the one button that is always there: report spam.
That is the practical reason the rule exists. An unsubscribe button is a lightning rod. When it is present, disinterest goes there. When it is absent, disinterest becomes a complaint, and complaints are the metric that gets a sender filtered.
The rules that apply to every message
The unsubscribe header is the one exception. Everything else in the requirements applies to a password reset exactly as it applies to a newsletter:
- SPF and DKIM must pass. Both, on every message.
- DMARC must be published, at minimum
p=none, and the message must align. This is the requirement that catches most transactional senders, because alignment fails silently when a provider signs with its own domain. - Forward-confirmed reverse DNS on the sending IP.
- TLS on the connection.
- Spam complaint rate under 0.3%, and both receivers say to aim under 0.1%. Gmail measures this per sending domain, and it is the number that decides whether your mail is filtered.
A transactional sender who has never sent a marketing message can still fail on any of the first four, and the fifth applies to them just as much: a security alert nobody understands gets reported as spam like anything else.
Doing the header properly when you do need it
When a message does need one-click unsubscribe, the implementation is two headers, not a footer link:
List-Unsubscribe: <https://yourapp.com/unsub/8f3a...>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickThe URL must accept an HTTP POST with no authentication step, no confirmation page, no “are you sure”. The mail client sends the POST when the user clicks the button the client draws, and the user expects nothing more to happen. Process the request within two days, and stop that message type for that address, not everything, which is a good reason to make the token in the URL identify the stream as well as the recipient.
Keep the footer link too. It serves users whose client does not draw the button, and it is where a person looks first.
Separate the streams
If one thing from this post changes your setup, make it this: send transactional and subscribed mail from different subdomains. mail.yourapp.com for the receipts and resets, news.yourapp.com or updates.yourapp.com for the rest.
Complaint rate, the metric above, attaches to the sending domain. When one campaign goes badly, the reset emails on the same domain go to spam with it. Separate domains mean separate reputations, separate DMARC reports, and a clean answer to “which of our mail carries the header”: the one on the domain that needs it.
Where Pharos fits
Pharos is built for the top half of the table: mail a person triggered and is waiting for. It authenticates and aligns every message, sends over TLS from IPs with forward-confirmed reverse DNS, and holds every account to a complaint rate below 0.1%, the number the receivers publish as the target. The acceptable use policy asks you to send subscribed mail from somewhere else, for the reason in the previous section.
Questions this raises
What exactly is one-click unsubscribe?
Two headers on the message. List-Unsubscribe carries an HTTPS URL, and List-Unsubscribe-Post carries the fixed value List-Unsubscribe=One-Click. A mail client that shows an unsubscribe button POSTs to that URL when the user clicks it, and the request must be honoured within two days. A link in the footer is not this, though it is still good to have.
Does the 5,000 messages a day threshold mean small senders are exempt?
From the unsubscribe and DMARC record requirements, technically. Not from the complaint rate, and not from receivers weighting authentication in practice. Treating the bulk-sender rules as the baseline for every sender is the cheaper path, because the day you cross the threshold is not a day you will notice.
Can I send transactional and marketing mail from the same domain?
You can, and you should not. Complaints attach to the sending domain, and a promotional campaign's complaint rate becomes the password reset's complaint rate. Use separate subdomains, so each stream carries its own reputation and its own headers.
Sources
Know when the rules change.
Gmail, Yahoo and Microsoft change what they require from senders. Pharos changes too — a capability, a limit, a price, something retired. Both change what you have to do to keep sending, so this list sends one email when either happens.
check your email
Confirm from the email we just sent, and you're on the list.