Transactional email
Mail your app sends to one person because they did something: receipts, password resets, invites. Expected, triggered, not a campaign.
See it
What it is
Transactional email is mail sent to exactly one person because that person did something: a receipt after checkout, a password reset link, an order shipped notice, a team invite. The recipient is expecting it, usually within seconds, and often cannot finish what they started without it. That expectation usually shows up in the numbers: mail people are waiting for gets opened, draws few complaints, and tends to place well. It is not an exemption, though. Filters still judge a receipt on reputation, content, and how recipients treat it, and there is no switch that marks a message transactional. The legal picture is the same shape: many consent regimes carve out messages that are strictly service related, but the carve-outs differ by jurisdiction and shrink the moment the message starts selling something.
Practically it means a different sending path from your campaigns: an API call from your app code (Resend, Postmark, SES, Sendgrid) rather than a scheduled blast from a campaign tool. Send it from its own subdomain, something like 'tx.example.com', so a rough marketing month cannot drag your password resets into the spam folder. Latency is a feature here: a reset link that lands in four minutes is a support ticket.
The gotcha is contamination. The moment you staple a 'while you're here, 20% off' block onto a receipt, filters and regulators start reading the whole message as marketing, and the recipient who reports it as spam is reporting your most critical mail stream. Keep the promo out, keep the streams separate, and never route transactional mail through the same domain reputation you are gambling with.
Ask AI for it
Wire up transactional email for this app using a provider API (Resend, Postmark, or SES) instead of raw SMTP from the web server. Send from a dedicated subdomain like tx.example.com with its own SPF, DKIM, and DMARC records, and keep it separate from any marketing stream. Queue sends in a background job so a slow provider never blocks a request, attach an idempotency key per event so a retried job cannot mail the same receipt twice, and build every message as multipart with both a plain-text and an HTML part. Set a Reply-To a human actually reads, keep promotional content out of these messages entirely, store the returned message ID on the related record, and ingest the provider's delivered, bounced, and complained webhooks so failures are visible instead of silent.