Keep transactional mail transactional.

A transactional message exists because the recipient did something, or because the relationship needs a fact. It is not a pitch. This lesson draws that line, then shows when an unsubscribe link is required and what PostShiba does with one-click List-Unsubscribe.

What counts as transactional

Transactional mail is triggered by the user's own action, or by a fact they need about a relationship they already have. The test is simple. Did they do something that created this message, and does the message carry information they need to finish that action or keep the account working?

These count.

A password reset after they asked for one. A receipt or invoice after they paid. A 2FA code so they can sign in. An order or shipping update for something they bought. A confirmation that they changed an email address, a password, or a billing method. A security alert that a new device signed in.

The mail is about their action or their account. It would be a problem if it never arrived. They are not being sold to.

A comment notification can still sit here when the recipient turned the setting on and the body only reports the comment. The categories lesson covers that grey zone. If the message is only a fact they asked to hear, treat it as transactional.

What does not

Bulk is mail you decided to send, on your schedule, to a list. A product newsletter. A feature announcement. A win-back campaign. A "we miss you" note to people who have not signed in. A sale. A survey that is not required to use the product.

The recipient may have opted in months ago. They did not ask for this exact message today. If they never open it, their account still works. That is the tell.

Volume and one-to-one delivery do not change the category. A campaign sent to one address at a time is still a campaign. A receipt sent to 10,000 buyers in an hour is still a receipt.

Automations that drift

The quiet failures are automations that start as facts and turn into marketing.

A trial nudge is the usual one. "Your trial ends in three days" can be a fact they need if the body only states the date and how to keep the account. "Your trial ends in three days, and here is 20% off annual" is a pitch. The discount is why you sent it.

"We miss you" is bulk on the first send. So is "You have not used this feature yet." So is a product announcement dressed as a digest. The person did not ask for a tour. You decided they should take one.

Onboarding drifts the same way. Email one, "You created an account", is transactional. Email two, "Confirm this address", is transactional. Email four, "Have you tried our new report?", is a product announcement. Put the first facts on the transactional cluster. Put the later nudges on bulk, with a way to opt out.

If you have to argue that the message is transactional, it is not. Send it on the bulk cluster.

When you need an unsubscribe link

Marketing mail must offer a way to opt out under laws like CAN-SPAM in the US and similar rules elsewhere. Gmail and Yahoo also require bulk senders to support one-click unsubscribe. This is not legal advice.

Transactional mail that is only a fact the recipient needs, triggered by their action or the relationship, does not take an unsubscribe link. A reset code with an unsubscribe button looks like a campaign, and some people will click it. Then they stop getting receipts.

You need a way out when the message is promotional, when it is sent to a list on your schedule, or when it would still make sense if the person never opened it. Trial nudges with offers, win-back campaigns, newsletters, and product announcements all need it.

Judge a few examples below. Decide whether each one needs an unsubscribe link.

If a message is mixed, treat the whole thing as marketing. A receipt with a promo banner needs a way out, and it should not have been mixed in the first place. Split the send. Keep the receipt clean.

One-click List-Unsubscribe

One-click unsubscribe is a pair of headers, List-Unsubscribe and List-Unsubscribe-Post. Mail apps that honor them show an Unsubscribe button next to the sender. The person does not have to scroll to a footer or load a landing page first. A click from the mail app opts them out immediately.

Gmail and Yahoo ask bulk senders to support that path. A footer link alone is not the one-click header. You can still put a link in the body. The header is what the mail app uses.

Do not add these headers to a password reset or a 2FA code. The recipient is in the middle of signing in. An unsubscribe button on that message is the wrong control.

How PostShiba handles it

PostShiba adds the headers for you on a bulk cluster when all of these are true: the message has exactly one recipient, and you have not set List-Unsubscribe or List-Unsubscribe-Post yourself. Transactional clusters never get the header.

If you set your own header, PostShiba leaves both alone and your handling applies. To also put a link in the body on messages that get the one-click header, send X-Include-Unsubscribe: true. PostShiba removes that header before delivery.

When a recipient uses the one-click path, PostShiba suppresses that address on the sending tenant. The row lands on the suppression list with the reason Unsubscribe. Later sends from that tenant skip the address and list it in suppressed. You also get an unsubscribe event on the cluster and on any webhook that subscribes to it.

Plus tags are ignored when matching, so user+promo@example.com matches user@example.com. A one-click unsubscribe on news.example.com under tenant acme-florist does not suppress the same person on a different tenant.

Keep the streams honest. Transactional clusters stay transactional. Bulk clusters carry the campaigns, the headers, and the opt-outs. Pick your sending subdomains so a complaint on the newsletter host does not sit on the same From domain as the password reset.