Know which mail you send.

Mailbox providers do not score a password reset the same way they score a product newsletter. One is mail the recipient asked for in the last minute. The other is mail they may ignore. This lesson names the three kinds of mail a product sends, why the scores differ, and how PostShiba keeps the streams on separate clusters.

Transactional, notification, and bulk

Most products send three shapes of mail, even when the code treats them as one send() call.

Transactional mail is triggered by the recipient's own action, or by a fact they need about an account they already have. A password reset after they clicked "Forgot password". A receipt after a purchase. A 2FA code so they can sign in. The person is waiting. They will look for the message. They will not mark it as spam.

Notification mail tells someone that something happened around them. A comment on a thread they follow. A mention. A shipping update they did not click just now. The recipient did not press a button ten seconds ago, but the mail is still about their work or their order. They expect it if they turned the setting on.

Bulk mail is sent to a list on your schedule. A product newsletter. A weekly digest you push to everyone. A win-back campaign to people who have not signed in. The recipient did not ask for this exact message today. They may have opted in months ago.

Sort a few examples below. The categories are the ones mailbox providers infer from how people treat the mail, not from the label in your job queue.

A 2FA code is transactional even if the template is named notify_login. A win-back campaign is bulk even if you send it one recipient at a time. The category follows the reader's expectation, not your function name.

Why mailbox providers treat them differently

Mailbox providers watch three things: expectation, engagement, and complaint rate.

Expectation is whether the person was waiting for the message. A reset code is expected. A "we miss you" email is not. Expected mail gets used, and it almost never gets a spam report. Unexpected mail is the opposite.

Engagement is what the recipient does next. They open the receipt. They copy the 2FA code. They ignore the fifth newsletter this week. Providers cannot see intent, but they can see that one stream is used and another is not. A stream that is never used looks like mail nobody asked for.

Complaint rate is the share of people who hit "This is spam". Transactional mail almost never earns that click. Bulk mail does, especially a list you have not touched in months. Providers weigh complaints far more heavily than a missed open. A small number of reports can pull a whole stream down.

That is why a password reset and a newsletter cannot share a reputation. The newsletter's complaints teach Gmail and Yahoo that mail from that IP and that From domain is unwanted. The next reset then arrives under that lesson.

The grey zone

Notifications, digests, and onboarding sequences sit between the two clean categories.

A comment notification is close to transactional when the recipient asked to be told, and the mail only reports the comment. It slides toward bulk when you batch ten comments into a "here is what you missed" pitch, or when the default is on for people who never chose it.

A weekly digest is a notification if each item is something the person already follows, and the mail is only a list. It is bulk if the digest is how you ship product news to the whole account list.

An onboarding sequence starts as transactional. "You created an account" and "Confirm this address" belong with the receipt. By email four, "Have you tried our new report?" is a product announcement. That is bulk. Keep the first facts on the transactional cluster. Put the later nudges on bulk.

If you are unsure, ask what happens if the person never opens it. If their account is broken, the mail is transactional. If they only miss a tip, it is not.

A mixed message is marketing

A receipt that ends with a promo banner is not a receipt in the reader's eyes. The order number is still there. The 20% off module is what they remember. Mailbox providers see the same thing: a message that looks like a campaign, from a stream that also sends password resets.

Do not bolt a newsletter onto a 2FA code. Do not add "while you wait, here are three features" under a password reset. Do not put a win-back offer in the shipping notification. Split the send. The receipt stays a receipt. The campaign goes out later, on the bulk cluster, to people who can opt out.

This is also how lists go bad. A person who wanted the receipt did not ask for the banner. Some of them will report the message. Those reports attach to the domain and the IP that sent the receipt.

Clusters never mix

PostShiba clusters are transactional or bulk. The type is locked after create. Receipts, password resets, and 2FA codes go on the transactional cluster. Campaigns, newsletters, and win-back mail go on the bulk cluster. Never put both on one cluster.

A bulk cluster also adds a one-click List-Unsubscribe header when the message has a single recipient and you have not set your own. Transactional clusters never get that header. That is the other reason to keep the streams apart: a reset must not show an unsubscribe button.

Complaints and unsubscribes on the bulk cluster stay on that cluster. They do not share an hourly cap, a sending environment, or a pool with the transactional cluster. A bad newsletter day does not touch the password resets.

Give each stream its own sending subdomain as well. Pick your sending subdomains is the setup step after you know which mail is which. Keep transactional mail transactional draws the header line: what still counts, and when you must offer a way out.