On this page
What counts as transactional email
Transactional messages are triggered by something a person did or needs to know about: a one-time password, a password reset, an order confirmation, a receipt, a shipping update, a security alert, an account notice. They are expected, usually awaited, and often time-critical. A login code that arrives after ten minutes has, for practical purposes, failed.
Because they are expected, transactional messages normally enjoy good engagement and a strong reputation. The risk is letting them share infrastructure with marketing mail, where a campaign that draws complaints or bounces can drag both down together.
Warning signs
- Users report OTPs or reset emails arriving late or landing in spam.
- Transactional delivery slows down whenever a newsletter goes out.
- Your application sends mail from the web server’s local mail function with no authentication.
- Nobody can say how long a password reset takes to arrive.
- Receipts and newsletters come from the same address and the same IP.
What’s included
- A dedicated transactional subdomain, for example a notifications or accounts subdomain, separate from the one used for marketing.
- A separate sending path: its own IP or IP pool, its own configuration set, or its own provider account, depending on your setup.
- Full authentication with SPF, DKIM and DMARC aligned on that subdomain.
- API or SMTP integration with your application, using individual credentials and retries on temporary failure.
- Event handling so bounces and complaints are recorded against the user account, not just the mailing platform.
- Latency monitoring that measures how long critical messages take to reach test inboxes.
- Templates with a clear plain-text version and consistent sender identity.
How we deliver it
- List every message your system sends and classify it as transactional or marketing.
- Choose the sending path: a cloud platform, your own SMTP server or a Postal instance.
- Set up the subdomain, authentication and reverse DNS where applicable.
- Integrate with your application, adding sensible timeouts, retries and logging of message IDs.
- Wire delivery, bounce and complaint events back to your application.
- Test each message type end to end with major providers and measure arrival time.
- Set alerts for failures, delays and rising bounce rates, and document the setup.
Keeping transactional mail transactional
It is tempting to add promotional content to receipts and notifications because they are well read. Doing so risks the message being treated as marketing, both by mailbox providers and under laws such as CAN-SPAM, which distinguish transactional from commercial messages. A light, relevant touch is fine; a full promotion belongs in your marketing stream, with its unsubscribe.
Tools and standards
We commonly use Amazon SES configuration sets, Postfix with a dedicated transport, or Postal with a separate IP pool. TLS is enforced where possible, and MTA-STS can be published on the domain. Reputation for the subdomain is tracked in Google Postmaster Tools. See cloud email sending setup and SMTP server setup for the platform side.
What affects timeline and cost
- Number of message types and applications sending them.
- How easy your application is to change, and who makes the code changes.
- Whether an existing provider is kept or replaced.
- Depth of latency and failure monitoring required.
- Template redesign, if needed.
Common mistakes
Sending OTPs through the same queue as a newsletter. Using a no-reply address that bounces replies from confused customers. No retries in the application, so a brief provider error loses the message. Ignoring bounces, so the app keeps emailing a dead address and never tells the user. Long queue lifetimes that deliver expired codes hours later.
More in our email infrastructure guide and across our email infrastructure services. Or contact us.
Frequently asked questions
Why separate transactional and marketing email?
So a problem with one can’t affect the other. Separate subdomains and sending paths keep critical messages on a reputation built only from mail people expect.
Should OTPs use SMTP or an API?
Either works. APIs often give clearer error handling and message IDs, while SMTP is simpler to plug into existing software. We choose based on your application.
Do transactional emails need an unsubscribe link?
Genuinely transactional messages usually don’t, but anything promotional does. We help you draw that line clearly.
How do you measure delivery speed?
We send test messages to monitored inboxes at major providers and record the time from sending to arrival, alerting when it rises.
Can we keep our current provider?
Often yes. Many improvements are configuration changes: a separate subdomain, event handling and monitoring. We only suggest moving when there is a clear reason.
Talk to us about transactional email setup
Receipts, OTPs and alerts on a separate, protected path so marketing can't break them.