Store emails get set up once and then nobody looks at them until a customer calls to say the confirmation carries a logo from three years ago, or that no confirmation came at all. Yet WooCommerce transactional emails, meaning the order confirmation, bank transfer details, shipping notice, invoice and password reset, are the only messages a store sends on its own, with no human involved, to every customer after every purchase. Customers read them more carefully than the homepage, because they are waiting for something specific: did the order go through and when does the parcel arrive.
This post is about setting them up from scratch: what goes out, to whom, from which address and what it should look like. Diagnosing a store that has stopped sending is covered separately in the post on WooCommerce not sending order emails, and the DNS records in the one on SPF, DKIM and DMARC. Here I only point to both, and most of the space goes to what neither of them has: an inventory of the messages and a look that survives an update.
WooCommerce transactional emails - why they do not arrive
Before you change anything about the look, make sure the messages reach anyone at all. A nicely styled email that lands in spam is wasted work. Three symptoms store owners bring to me, and three different directions to look in:
- The customer gets nothing, you get the notification. The store is sending, but the customer’s mailbox has no reason to trust the sender. That is a domain credibility problem, not a WooCommerce one.
- Nobody gets anything. The store is not sending, or a plugin is intercepting the send. You look in the settings and the plugin list, not in DNS.
- Emails arrive, but hours late and in a batch. The store’s task queue is stuck; sending itself works.
Each of these has its own order of checks, and I laid every one out step by step in the diagnosis post, so I will not repeat it here. For a setup from scratch one thing matters: sending first, looks second. In that order, never the other way round.
SMTP and domain authentication
Two things I do in every store before the first order, before I touch any template.
The first is sending through SMTP, meaning hooking the store up to a real mailbox on the store’s domain instead of the default send from the hosting server. The store then logs in to the mail server the way an email client does and sends as an authenticated sender. The second is three records in the domain’s DNS that tell receiving mailboxes who is allowed to send on behalf of your company. The order is always the same: SMTP first, DNS second, because only an authenticated send has a chance of passing the record checks.
Choosing the plugin, ports, app passwords and mailbox limits are in the diagnosis post; the record contents and how to read the reports are in the SPF, DKIM and DMARC post. From this post’s point of view what counts is the final test: a message from the store opened in Gmail, the original view, and a pass next to each of SPF, DKIM and DMARC. Until you see that, restyling makes no sense, because nobody is going to see those emails anyway.
Which emails go out, to whom and from where - an inventory before restyling
This is where the part begins that the other two posts do not have. WooCommerce keeps, in its settings under the emails tab, a list of every message it can send. It is worth walking through it item by item and answering three questions for each: when does it go out, to whom, and is it needed at all.
Messages for you and the people running the store:
- New order - goes to the addresses in that message’s recipient field, not to the WordPress administrator. That field has its own list, which you fill in by hand, and it does not change by itself when you change the admin address. You can enter several addresses separated by commas, for example the warehouse mailbox and the owner’s.
- Cancelled order and failed order - to the same recipients. Failed is worth leaving on, because it is the only trace of a customer who wanted to pay and could not.
Messages for the customer:
- Order on hold - for a traditional bank transfer. It carries the transfer details, so its content matters: account number, transfer title, deadline.
- Processing order - this is what the customer understands as the “order confirmation”. It goes out when payment has cleared, or when a cash-on-delivery order moves straight to processing.
- Completed order - after dispatch. This is usually where the tracking number lands, if the courier plugin adds it.
- Refunded order, customer invoice and order details, customer note, reset password, new account.
Two things that trip up the most owners. First, WooCommerce does not send an email “because an order came in”. It sends one because the order changed status. A customer paying by bank transfer gets the on-hold message, and will never get the processing confirmation if nobody manually moves the status after the payment is booked. That is not an outage, it is a missing step in the process. Second, the sender fields at the bottom of the same page: name and address. The address has to be on the store’s domain and identical to the one the store logs in to SMTP with. The sender name is the first thing the customer sees in their inbox list, so you put the store’s name there, not “WordPress” and not the administrator’s first name.
Every message on the list also has its own settings: subject, heading and a field for additional content. That is the cheapest way to put a sentence about processing time into the confirmation, a note on where to track the parcel into the shipping message, and a request to quote the order number in the transfer title into the on-hold message. No template touched, no risk at update time.
What helps: instead of clicking around the settings on a live store, place one test order with every payment method you have enabled and walk each one manually through all the statuses. You will collect in your inbox the complete set of messages the customer really receives, and only then decide what to change.
The look, without breaking anything
By default WooCommerce sends messages in a single template made up of a header image, a top bar colour, a background colour, a text colour and footer text. You set all of these in the same tab, globally for every message, and that is the first layer I start with at every client. Logo in the header, colours matching the site, and in the footer the company name, address, phone and support hours. For most stores that is enough for an email to stop looking like a system message and start looking like a message from the store.
At this layer there are three traps I see regularly:
- A header image loaded over an address without https, or from a staging server. Gmail shows an empty frame, Outlook shows a warning. The logo has to live on the production domain, under a full https address, at a sensible size, because an email client will not scale it the way a browser does.
- Colours chosen for a light background. More and more people read mail in dark mode, and some email clients invert colours on their own. A dark logo on a transparent background disappears. In email I put the logo on a fixed, light background, even if it is transparent on the site.
- Special characters and currency. After changing a template or a plugin I check that currency symbols and accented characters render correctly in every email client, because a message that goes out in a different encoding than it declares looks like spam.
There is one more rule that applies whichever way you make the change: what works on a website does not work in an email. Email clients strip external stylesheets, some of them strip styles in the document head too, they run no scripts at all and they treat layout differently from one another. So styles in an email sit in the tags themselves and the layout is simpler than on the site. If someone offers you an email template “just like the website”, with animation and a grid, they do not know where it is going to be displayed.
Three ways to go deeper, and what each costs at update time
When the global settings and the additional content are not enough, three routes remain. Each works, each costs something different, and the choice depends on who will be maintaining the store.
An email design plugin. A builder where you drag blocks and see a preview. The fastest route to a result and the most convenient for someone who does not want to touch code. The cost: one more plugin in the store that has to stay compatible with every WooCommerce update, and a dependency on it, because the moment it is switched off the emails revert to the default look. In a store that already carries dozens of plugins I add it reluctantly.
Overriding the templates in a child theme. WooCommerce lets you copy any message’s template file into the theme folder and change it there. This is the cleanest route: no extra plugin, full control over the layout. The cost: templates carry versions, and when WooCommerce changes its own, your copy stays on the old one. The store flags this in the system status as an outdated template, and until you update the copy by hand you risk a new order field not showing up in the email. So I override only the files I really have to, and check their status after every update, together with the rest of the safe WooCommerce updates checklist.
Your own code hooked into the email events. In many places in the template WooCommerce lets you attach your own content without copying the whole file: before the order table, after it, in the footer. Adding a block with a tracking link, or a shipping-time note for a specific product category, is exactly what I do this way. The cost: someone has to write it, and it needs a home in a child theme or a small plugin of its own so the code survives a theme update.
The order I think about this in is always the same: global settings first, then additional content per message, then code on the events, and only at the very end an override of the whole template. The further down that list, the more work at every update.
How I test emails after a change
The “send test email” button in an SMTP plugin only checks the connection to the mail server. It does not check the template, the additional content, or what plugins append to a specific message type. So after every change to the look I do the same thing as during the inventory: a full test order, walked manually through every status, and I read every message on its own.
I read them in at least three places: Gmail in the browser, Outlook, and on a phone, each in light and dark mode. The differences between them are bigger than you would expect, and it is usually Outlook that shows a layout which looked fine in Gmail breaking across the width. On top of that, the original view in Gmail, so that after a plugin change I can confirm the message still goes out through the same channel and still passes authentication, because email plugins can quietly swap the sending method.
If the store is already live and the emails look like something set up years ago, that review falls under optimising and developing an existing store for me: an inventory of the messages, tidying up sender and recipients, a look that matches the site, and a test of the whole order cycle in several email clients. It usually surfaces a few things the owner did not know about, such as notifications still going to the mailbox of someone who left the company long ago.
Frequently asked questions
Can I switch off some of the emails so the customer does not get so many? Yes, every message has its own toggle. I usually keep on hold, processing and completed, because they answer the customer’s three questions: did the order go through, is it paid, has it shipped. Switching off the completed message is the most common cause of “where is my parcel” phone calls.
How do I add a tracking number to the completed order email? Simplest through a courier plugin that adds the number and a tracking link to that message by itself. If you ship outside the system, what remains is a customer note sent from the order screen, or your own code that attaches a field with the number to the message. Typing the number into the additional content makes no sense, because that content is shared by every order.
Can restyling the emails break their deliverability? It can, in two cases. When an email design plugin swaps the sending method and bypasses the SMTP you set up, or when the new template pulls images from a foreign server. After every change to the look I open the message’s original view in Gmail and check the same things as when setting up sending.
I get emails from WooCommerce and separately from an invoicing plugin. How do I unify them? Invoicing plugins usually attach the invoice to an existing WooCommerce message rather than sending their own, and then there is one look. If they send separately, they have their own template in their own settings and the logo and footer have to be set in two places. With several systems sending from the store’s domain I also make sure each is listed in SPF, otherwise one of those messages starts landing in spam.
After a WooCommerce update the emails changed appearance. What happened? Most likely the store moved to a newer default template and your colour and image settings were interpreted afresh, or an overridden template in the theme was flagged as outdated. Check the system status in WooCommerce, which lists the templates with version information, and compare it with the copy in the theme. If you have no copies of your own, going through the global settings again and placing a test order is enough.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Let’s talk about your project.