Notify
Sign in

Transactional Email Best Practices

Best practices for transactional email with Notify — subjects, preheaders, From/reply-to, DNS, plain text, observability, and security.

Transactional email — password resets, receipts, alerts — should be reliable, clear in the inbox, and easy to debug. These practices apply when sending with Notify’s POST /api/email/send endpoint.

For the long-form 2026 guide (meta, content UX, checklist, provider choice): Transactional email best practices for developers.

Inbox meta

Subject lines

  • Keep them clear and around 50 characters or fewer
  • Put the most important information first
  • Avoid spam trigger words and ALL CAPS
  • Prefer useful over cute; enable keyword filtering (Receipt —, Security alert —)

Preheaders

Email clients show preview text after the subject. Start the HTML with a meaningful line (often visually hidden) so previews aren’t logo alt text or “View in browser.”

From and reply-to

  • Send from a verified domain
  • Use a recognizable display name (product/company users know)
  • Prefer monitored inboxes or reply-to over bare noreply@ for account/billing mail
  • Consider separate addresses (billing@, security@) so recipients can filter
  • Keep marketing on a different domain/subdomain than transactional

Authentication

Set up SPF, DKIM, and DMARC through domain verification. Primer: SPF, DKIM, DMARC explained.

Content

Message body

  • One primary action or piece of information per email
  • Use plain text when formatting isn’t needed; when using HTML, include a sensible text equivalent when you can
  • Use absolute dates/times for expiries (“expires 10 Aug 2026 16:00 UTC”), not “soon” or “a few moments ago”
  • Explain why the recipient got invites or rare account emails (who invited them, which product)
  • Don’t send empty digests

Mobile and frequency

  • Keep layouts single-column and tap-friendly
  • Streamline chrome on high-frequency notifications; fuller branding on receipts and security mail

Notification preferences

Mandatory for security/billing. Optional product alerts should link to a preference center — don’t let users unsubscribe from invoices by accident.

Types to implement: 12 transactional emails every SaaS should send.

Delivery

Verify your domain

Production sends from a custom from address require domain verification. Unverified domains are rejected. Use sandbox/test while DNS is pending.

Respect rate limits

Spread high-volume sends over time. Implement backoff on 429 responses. See Usage Limits.

Handle errors

Always check the API response:

const response = await fetch('https://notify.cx/api/email/send', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'x-api-key': process.env.NOTIFY_API_KEY!
  },
  body: JSON.stringify({
    to: 'recipient@example.com',
    subject: 'Hello world',
    message: 'Your email content here',
    from: 'Acme <noreply@your-verified-domain.com>'
  })
});

if (!response.ok) {
  const error = await response.json();
  // Log and handle: 400 invalid params, 401 bad key, 429 rate limit
  throw new Error(JSON.stringify(error));
}

const { data } = await response.json();
// Save data.messageId for log correlation

Observe

Check logs

After sending, verify delivery in dashboard logs. On the Free plan, logs are available for 48 hours; Pro and Scale include permanent history. Review by template type when you change copy.

Set up webhooks

On Pro and Scale plans, use webhooks to react to bounces and complaints — add addresses to your suppression list automatically.

Monitor key metrics

  • Delivery rate — should stay high (many teams aim above ~95%)
  • Bounce rate — keep well under ~5%; investigate spikes
  • Complaint rate — keep far under ~0.1%

Security

  • Store API keys in environment variables
  • Never call the Notify API from browser code
  • Regenerate compromised keys immediately
  • Keep email logs access restricted
  • Hash auth tokens; short TTL; single-use; rate-limit reset endpoints

Testing

Before production:

  1. Send a guided test from the dashboard checklist, or rehearse with the test API
  2. Verify plain text and HTML rendering and the inbox preheader
  3. Confirm delivery in logs
  4. Test error handling for invalid addresses and rate limits

Common pitfalls

  • Sending from an unverified domain
  • Mixing marketing and transactional reputation on one domain
  • Exceeding monthly or hourly limits without backoff
  • Ignoring bounces — repeated sends to bad addresses hurt reputation
  • Not saving messageId — makes log and webhook correlation harder
  • Relative times (“today”) that are wrong when the email is read later

Next steps