Transactional Email for Websites: Orders, Resets and Receipts

When a customer places an order, resets a password or submits a booking request, your website sends an email. These automated messages are called transactional email. Unlike a newsletter, each one is triggered by a single action and the recipient is waiting for it. If it does not arrive, support tickets follow. Getting this right is mostly a matter of how your site sends mail and whether the message can be trusted.

Transactional versus marketing email

	Transactional	Marketing
Trigger	A user action	A campaign you schedule
Examples	Receipts, resets, booking confirmations	Newsletters, promotions
Expectation	Arrives within seconds	Arrives eventually
Unsubscribe	Not applicable to core messages	Required and prominent
Spam risk	Lower, if authenticated	Higher, driven by complaints

Keep the two streams separate where you can. Marketing complaints should never put password resets at risk.

How websites usually send mail

The default: local mail from the web server

Many applications, including WordPress by default, hand the message to the web server's local mail function. It is easy and needs no configuration, but it has weaknesses. The message often has a generic sender, such as a system user at the server's hostname, it may not be signed with DKIM, and the From address may not match any domain you have authenticated. Large providers frequently treat these messages as suspicious.

Better: authenticated SMTP

Configure the site to log in to a real mailbox over SMTP, for example [email protected] or [email protected], with the server name, port 587 or 465 and a password. The message is then sent by your mail server, signed with your DKIM key and covered by your SPF record. In WordPress, an SMTP plugin makes this a form to fill in. In other applications, look for a mail settings page or environment variables.

Dedicated sending services

Third-party transactional email services send on your behalf through an API or SMTP, and provide delivery logs, bounce handling and scalable capacity. They are useful for shops with many orders or when you need detailed reports. They require that you add their records to your DNS, so that the messages are authenticated as your domain.

The From address matters

• Use an address on your own domain, never a free webmail address. Sending as a public provider's domain from your server will fail DMARC checks at that provider and can be rejected.
• Make sure the address is a real, working mailbox or alias so that replies and bounces go somewhere.
• Be consistent. A recognisable name such as "Yourshop Orders" helps customers find the message.

Authentication checklist

1. SPF includes every server that sends your transactional mail.
2. DKIM signs those messages, with a key published for the right selector.
3. DMARC is published, and your reports show the website's mail passing and aligned.
4. Reverse DNS of the sending IP matches its hostname.

If a third-party service sends for you, use its domain authentication feature. If it only signs with its own domain, DMARC alignment may fail.

Content that is easy for filters and people

• Plain, short messages with a clear subject, such as "Your order 1234 is confirmed".
• Both a text and an HTML version.
• Links to your own domain, not shorteners.
• No unnecessary attachments. Link to a receipt page instead.
• Do not put sensitive details such as full passwords in the message. Send a time-limited reset link.

Testing and monitoring

Test every template: new account, password reset, order, refund and contact form. Check each at several different mailbox providers, in the inbox and spam folders. Look at the headers for passing authentication. In production, keep a log of outgoing mail if your tool supports it, and review failures regularly. A silent failure of your mail setup is hard to spot, because nobody complains about an email they never knew was coming, until they cannot log in.

Rate limits and sending reputation

Shared servers and mail services often limit the number of messages you can send per hour. That is a protection for everyone, and a reason to avoid using your website's mailer for newsletters. If you send bulk marketing, use a service designed for it. Keep bounce handling in mind: repeatedly mailing addresses that do not exist harms reputation, so remove invalid addresses from your user database when bounces reveal them.

Use a subdomain for isolation

Some businesses send website mail from a subdomain, such as shop.yourdomain.com. The subdomain builds its own reputation and has its own SPF and DKIM records, which protects your main domain from the consequences of a problem on the website. It also keeps your SPF record under the 10-lookup limit.

Queues and failures

Sending mail while a visitor waits can slow the page down, and a temporary mail server problem can turn into an error on checkout. Well-built applications put messages in a queue and send them in the background, retrying if a first attempt fails. If your platform offers this, use it. If it does not, make sure a failed email never blocks the order itself, and that someone is notified when sending errors appear in the logs.

Transactional email on Zebra Hosting

With Zebra Hosting you can create a mailbox for your site's messages in Plesk and point your website at it over authenticated SMTP, with support in 17 languages to help you set it up. See the business email plans, or if your site runs WordPress, the WordPress hosting options.