Transactional Email Deliverability: 7 Checks for Shops

Imagine a small online flower shop. A customer orders a bouquet for her mother's birthday, pays, and waits for the confirmation email. It doesn't come. She checks again ten minutes later, then calls the shop to ask whether the order went through. The shop owner finds the order in the admin panel and reassures her. That evening two more customers call with the same question, and one of them has already ordered from a competitor to be safe.

The email had been sent. It landed in the spam folder, or it was quietly rejected by the customer's mailbox provider. Nobody at the shop knew, because the website reported "sent" and nothing else.

Emails triggered by an action on your site, such as order confirmations, password resets, booking confirmations and invoices, are usually called transactional email. They are rarely discussed during a project, because they are tested once with the developer's own address and work. Then the site goes live, the volume grows, mailbox providers tighten their rules, and the messages that customers expect most start to disappear. These seven checks take a few hours and prevent most of it.

1. Don't send from the web server itself

Many websites send email directly from the server they run on, using whatever mail function the platform provides. It works on day one. But that server's address has no sending history, it often shares an address range with thousands of other sites, and mailbox providers treat its messages with suspicion.

Use a dedicated email sending service for transactional messages, connected to your site through its API or SMTP settings. These services manage their sending addresses' reputation, retry when a provider is slow, and report what happened to each message. For a small shop, the cost is usually low enough that the first prevented phone call pays for it.

2. Set up SPF, DKIM and DMARC on your domain

Mailbox providers ask three questions about every message that claims to come from your domain. In plain words:

• SPF: is the server that sent this message allowed to send for this domain? You answer with a DNS record that lists your sending service.
• DKIM: was the message signed by the domain, and was it changed on the way? The sending service gives you a key to publish in DNS.
• DMARC: what should the provider do if the first two checks fail, and where should it send reports? Another DNS record.

Large providers such as Gmail and Yahoo now expect bulk senders to have all three, and messages without them are increasingly filtered even at small volumes. Start DMARC in a monitoring-only mode, read the reports for a few weeks to make sure every legitimate sender is listed, then tighten it.

A common gap: the shop sends order emails through one service, invoices through the accounting software and newsletters through a third tool. Each of them has to be included in SPF and set up with DKIM, or one stream will fail the checks.

3. Keep transactional and marketing email apart

When a newsletter goes out to an old list and many people mark it as spam, providers lower the reputation of the sender. If the newsletter and the order confirmations come from the same address and domain, the confirmations pay the price.

Send them separately. A common arrangement is to send transactional messages from the main domain or a subdomain such as orders, and marketing messages from a different subdomain, ideally through a separate stream in the sending service. Then a campaign that goes badly does not stop password resets.

4. Use a reply address a person reads

Messages from a "no-reply" address save a little work and cost a lot of trust. Customers reply to order confirmations with real questions: a delivery note, a wrong address, a request to change the card message. If the reply bounces or disappears, the next contact is a phone call or a complaint.

Set the reply address to a mailbox someone checks during working hours. Replies also help in a quieter way: providers notice when people reply to a sender's messages and treat that sender as one people want to hear from.

5. Keep the message plain and specific

Transactional emails do not need to look like a campaign. The ones that arrive most reliably say what happened, give the details the customer will look for, and offer one clear next step: order number, items, total, delivery address and date, a link to the order page.

Some habits make filtering more likely: a message that is mostly one large image, link shorteners, many links to different domains, a subject line that reads like an advertisement. Put any promotion in a separate email, not in the receipt.

6. Handle failures, and don't rely on email alone

A sending service tells you, for each message, whether it was delivered, bounced, or reported as spam. Store that status next to the order or the account. If a password reset bounced, the support person can see it immediately instead of asking the customer to "check your spam folder" for the third time.

Also make sure the customer never depends on the email to know what happened. The confirmation page after payment should show the order number and say clearly that the order was received. The account page should list orders and bookings. For password resets, tell the user which address the link was sent to and offer a way to request it again after a minute.

7. Test real inboxes after every change

Deliverability breaks quietly, usually after an unrelated change. The site moves to new hosting and the old SPF record no longer matches. The domain's DNS is moved to another provider and the DKIM records are not copied. A new invoice tool starts sending in your name without being added to SPF.

After each such change, place a test order and request a password reset, and check that both arrive in the inbox at two or three common providers, not only at your own company address. Once a month, look at the DMARC reports or the sending service's dashboard for bounces and spam reports. The goal is to hear about a problem from a report, not from a customer on the phone.

In short

• Send transactional email through a dedicated sending service, not from the web server.
• Publish SPF, DKIM and DMARC for your domain, and include every tool that sends in your name.
• Send transactional and marketing email from separate addresses or subdomains.
• Use a reply address a person reads.
• Keep receipts plain: what happened, the details, one link.
• Store the delivery status of each message, and show the same information on the site.
• Test real inboxes after every hosting, DNS or tool change, and read the reports monthly.

In our e-commerce and web projects, we set up the sending service and the domain records as part of launch, and include order and password emails in the tests we run before handover.