Transactional Email Best Practices: Getting Receipts and Alerts to the Inbox

Transactional Email Is Different—Treat It That Way

A transactional email is triggered by a user action: a password reset, an order confirmation, a shipping notification, an account alert. The recipient expects it and wants it. That expectation creates a trust advantage that marketing email doesn't have—but it also creates a higher standard. When a password reset doesn't arrive, a user is locked out. When an order confirmation goes to spam, a customer thinks their purchase failed. The stakes for reliable inbox placement are high.

Despite the expectation advantage, transactional email routinely ends up in spam—usually because it's sent from the same infrastructure and domain as marketing mail, or because basic configuration details are overlooked. This guide covers the practices that keep transactional email consistently reaching the inbox.

Separate Transactional From Marketing Mail

The most important structural decision is to send transactional and marketing email from different subdomains and, where possible, different IP addresses. The reasons:

• Marketing campaigns drive spam complaints—recipients unsubscribe or hit "report spam" at higher rates than with transactional mail
• Complaint spikes from a campaign shouldn't penalize the reputation of your receipts and alerts
• Separating the streams lets you monitor metrics independently—you want to know if password resets specifically are getting deferred, not have that signal buried in campaign data

A clean setup uses mail.yourdomain.com (or notifications.yourdomain.com) as the sending subdomain for transactional, with its own DKIM key and dedicated IP. Marketing goes out from news.yourdomain.com or through a separate ESP.

Authentication Is Non-Negotiable

Every transactional sending domain needs proper SPF, DKIM, and DMARC. More specifically:

• SPF must cover the IPs used by your transactional relay
• DKIM should use a 2048-bit key, and the signing domain should match the From address domain (aligned signing for DMARC)
• DMARC on transactional subdomains should be at p=quarantine or p=reject—given that these messages are security-sensitive (password resets, payment confirmations), you don't want anyone spoofing them

Aligned DKIM signing is especially important for transactional mail. The domain in the d= tag of the DKIM signature should match the domain in the From header—not a third-party sender's domain. Many SMTP relay setups sign with their own domain by default; configure custom domain signing so DMARC alignment works correctly.

From Address and Reply-To

Use a real, monitorable From address for transactional mail. no-reply@yourdomain.com is common but counterproductive for several reasons:

• It signals to spam filters that engagement (replies) isn't expected, which is a weak negative signal
• Users who try to reply to report a problem get a bounce or a void—bad experience
• Some spam filter heuristics flag no-reply addresses as lower-quality senders

Use a real address like notifications@yourdomain.com with a Reply-To header pointing to your support inbox if you want replies handled separately. This gives users a way to respond while routing replies where they need to go.

Send Promptly and At the Right Volume

Transactional messages should be sent within seconds of the triggering event—not batched. Batching transactional mail misses the window of user intent and erodes the "expected" quality that makes transactional email easier to place in the inbox.

At the same time, a sudden spike in transactional volume (a flash sale that generates 100,000 order confirmations in an hour) can trigger the same throttling as any other volume spike. If you anticipate bursts, use a relay with a deep send queue and request queue handling so messages are delivered as fast as the receiving provider allows without triggering rate limits that cause deferrals.

Message Structure That Helps Deliverability

Transactional messages work best when they're clean and focused:

• Send both HTML and plain-text parts (multipart/alternative). A missing plain-text part is a minor spam signal and also means users with text-only clients get nothing.
• Keep the HTML simple—transactional messages don't need elaborate templates. A single-column layout with a clear action button outperforms complex designs and generates fewer rendering problems on older clients.
• Keep images minimal. Password resets and alerts don't need a header image. Reducing image weight improves load time and reduces the chance the message is clipped by Gmail.
• Include a clear unsubscribe option for notification-type emails (not required for strictly transactional like password resets, but good practice for shipping and order updates).

Monitor Bounce and Complaint Rates per Message Type

The most useful deliverability metric for transactional email is bounce rate by message type. If your password reset emails are hard-bouncing at 5% but your order confirmations are bouncing at 0.2%, that tells you the issue is your user account data, not your infrastructure. Breaking out metrics by email type is only possible if you tag each message type distinctly in your relay's event tracking.

Set up webhook notifications for bounces and complaints so your application can handle them in real time: suppress bounced addresses, remove complainers, and alert your team when rates exceed thresholds. A transactional relay that exposes per-event webhooks makes this straightforward to implement.

Test Before Every Deploy

Test transactional emails the same way you test code: before every deploy that touches email templates or sending logic. Specifically check:

1. Does the message render correctly in Gmail, Outlook, and Apple Mail?
2. Are the links correct and do they resolve to the intended destinations?
3. Does the plain-text part match the HTML content?
4. Is DKIM signing present in the headers (check DKIM-Signature and Authentication-Results)?

If you're setting up or migrating transactional sending infrastructure, MailDog's mail service handles DKIM signing, bounce tracking, and delivery webhooks out of the box. The documentation covers integration for common frameworks and languages. For configuration details on SMTP ports and relay setup, see SMTP ports explained.