How transactional email actually works

A transactional email is a message sent to one person in response to something they did: a password reset, a login code, an order confirmation. Almost every app and online store sends them, and they work differently from the marketing emails a company sends to its whole audience. The recipient is expecting a transactional message, which is why inbox providers and regulators treat the two kinds by separate rules, and why the same template can reach the inbox or land in spam.

What is transactional email?

A transactional email is sent in direct response to a user action: an order confirmation, a login code, a password reset, or a dunning notice. There's a one-to-one link between the action and the message, and the user is usually waiting for it.

Marketing emails work the other way around. The sender selects the audience, timing, and content, and pushes the message out in bulk to all contacts. No specific user action triggers any specific send.

This distinction matters because Gmail, spam filters, and privacy regulators all depend on it, so the same HTML template can behave very differently depending on its category.

Why inboxes treat them differently

It comes down to one thing: a transactional email is mail the recipient is actively expecting. The user just asked for the reset or placed the order, so it's wanted by definition. Marketing email arrives unrequested and has to earn its place in the inbox.

Recipients prove the point by opening transactional email 80–85% of the time, against 20–25% for marketing. Inbox providers like Gmail trust mail that people reliably open, which is part of why a well-run transactional stream lands in the inbox so consistently. Regulators follow the same logic: anti-spam laws target unwanted bulk mail, so a receipt under CAN-SPAM or a purchase confirmation under GDPR is largely exempt from the rules a promotion has to follow.

That extra trust is exactly what makes transactional email tempting to abuse. It reaches the inbox more reliably and carries fewer legal strings, so slipping a promotional banner into an order confirmation is an easy way to reach people who would ignore a normal campaign. That shortcut is where most deliverability problems start.

Mixing them makes you end up in spam

The key point is that the exemption applies only as long as the email is purely transactional. If you include enough promotional content, regulators and inbox providers stop viewing it as a transaction. For example, an order confirmation with a 30%-off coupon and three product recommendations is no longer just a receipt; it becomes a marketing email with a receipt attached. This means it must include the unsubscribe link, which a receipt normally does not require.

Gmail reaches the same conclusion more quickly and without warning. It analyzes the content, engagement, and sender reputation behind each message. A transactional template that appears promotional or shares infrastructure with campaigns can seriously harm your sender score. Once your domain reputation drops, it can take weeks of consistent, clean sending to recover.

The fix follows from the cause: keep each transactional template to a single purpose. When there's something to cross-sell, that's a separate marketing email, with its own opt-in and unsubscribe link.

Setting up the infrastructure

Because the recipient is waiting on it, a transactional email sits on the product's critical path, so a delivery failure is closer to an outage than a missed message. That's why the setup is worth getting right.

Domain authentication is the single biggest lever for deliverability, and it's the area most teams get wrong. Three DNS records do the work:

• SPF lists the IPs allowed to send for your domain. It tells receivers, "this server is authorized to send as me."
• DKIM signs each message with a private key. The receiver checks the signature against a public key in your DNS, proving the message wasn't tampered with in transit.
• DMARC ties SPF and DKIM together and tells receivers what to do when a message fails: quarantine, reject, or just report it. DMARC is the one most teams misconfigure: setting p=none and forgetting to ratchet it up to quarantine or reject leaves the policy effectively off.

With authentication in place, a few more practices keep the stream healthy:

• Separate your sending streams. Use different IPs, or at least different subdomains, for transactional and marketing email, so a spam complaint from a campaign can't drag your password resets down with it.
• Be selective about tracking. A tracking redirect on a password-reset link adds latency and can trigger phishing warnings, so disable tracking on security-sensitive emails and keep it for receipts and notifications where engagement data is useful.
• Test in a sandbox first. Sandbox keys exercise the full send path without spending quota or risking reputation, and wiring them into CI catches a regression before it reaches a real inbox.
• Manage suppressions and bounces. Suppress hard bounces and spam complaints permanently and retry only soft bounces on a backoff. A suppression list that grows faster than expected usually points to a problem upstream, like a signup form with no email validation.

FAQ

Bottom line

Transactional email earns trust by being exactly what the recipient asked for, and loses that trust the moment it tries to be anything more. Let each message do its one job well, and most of the rest tends to take care of itself.

Lettr's transactional email is built to handle that groundwork, from domain authentication to separate sending streams and per-message logs, whether you send over a drop-in SMTP relay or the API, so transactional email stays one less thing to run yourself.