What is transactional email? Examples and how it works

Click "Forgot password" and an email arrives a few seconds later. Buy something and a receipt turns up. Nobody typed those messages by hand and nobody scheduled them. Your action caused them. That's transactional email.

The short definition

Transactional email is a message an application sends to one person because of something that person did, or something that happened to their account. It's triggered by an event, addressed to an individual, and expected.

That last word matters. People wait for these messages. They check their inbox for the code. If it doesn't show up, they assume your product is broken.

Common examples

• Sign-up confirmation and email address verification
• One-time sign-in codes
• Password reset links
• Order confirmations, receipts and invoices
• Shipping and booking updates
• Security alerts, like a login from a new device
• Contact-form notifications sent to your own team
• Billing failures and subscription changes

Compare that with a newsletter, a product announcement or a discount code. Those are marketing messages. They go to a list, they're scheduled, and recipients can ignore them without consequence. Different rules apply to each kind, and keeping the two apart is one of the best things you can do for your sender reputation.

How your app sends it

There are two ways to hand a message to a mail service.

SMTP. Your app opens a connection to a mail server on port 587, logs in and transmits the message. Every language and framework can do this, which is why WordPress plugins, Laravel and PHPMailer all use it.

An HTTP API. Your app makes one authenticated POST request with a JSON body. There's no connection handling and the response tells you what happened. We show it in sending email from Node.js.

Either way, the message leaves your server, passes through a mail server that signs it, and travels to the recipient's provider. That provider decides whether it reaches the inbox.

What makes transactional email different to run

Delivery speed matters more than anything

A newsletter that arrives ten minutes late is fine. A login code that arrives ten minutes late is a failure. Transactional mail needs a path that isn't stuck behind a bulk send.

Reputation is shared and fragile

Mailbox providers score your domain on how people treat your mail. Password resets get opened and clicked at high rates, which is good for you. A burst of mail to old or invalid addresses is bad for you. If your sign-up form lets anyone trigger a message to any address, someone will abuse it, and the complaints land on your domain.

Authentication is not optional

Receivers check SPF, DKIM and DMARC. Without them, even a legitimate receipt can end up in spam. Start with what an SPF record is and what DKIM does.

Failure has to be visible

Some failures are the receiver's fault: a mistyped address, a full mailbox. Others are yours: a blocked sender, a revoked API key. You need to know which. A good API returns a clear error rather than silently dropping the message.

What a good transactional email looks like

• One purpose. A reset email resets a password. It doesn't also advertise your new feature.
• A clear subject. "Reset your password" beats "Important update".
• A plain text part and an HTML part. Text helps with filtering and with people who read mail without images.
• A recognisable sender. Use a consistent from name and address, such as Your App <[email protected]>.
• Short expiry on anything secret. Links and codes should stop working quickly.
• No tracking tricks. Skip link rewriting and hidden pixels in security emails. They look suspicious to filters and to people.

Do you need unsubscribe links?

Usually not for purely transactional messages, since people can't opt out of a receipt for something they bought. But rules differ by country and by exactly what the message contains, and adding marketing to a receipt can change how the law and mailbox providers see it. Keep the mail strictly about the transaction, and check the rules where your customers live.

Setting it up from your own domain

The path is the same whichever service you use:

1. Add your domain and publish its SPF, DKIM and DMARC records.
2. Verify them against live DNS.
3. Create an API key (or SMTP credentials) for that domain.
4. Send from an address on the domain.

Mailions follows exactly that order. Each domain gets its own DKIM key, the panel shows the records to publish and the API guide has working examples for Node.js, PHP, Python and cURL. If the mail server is briefly unavailable the message is queued and sent later instead of being lost. Access is set up with us rather than through a checkout, so contact us with your domain and what you plan to send.