Transactional emails are the most critical emails your business sends — failed delivery means a blocked user, a missed order, or a confused customer. This guide covers best practices across infrastructure, content design, monitoring, and error handling to ensure your transactional emails arrive reliably, every time.
1. Infrastructure Best Practices
| Practice | Why It Matters |
|---|---|
| Use a dedicated sending subdomain | Separate mail.yourcompany.com for transactional from newsletter.yourcompany.com for marketing. A spam complaint spike from a marketing campaign never harms transactional deliverability. |
| Publish and maintain SPF, DKIM, and DMARC | Authentication is non-negotiable for transactional email. Gmail, Outlook, and Yahoo all require it. Unauthenticated transactional emails go to spam regardless of content quality. |
| Use a dedicated SMTP account per application | One application's sending issues do not affect another. Credential rotation for one app does not require updating all apps. |
| Store credentials in environment variables | Never hard-code SMTP credentials in your source code. Use environment variables or a secrets manager in all environments. |
| Use connection pooling for high-volume apps | Reusing SMTP connections rather than opening a new connection per email significantly reduces latency and server load at high sending rates. |
2. Speed — The Critical Factor for Transactional Email
Transactional emails must arrive within seconds of the triggering event. Users who do not receive an OTP within 60 seconds will abandon the flow. Here is how to maximise delivery speed:
- Send asynchronously — do not block your web response waiting for the SMTP connection to complete. Queue the email send in a background job and return the HTTP response to the user immediately.
- Use a job queue (Redis, RabbitMQ, AWS SQS) for email sending — this decouples email delivery from your request/response cycle and provides automatic retry on failure.
- Pre-open SMTP connections — for high-frequency transactional sending, maintain a persistent pool of authenticated SMTP connections rather than opening a fresh one for each email.
- Use the Email API instead of SMTP for speed-critical emails — the REST API avoids SMTP handshake overhead and can be faster for OTPs and password resets.
3. Email Design Best Practices for Transactional
| Design Principle | Guidance |
|---|---|
| Clarity above all else | The recipient must understand the email's purpose within 2 seconds of opening it. State the key information (OTP, order number, reset link) prominently at the top. |
| Keep it simple | A transactional email does not need complex design. A clean single-column layout, your logo, the key message, and a clear CTA button is sufficient and loads faster. |
| Large, tappable CTA buttons | Password reset and email verification emails are primarily opened on mobile. Buttons must be at least 44px tall with sufficient padding so they are easy to tap. |
| Include a fallback text link | Below every button, include the URL as a plain text link: "If the button does not work, copy this link: [URL]". Some email clients block buttons. |
| Set OTP expiry clearly | Always state when a code or link expires: "This code is valid for 10 minutes." Reduces support tickets and user frustration. |
| Always include a plain-text version | Some email clients render only plain text; a missing plain-text version can cause the email to be marked as spam by filters that penalise HTML-only emails. |
| Keep total size under 50 KB | Transactional emails should be lighter than marketing emails. A 10–30 KB email loads instantly on any connection. Avoid large embedded images. |
4. Monitoring and Alerting
For transactional email, a delivery failure is a customer-facing incident. Set up monitoring to detect failures before your users report them:
- Subscribe to delivery webhooks — configure MigoSMTP to send
email.bounced,email.deferred, andemail.complainedevents to your webhook endpoint. Process these events in real time in your application. - Alert on bounce spikes — if your bounce rate for transactional emails exceeds 1% in a 1-hour window, trigger an alert to your engineering team.
- Monitor delivery rate — set a delivery rate alert in MigoSMTP (Dashboard → My Alerts) to notify you if the overall delivery rate drops below 98%.
- Track time-to-delivery for critical emails — for OTPs and password resets, log the time between send and delivery confirmation (via webhook) in your application metrics. Alert if average delivery time exceeds 30 seconds.
- Set up an end-to-end delivery test — periodically (e.g. every 15 minutes) send a canary test email to a monitored mailbox and verify it arrives. Alert if it does not arrive within 2 minutes.
5. Error Handling and Retry Logic
| Error Type | Recommended Response |
|---|---|
| SMTP connection timeout | Retry immediately (once); if second attempt fails, switch to the Email API as a fallback; alert engineering team |
| Authentication failed (535) | Do not retry — credentials are wrong. Alert immediately. Do not queue further sends until credentials are fixed. |
| Quota exceeded (402) | Alert immediately — transactional email quota exhaustion is a P1 incident. Upgrade plan or use wallet top-up without delay. |
| Server error (5xx) | Retry with exponential backoff — 10s, 30s, 2min, 10min. After 4 retries, dead-letter the message and alert. |
| Soft bounce (via webhook) | MigoSMTP retries automatically. No action needed unless retries exhaust — then surface the issue to the user (e.g. ask them to check their email address). |
| Hard bounce (via webhook) | Mark the email address as invalid in your database immediately. Do not retry. Surface an error to the user asking them to update their email address. |
6. Unsubscribe and Preference Handling
Transactional emails technically do not require an unsubscribe link — but following these practices reduces spam complaints:
- Add an email preferences link (rather than a full unsubscribe) that lets users control which notification types they receive without opting out of critical emails entirely.
- Never allow users to opt out of security-critical transactional emails (OTPs, password resets, account compromise alerts). These must always deliver.
- For less critical transactional emails (order status updates, renewal reminders), allow users to opt out and honour the preference immediately.