Home / Guides / Transactional Email Best Practices

Transactional Email Best Practices for Developers

How to send password resets, receipts, and notifications that actually reach the inbox. Practical advice for developers, not marketers.

Use a dedicated subdomain for transactional email

Never send transactional email from your root domain. Use a subdomain like mail.yourapp.com or notify.yourapp.com. This isolates your transactional reputation from marketing email and protects your root domain.

If your marketing emails get complaints, your password resets still land in the inbox.

Authenticate everything

Every transactional email should pass SPF, DKIM, and DMARC. This is non-negotiable. Without authentication, ISPs treat your email as suspicious.

RelayPost configures DKIM signing and SPF alignment automatically when you verify your domain. See our authentication guide for details.

Send immediately

Transactional emails are time-sensitive. A password reset that arrives 5 minutes late is a failed user experience. Aim for delivery within seconds:

  • Password resets and login codes: under 10 seconds
  • Order confirmations: under 30 seconds
  • Account notifications: under 1 minute

Use an email API with low latency rather than queuing transactional emails through a batch system.

Keep content simple and relevant

  • Use a clear, descriptive subject line: "Your password reset code" not "Action required"
  • Get to the point — the CTA or information should be visible without scrolling
  • Include both HTML and plain-text versions
  • Don't add marketing content to transactional emails — it dilutes trust and can trigger spam filters
  • Use a consistent From name and address so recipients recognize you

Handle bounces and complaints automatically

When an email bounces (invalid address) or a recipient complains (marks as spam), stop sending to that address immediately. Continuing to send to bad addresses damages your sender reputation.

RelayPost handles this automatically through suppression lists. Hard bounces and complaints are suppressed without manual intervention.

Monitor delivery metrics

Track these metrics for your transactional email:

  • Delivery rate — should be 99%+ for transactional email
  • Bounce rate — should be below 1% (transactional emails go to known addresses)
  • Time to delivery — measure p50 and p99 latency
  • Open rate — transactional emails typically see 60-80% open rates; a drop signals deliverability issues

Use webhooks to track delivery events in real time.

Use templates for consistency

Create reusable templates for each transactional email type. This ensures consistent branding, reduces errors, and makes updates easier. Store templates in your email provider rather than hardcoding HTML in your application code.

Frequently asked questions

What are transactional emails?

Transactional emails are triggered by a user action — password resets, order confirmations, account notifications, shipping updates, and login alerts. They're expected by the recipient and typically have high open rates.

Should transactional and marketing emails use the same domain?

No. Use separate subdomains — for example, mail.yourapp.com for transactional and news.yourapp.com for marketing. This isolates reputation so marketing complaints don't affect transactional delivery.

How fast should transactional emails be delivered?

Within seconds. Password resets and login codes should arrive in under 10 seconds. Order confirmations within 30 seconds. Any delay longer than a minute creates a poor user experience.

Do transactional emails need an unsubscribe link?

Legally, pure transactional emails (password resets, receipts) don't require an unsubscribe link under CAN-SPAM. However, Google and Yahoo now recommend one-click unsubscribe headers on all bulk email. For transactional email sent to individual recipients, it's not required.

Send transactional email that lands in the inbox

Automatic authentication, instant delivery, built-in suppression. Start free.

Get Started Free