Transactional Email Best Practices: What Developers Get Wrong

Most developers think transactional email is a solved problem. You call an API, the email goes out, the user gets their password reset. Done.

Then I look at the actual emails our customers send, and the same gaps show up over and over. The send works. The email arrives. But it renders as a wall of broken HTML on a phone, or it has no plain-text version, or a hard bounce never gets suppressed and the sender reputation slowly rots.

The most common one I see is the simplest to fix. A receipt or a verification email that looks fine on a laptop and falls apart on mobile, with no plain-text part to fall back on. Most of your users open these on a phone. If the email breaks there, the email failed, even though your logs say it sent.

The transactional emails that quietly fail are not the ones that bounce. They are the ones that arrive, render badly, and never get read. That is the failure mode nobody monitors.

Here are the transactional email best practices I actually care about, in the order they matter. If you want the definition and the six core types first, start with what is a transactional email.

Authenticate before you send a single email

If SPF, DKIM, and DMARC are not set up, nothing else on this list matters. Your email is going to spam regardless of how good the content is.

This is the one setup step that fixes most deliverability problems before they start. Gmail and Yahoo now require authentication for anyone sending at volume, so this is no longer optional. I wrote a longer breakdown of how email spam filters actually score your messages, and authentication is the first signal every filter checks.

If you are sending from a fresh domain, warm it up before you push real volume through it. A cold domain sending thousands of password resets on day one looks exactly like a spammer. Here is how I warm up a new sending domain without tanking the reputation.

Always ship a plain-text version

This is the mistake I see most. Developers build an HTML email, test it once in their own inbox, and ship it. No plain-text part.

A plain-text fallback does two things. It renders for the small number of clients that strip HTML, and it improves your spam score, because a message with both an HTML and a plain-text part looks more like real mail and less like a template blasted out by a marketing tool.

Every transactional email you send should be multipart. HTML for the people who can see it, plain text for everyone and everything else. If you only have time to ship one version of a password reset email, ship the plain-text one. It will always render and it will always deliver.

Design for the phone first

Open your own order confirmation email on your phone. Then make every transactional email pass that test before it ships.

Most opens happen on mobile. A receipt with a fixed 600px table, tiny tap targets, and a button that runs off the edge of the screen is a bad receipt, even if it looks perfect on your monitor. Keep the layout single-column. Make buttons big enough to tap. Test dark mode, because a logo on a transparent background can vanish against a dark inbox.

You do not need a heavy framework for this. A simple, well-tested template that you reuse across every transactional email beats a custom layout per email type.

Send it fast

Timing is part of the product for transactional email. A password reset that takes four minutes to arrive feels broken. A verification code that lands after the user has already given up does not count as delivered.

These emails are triggered by a user action and the user is usually sitting there waiting. Send within seconds, not minutes. If your sending path runs through a slow queue or a batch job, move transactional sends onto a fast, separate path so a marketing campaign backlog can never delay a password reset.

Handle bounces with webhooks, not guesswork

If you are not listening to bounce events, you are flying blind. Every send eventually hits an address that does not exist or a mailbox that is full, and what you do next decides your sender reputation.

The rule is simple. Suppress hard bounces immediately and never send to that address again. Retry soft bounces a limited number of times, then suppress. I broke down the full logic in soft bounce vs hard bounce, including what your code should do for each event type.

Wire your webhook handler to update a suppression list automatically. Sending to a known-dead address a second time is the fastest way to look like a spammer to a mailbox provider. Keep an eye on the aggregate too, because a rising email bounce rate is usually a list-quality problem you can fix before it becomes a deliverability problem.

Keep transactional and marketing separate

Send your password resets and your weekly newsletter from the same domain and IP, and one bad campaign can drag your transactional deliverability down with it.

Separate them. Different subdomains at minimum. Your transactional stream should have a clean, narrow reputation that nothing else touches. A spike in marketing complaints should never be able to delay a receipt or a verification code.

Monitor what actually matters

For transactional email, the metric I watch is delivery, not opens. Did the email reach the inbox, and how fast. Open rates on transactional email are noisy and inflated, so I do not optimize against them.

Track bounce rate, delivery time, and complaint rate through webhook events rather than a dashboard you check once a week. Set an alert on bounce rate so you find out about a problem from your monitoring, not from a user tweeting that they never got their reset link. If you are not sure which numbers are worth watching, I covered that in how to read email metrics.

FAQ

What is the most important transactional email best practice? Authentication. Set up SPF, DKIM, and DMARC before anything else. Without it, every other best practice is wasted because your email lands in spam.

Do transactional emails need a plain-text version? Yes. Send every transactional email as multipart with both an HTML and a plain-text part. It improves rendering across clients and lowers your spam score.

How fast should a transactional email send? Within seconds. These emails are triggered by a user action and the user is usually waiting. Run transactional sends on a separate, fast path so marketing backlogs cannot delay them.

Can I send transactional and marketing email from the same domain? You can, but you should not. Separate them onto different subdomains so a marketing complaint spike cannot damage transactional deliverability.

What should I do with bounced transactional emails? Suppress hard bounces immediately and permanently. Retry soft bounces a few times, then suppress. Automate this through your bounce webhook so dead addresses never get a second send.

Should I track open rates on transactional email? Not as a primary metric. Open tracking is inflated and noisy. Watch delivery rate, delivery time, bounce rate, and complaint rate instead.

How we handle this at AutoSend

Every email AutoSend sends on its own behalf, the verification codes, the billing receipts, the alerts, goes out multipart with a plain-text part, on a separate transactional path, with a bounce webhook updating suppression automatically. We follow this checklist because we send our own transactional email through the same system our customers use.

AutoSend gives you a transactional email API with bounce webhooks, automatic suppression, and separate transactional and marketing sending built in, so most of this list is handled before you write a line of code.