Transactional Email Rules

A transactional email exists because the user took an action and needs confirmation or information about it — it is infrastructure, not a marketing opportunity, and every rule here follows from protecting that trust and the deliverability it depends on.

Transactional vs marketing separation

• Send transactional email (receipts, password resets, shipping notifications, security alerts) through a separate sending domain or subdomain and a separate stream/IP pool from marketing email — mixing them means a marketing sender-reputation problem (spam complaints, bulk unsubscribes) can delay or block critical transactional mail like password resets.
• Never require or imply marketing consent for transactional email — a password reset or order receipt must send regardless of the user's marketing opt-in status, since it's fulfilling a direct action they took, not campaign email under opt-in rules.
• Track deliverability metrics (bounce rate, spam complaints) separately per stream — a marketing campaign's poor metrics should never be able to affect the reputation of the transactional stream sharing the same infrastructure.

Immediate sending

• Send transactional email synchronously with (or within seconds of) the triggering action, not batched — a password reset or order confirmation that arrives minutes late defeats its purpose and generates support tickets asking "did this even work."
• Queue for reliable async delivery (not blocking the triggering request) but keep the queue's processing latency in the seconds range for transactional mail specifically — this isn't a marketing send that can tolerate an hour of batch-processing delay.

Subject = the fact

• State the fact plainly in the subject line ("Your order #4821 has shipped", "Reset your password", "Payment failed for invoice #99") — the user should know what happened without opening the email. This is the opposite of a marketing subject line, which exists specifically to create curiosity that requires opening.
• Never add marketing framing, emoji, or urgency language to a transactional subject — "🎉 Great news about your order!" for a shipping notification undermines the trust that makes users open transactional email reliably in the first place.

Essential info in the body, not behind a login

• Put the actual information the email exists to deliver directly in the email body (order total, tracking number, the specific error on a failed payment) rather than only a generic "log in to view details" — the user should get the answer without an extra step whenever the content isn't sensitive enough to require it.
• Reserve "log in to view" for genuinely sensitive content that shouldn't sit in an inbox indefinitely (full payment details, account security changes) — and even then, give enough summary in the body that the user knows why they're being asked to log in.

Deliverability basics

• Set up SPF, DKIM, and DMARC correctly for the sending domain before sending any production volume — without all three, transactional email lands in spam or gets rejected outright by major providers, regardless of content quality.
• Use a dedicated subdomain for transactional sending (e.g. mail. or notify.) rather than the bare root domain, so its sending reputation is isolated from the root domain's other email traffic.
• Monitor bounce and complaint rates continuously — a rising bounce rate on transactional mail usually signals a broken trigger (retrying a permanently-invalid address) rather than a content problem, and needs fixing at the source, not just suppressing.

No marketing smuggled into receipts

• Keep upsell content, promotions, or "you might also like" sections out of core transactional templates, or clearly and visually separate them below a hard line if the business genuinely wants to include them — a receipt whose primary content is upsell copy confuses the transactional purpose and risks provider spam classification.
• Never make the primary CTA of a transactional email a marketing action ("Shop now!") instead of the transactional one ("View your order", "Track your shipment") — the email exists to serve the action that triggered it first.

Plain-text fallback

• Always send a plain-text multipart/alternative version alongside the HTML version, not HTML-only — some clients render plain text by default, some strip HTML entirely for security screening, and a missing plain-text part is itself a deliverability signal some spam filters weight negatively.
• Make sure the plain-text version actually contains the essential information (order number, amount, the key fact), not just "please view this email in HTML" — a plain-text fallback that's functionally empty defeats the purpose of having one.