Transactional email is a one-to-one email sent in response to a user action: signup confirmation, password reset, receipt, magic link, invoice, shipping update.
Transactional email is email triggered by an application event and sent to a single recipient. The triggering event is an action that user just took: creating an account, submitting a payment, requesting a password reset, completing a purchase.
This is the opposite of marketing email, which is sent to a list of people (with consent) and is not directly caused by any individual action.
Regulatory: transactional email is exempt from many CAN-SPAM and GDPR marketing rules because it's not promotional. You still have to follow general deliverability and anti-spam rules.
Deliverability: transactional is time-sensitive (users wait for that password reset). It typically runs on isolated 'hot' sending infrastructure with aggressive retry logic.
Engagement profile: transactional opens hit 80%+, marketing opens hit 20-40%. Inbox providers treat these as fundamentally different streams.
Infrastructure: most serious email platforms separate transactional and marketing sends onto different IPs and different domains to protect each stream's reputation.
Sub-200ms API response for queued delivery.
SPF, DKIM, DMARC configured at onboarding.
Webhook events: sent, delivered, opened, clicked, bounced, complained, unsubscribed, failed. Signed, retried, idempotent.
Template rendering with variables (Handlebars or Mustache).
Bounce and complaint handling with auto-suppression.
Dedicated IPs (above roughly 500K sends/month).
Clean logs you can search by message ID, recipient, or event.
Full transactional API at `https://api.nitrosend.com/v1/my/messages`. See the transactional email API page for REST, Node SDK, Python, and MCP examples.
Transactional and marketing run on separate deliverability-isolated infrastructure. Your receipts don't live on the same IPs as your weekly newsletter.
BYO support: route through Amazon SES, Resend, Postmark, Mailgun, or SendGrid on Pro and above. Same platform, your sending reputation.
Transactional is triggered by one user's action and sent to one person (password reset, receipt). Marketing is sent to a list with consent-based targeting (newsletter, product announcement). They typically run on separate sending infrastructure.
Yes, strictly speaking. Good email platforms do this automatically (transactional and marketing on different IPs, different domains, different reputation histories). If you use one provider for both without separation, a bad marketing send can damage transactional deliverability.
Technically yes, practically no. Transactional infrastructure expects the 80%+ engagement rate transactional gets. Sending marketing through it pollutes the reputation and eventually breaks both.
SMTP is the protocol; an API is a service built on top. APIs add templating, webhooks, analytics, retries, bounce handling, authentication setup, and better debugging. Raw SMTP works but you end up building the rest yourself.