What is transactional email?

Transactional email is mail an application sends to one person because that person did something. A receipt after a payment. A password reset after clicking “forgot password”. A confirmation after a booking. An alert when a threshold is crossed. The defining property is not the content — it is that a specific recipient caused a specific message, and is usually waiting for it.

That is the whole distinction, and it has consequences.

How it differs from bulk email

Bulk or marketing email is sent to many people at a time because the sender decided to send it. Transactional email is sent to one person at a time because that person triggered it. Everything else follows from that difference.

The consent difference is the one people get wrong. A password reset needs no opt-in because the recipient asked for it thirty seconds ago. A newsletter needs one. Mail that mixes the two — an order confirmation with a promotion stapled to the bottom — is treated as marketing by most regulators and by most receivers.

Why it is filtered differently

It usually is not. Receiving mail servers do not have a “transactional” flag to check, and there is no header that grants exemption. A password reset passes through the same filters as a newsletter, from the same reputation systems, judged by the same signals.

What is different is the cost of getting it wrong. If a marketing message lands in spam, an open rate drops. If a password reset lands in spam, a person cannot log in, and the first thing you hear is a support ticket that does not mention email at all.

So the engineering standard for transactional mail is higher even though the filtering standard is identical. The mail has to arrive within seconds, every time, and you need to be able to prove what happened to any individual message when someone says they never got it.

What it needs from infrastructure

Four things, in rough order of how often they are the cause of a problem:

1. Authentication that aligns. SPF and DKIM both passing is not enough. DMARC alignment is the check that decides whether the authenticated identity matches the address the recipient sees, and it is the one that quietly fails.
2. Sending infrastructure that looks legitimate. Forward-confirmed reverse DNS on the sending IP, a valid TLS certificate, a hostname that resolves. Receivers weight this heavily and never tell you when it is the reason.
3. Speed. A reset email that arrives in four minutes has already failed. Queue depth matters more here than in any other kind of sending.
4. A per-message record. Not aggregate statistics. When one customer says the email never arrived, you need to know what happened to that one message, including which server accepted it and what it said.

What counts, and what does not

Mail a recipient caused or would expect:

• Receipts, invoices, order and shipping confirmations
• Password resets, email verification, magic links, one-time codes
• Security notices — new device sign-in, password changed, key rotated
• Alerts a user configured, and system notifications about their own account
• Replies from a support system to a ticket the person opened

Mail a recipient did not cause, whatever it is called internally:

• Newsletters, product announcements, feature launches
• Re-engagement, win-back and abandoned-cart sequences
• Anything to an address that did not ask for it

The line matters practically, not just legally: a provider built for one-at-a-time mail and a provider built for campaign sends optimise for different things, and sending bulk mail through a transactional path — or the reverse — usually ends with a reputation problem that is hard to attribute.

Pharos is built for the first column. The acceptable use policy says where the line falls in practice.