WooCommerce Emails: Deliverability, Branding and Customization

WooCommerce emails are the most-read messages your store will ever send. A newsletter is lucky to get a 25% open rate; an order confirmation gets opened by almost everyone, often within minutes, sometimes three or four times while the customer waits for the parcel. And yet most stores I audit send the default purple-headed template, from a generic address, through PHP’s mail() function – which means a decent share of those messages never reach the inbox at all. The one channel where the customer is actively looking for you is the one most store owners never touch.

This guide is the full treatment: which emails WooCommerce sends, when, and to whom; why deliverability has to come before any design work; SPF, DKIM and DMARC explained without the jargon; what the native settings can and cannot do; an honest look at customizer plugins versus code overrides; how to upgrade the content of each email so it reduces support tickets and earns reviews; the emails almost everyone forgets; how a developer adds new ones; and the testing routine that stops a WooCommerce update from quietly breaking the whole system. It is written from setting this up on dozens of client stores in Germany, the UK, the US and Australia – small shops on shared hosting and stores doing six figures a month.

Table of contents

• The WooCommerce email map: what sends, when and to whom
• Why wp_mail() fails – and what to use instead
• SPF, DKIM and DMARC in plain language
• Branding with the native settings – and where they stop
• Email customizer plugins, honestly
• Code overrides for full control
• Content upgrades: making each email do a job
• The emails nobody customises – and should
• Adding your own transactional emails
• Why promotional content does not belong in transactional emails
• Monitoring, bounces and the testing matrix
• Frequently asked questions

The WooCommerce email map: what sends, when and to whom

Before you brand anything, know what actually goes out. A stock WooCommerce install ships eleven transactional emails, each tied to an order status change or an account event. You will find them under WooCommerce > Settings > Emails, and it is worth reading that list once with fresh eyes, because several of them fire at moments you probably have not thought about.

• New order – goes to you (the admin recipient), not the customer, on every order that reaches processing or on-hold. Route it to an inbox someone actually monitors, not info@.
• Cancelled order and Failed order – also admin-facing by default. A failed order means someone tried to pay you and could not; treat that email as a fire alarm, not background noise.
• Order on-hold – customer-facing, sent when the order awaits payment (bank transfer, some invoice gateways). It needs to explain exactly what happens next, because the customer has paid nothing yet and is nervous.
• Processing order – the “thanks, we have your order and your money” email. This is the confirmation, the single most-opened message your store sends.
• Completed order – fires when you mark the order complete, which for physical goods should mean shipped or delivered. This is where tracking details and, later, a review request belong.
• Refunded order – confirms a full or partial refund. Customers read this one with their bank app open.
• Customer invoice / order details – manually triggered from the order screen; useful for phone orders and payment reminders.
• Customer note – fires whenever you add a note to the order marked “note to customer”. Handy, and dangerous if staff do not realise notes are sent.
• Reset password and New account – account plumbing. Boring until the reset email lands in spam and a returning customer is locked out at checkout.

Extensions add their own: subscription renewals and payment-failure notices if you run recurring billing (covered in my guide to WooCommerce subscriptions and memberships), booking confirmations, shipping-plugin notifications, invoice PDFs. Every one of these carries your brand and lands in the same inbox thread, so the map is the first deliverable of any email project: a one-page list of every email the store can send, its trigger, its recipient and whether it is currently enabled. On most stores I audit, at least one email is switched off that should not be, and at least one fires that nobody knew about.

Why wp_mail() fails – and what to use instead

Out of the box, WooCommerce hands every email to WordPress’s wp_mail() function, which hands it to PHP’s mail() function, which hands it to whatever mail transfer agent your hosting server runs. No authentication, no dedicated sending reputation, no delivery feedback. Your order confirmations leave the server from the same IP address as every other site on that shared host – including, statistically, at least one hacked site pumping out spam. Gmail and Microsoft do not know your store; they know that IP, and they judge you by your neighbours.

The symptoms are predictable: emails arrive for some customers and not others, Gmail users find them in spam, Outlook users sometimes get nothing at all, and you only learn about it when a customer emails “I never got my confirmation” – which means for every customer who tells you, several just assumed your store is dodgy. On a store with real volume, silent non-delivery of order confirmations is a measurable revenue and support cost.

The fix is to route mail through a proper transactional sending service, authenticated as your domain. Two ways to connect:

• SMTP plugin – WP Mail SMTP or FluentSMTP intercepts wp_mail() and relays through your chosen provider over SMTP or, better, the provider’s HTTP API. Setup is 30-60 minutes including DNS. FluentSMTP is free and logs every email; WP Mail SMTP’s free tier covers most stores.
• Direct API integration – for high-volume stores I sometimes wire WooCommerce straight to the provider’s API with proper queueing and retry logic, the same pattern I use for other WordPress API integrations. Overkill below a few thousand emails a day, worth it above.

Which provider? Honest comparison from stores I run this on:

My default recommendation for a store that depends on its email: Postmark if the budget allows, Brevo or SMTP2GO if it does not, SES when volume makes the others expensive. Whatever you choose, send transactional email on a separate stream (or separate subdomain) from any marketing email. Marketing lists decay, collect spam complaints and drag reputation down; your order confirmations should never share that fate.

SPF, DKIM and DMARC in plain language

Choosing a sender is half the deliverability job. The other half is telling the world’s inbox providers that this sender is allowed to speak for your domain. That is what the three DNS records do, and none of them is as scary as the acronyms suggest.

SPF – the guest list

SPF (Sender Policy Framework) is a TXT record on your domain that lists which servers may send email claiming to be from you. When Gmail receives a message “from” yourstore.com, it checks the sending server against that list. Your provider gives you the exact value – something like v=spf1 include:spf.mtasv.net ~all – and you paste it into DNS at your registrar. One rule: a domain gets exactly one SPF record; if one already exists (for Google Workspace, say), you merge the include statements into it rather than adding a second record.

DKIM – the wax seal

DKIM (DomainKeys Identified Mail) cryptographically signs each outgoing message. Your provider holds a private key and signs every email; the matching public key sits in your DNS as another TXT record; receiving servers verify the signature. If the message was altered in transit or sent by someone without the key, verification fails. Setup is again copy-paste: the provider generates the record, you publish it, you click verify.

DMARC – the instructions

DMARC ties the two together and tells receivers what to do when a message fails: p=none (deliver anyway but report it), p=quarantine (spam folder) or p=reject (refuse). Start with p=none and a reporting address, watch the reports for a couple of weeks to confirm all legitimate mail passes, then tighten to quarantine. Since Google and Yahoo began requiring authentication from bulk senders, a missing DMARC record is no longer a nice-to-have – stores without it see measurably worse placement.

Prove it works

Do not trust the green ticks in the plugin. Test placement the way I do at every store launch – it is a line item in my WooCommerce store launch checklist:

• mail-tester.com: place a test order using the address it gives you; aim for 9 or 10 out of 10 and fix whatever it flags below that.
• Real inboxes: test orders to a Gmail, an Outlook/Hotmail and one local provider for your market (GMX or web.de for German stores, BT or Sky for the UK). Check the inbox, the spam folder and – on Gmail – which tab the email lands in.
• Authentication headers: open the delivered email’s original source and confirm spf=pass, dkim=pass, dmarc=pass. Three passes or you are not done.
• Google Postmaster Tools: free, and worth registering your domain once volume passes a few hundred Gmail messages a day.

Branding with the native settings – and where they stop

With delivery solved, make the emails look like they came from your store. WooCommerce’s built-in options live in WooCommerce > Settings > Emails, below the email list, and they cover more than people expect:

• From name and address – change “WordPress” and wordpress@yourdomain to your store name and a real, monitored address. Never send from noreply@: it signals “do not talk to us”, hurts trust, and some spam filters score it negatively. Use orders@ or hello@ and actually read the replies – they are the earliest warning system your store has.
• Header image – your logo, uploaded to the media library and referenced by URL. Keep it around 400-600px wide and remember dark mode: a black logo on a transparent background disappears in Outlook’s dark theme. A version with padding on a white rounded rectangle survives everywhere.
• Base colour, background, body text colours – the base colour drives the header bar and links. Pick your brand colour, but check the contrast of white text on it.
• Footer text – accepts basic HTML. This is where your legal identity goes: company name, address, and for German stores the Impressum-style details customers expect on any commercial message. Add a support email and phone number here too.

For maybe half the stores I build, honest answer, this is enough: authenticated delivery, logo, brand colour, proper footer, upgraded text content (next sections). The native settings stop hard, though, at layout. You cannot reorder the content blocks, add a banner or a delivery-timeline graphic, change typography meaningfully, adjust the order-table styling, or make any change per-email rather than global. The template is one column, one design, all emails. When a client wants order confirmations that look like their brand rather than “WooCommerce in our colours”, we move to one of the next two options.

Email customizer plugins, honestly

Email customizer plugins give you a drag-and-drop builder for the templates: Kadence WooCommerce Email Designer (free, solid, no longer actively developed but still working), YayMail, Email Customizer for WooCommerce by ThemeHigh, and the builders bundled into suites like FunnelKit. They preview live, they let non-developers edit, and for a store owner who wants to tweak copy and layout without calling me every time, that autonomy is a real argument.

The honest trade-offs, from cleaning up after a few of these:

• They replace the whole template pipeline. Your emails now depend on the plugin. If it lags behind a WooCommerce update or is abandoned (it has happened in this exact category), every transactional email on the store is hostage to it.
• Generated markup is heavier. Builder output carries more nested tables and inline styles than a hand-written template. Usually fine, but Gmail clips messages over 102KB – and a builder template plus a long order table can cross that line, cutting off your footer and its legal text.
• Compatibility with other extensions is hit-and-miss. Emails from subscriptions, bookings or shipping plugins may not inherit the builder design, leaving you with two visual identities in the same inbox thread.
• Testing tools vary. The good ones send previews with real order data; the bad ones preview with placeholders and surprise you on the first live refund email.

My recommendation: if the store owner will genuinely edit emails themselves and the store is plugin-light, a maintained customizer (YayMail is the one I currently trust most) is a reasonable choice – budget for its licence and test after every WooCommerce update. If emails will be set up once and left alone, or the store already runs many extensions, code overrides are cheaper over a two-year horizon and remove a dependency.

Code overrides for full control

WooCommerce’s email templates are ordinary PHP files, and the override system is the same as for any other WooCommerce template: copy the file from wp-content/plugins/woocommerce/templates/emails/ into your-child-theme/woocommerce/emails/ and edit the copy. WooCommerce loads your version instead. The files worth knowing:

• email-header.php and email-footer.php – the frame around every email; this is where a custom banner, navigation-free header or richer footer lives once, applied everywhere.
• email-styles.php – the CSS, which WooCommerce inlines into the HTML at send time (email clients largely ignore embedded stylesheets, so inlining is not optional).
• customer-processing-order.php, customer-completed-order.php and friends – the per-email body templates, which is how you finally make the confirmation say something different from the shipping notice.
• email-order-details.php, email-addresses.php – the order table and address blocks shared by most emails.

Alongside templates, hooks handle the logic-level changes without touching markup: woocommerce_email_header and woocommerce_email_footer, plus filters like woocommerce_email_subject_customer_processing_order for subject lines and woocommerce_email_additional_content_ filters for the per-email extra text. A useful example – adding a delivery estimate under the order table of the confirmation only:

add_action( 'woocommerce_email_after_order_table', function( $order, $sent_to_admin, $plain_text, $email ) {
    if ( 'customer_processing_order' === $email->id && ! $plain_text ) {
        echo '<p><strong>Estimated delivery:</strong> 2-4 working days. Track it from the link in your shipping email.</p>';
    }
}, 10, 4 );

Two rules make overrides safe. First, override the minimum: every file you copy is a file you must diff against the original after WooCommerce updates (the system status page lists outdated templates under Templates – check it after every update). Hooks and filters survive updates untouched, so prefer them wherever they can do the job. Second, respect email-client reality: layout with tables, styles inline, no web fonts you have not stacked fallbacks for, and test in Outlook, which still renders email with a word-processor engine and will humble any modern CSS you try.

Do not skip the plain-text template pipeline either. Every WooCommerce email has a plain-text twin under templates/emails/plain/, sent when a recipient’s system prefers text or when a security gateway strips HTML – common at B2B customers whose corporate filters distrust HTML mail. If you change what an email says in HTML, mirror it in the plain version; a customer reading the text part should get the same facts, and spam filters score messages whose text and HTML parts diverge wildly.

Content upgrades: making each email do a job

Design gets the attention, but the copy changes the numbers. Each email exists at a specific emotional moment, and the default text ignores that.

Order confirmation: the anxiety-killer

The customer has just given money to a website. The confirmation’s job is to make that feel safe, and it does that by answering three questions above the fold: what did I buy (order summary, clear totals including tax and shipping), when do I get it (a concrete estimate – “ships within 1 working day, delivery in 2-4” beats silence even when the range is wide), and who do I talk to if something is wrong (a human support email and response-time promise, not a noreply). Add what happens next: “you will get a shipping email with tracking”. Stores obsess over trust signals at checkout – rightly, it is a pillar of reducing cart abandonment – and then send a confirmation that answers none of the questions an anxious first-time buyer actually has. The confirmation is checkout optimisation’s final page.

Shipping notice: tracking front and centre

If you use a shipping plugin or fulfilment integration, the tracking number and a direct carrier link belong at the top of the completed-order email, not buried under the order table. Name the carrier, state the expected window, and say what to do if the parcel does not arrive by a specific date. Every fact in this email is one “where is my order” ticket that never gets opened – on one German client store, rewriting exactly this email cut WISMO tickets by roughly a third.

Completed order: the review ask, timed ethically

The completed email is where a review request lives – but only if “completed” means the customer has the product. Asking for a review of something still in a delivery van annoys people and produces logistics complaints disguised as product reviews. The pattern that works: mark completed at handover to the carrier, then send the review request as a separate, delayed follow-up – 7-14 days after delivery for most physical goods, longer for products that need living with. And ask honestly: one product, one link, no incentive language that trips review-platform rules or spam filters. A review request that arrives after the product has genuinely been used gets better reviews, not just more of them.

The emails nobody customises – and should

• Failed order. By default only you hear about a failed payment; the customer often sees a generic gateway error and gives up. Configure a customer-facing recovery path: a clear email (or a follow-up flow) saying the payment did not complete, the order is saved, and here is a link to pay again – with the support address for card-declined embarrassment, which is real and silent. Stores recover a meaningful slice of failed orders just by saying “this happens, here is the link”.
• Refunded order. The default is a bare notification. Upgrade it with the two facts customers refresh their banking app for: how much, and how long until it lands (“refunds reach your original payment method within 5-10 working days, depending on your bank”). State partial refunds explicitly – “we refunded the shipping cost of EUR 4.90” – because an unexplained partial amount generates an angry email every time.
• On-hold / bank transfer. If you accept bank transfer, this email carries your IBAN and the payment reference. Make the reference impossible to miss and say what happens after payment (“we ship within 1 working day of the money arriving”). Half the manual work in bank-transfer stores is matching payments with missing references.
• New account and password reset. Test the reset flow from a real customer account quarterly. It is the email most likely to be silently broken – and a returning customer who cannot reset a password at checkout is a lost order that never shows in any report.

Adding your own transactional emails

Sooner or later a store needs an email WooCommerce does not have: a back-in-stock notice, a “your order left our workshop” step for made-to-order products, a pre-arrival email for heavy freight (“someone must be home”), a digital-goods onboarding sequence, or status emails for a custom order flow like quote-approved or awaiting-fitting.

The clean developer approach is to register a proper email class, not to scatter wp_mail() calls around the theme. You extend WC_Email, give it an id, subject and heading, point it at its own template pair (HTML and plain), register it via the woocommerce_email_classes filter and trigger it from the relevant hook – for a custom order status, that is woocommerce_order_status_changed. The payoff for doing it properly: your email appears in WooCommerce > Settings > Emails like the native ones, the store owner can edit its subject and toggle it without a developer, it inherits the store’s header, footer and styles automatically, and it flows through the same SMTP transport and logging as everything else. A custom email class is a half-day of development including templates and testing; I build them regularly as part of WooCommerce development projects, most often for stores with non-standard fulfilment flows. If your flow depends on data from an external system – the courier’s API, an ERP, a booking platform – the email work usually pairs with an integration that pulls that data into the order first.

One warning from cleanup jobs: resist the temptation to trigger emails from page templates or form handlers directly. Emails belong on order and status hooks, where they fire exactly once per event, get logged, and keep working when the checkout changes.

Why promotional content does not belong in transactional emails

The temptation is obvious: the confirmation gets opened by everyone, so why not put a 10% next-order coupon and three product recommendations in it? Two reasons, one legal and one technical.

Legal: transactional email enjoys a privileged position precisely because it is not marketing. Under GDPR and the ePrivacy rules in the EU (and equivalent rules elsewhere), you can email order information without marketing consent – but a confirmation stuffed with promotions starts to look like direct marketing sent without consent. German courts in particular have treated promotional content in transactional messages as actionable, and Germany is a market where competitors do send warning letters. The safe line: content necessary for the transaction is fine; a soft, service-flavoured element (like a review request for the purchased product) is defensible; a coupon carousel is marketing and needs marketing consent.

Technical: spam filters classify by content, and transactional messages score well partly because they look transactional. Fill the confirmation with promo blocks, discount language and a dozen product images and it starts scoring like a newsletter – dragging down the deliverability of the very email that must always arrive. This is also why Postmark refuses promo content on its transactional stream: mixing the two poisons the well. Keep the streams separate – transactional on its authenticated transactional path, marketing through a proper newsletter platform with its own consent, list hygiene and unsubscribe handling – and each performs better than a blended stream ever would.

Monitoring, bounces and the testing matrix

Email systems do not fail loudly; they rot. Monitoring is what turns “customers stopped getting confirmations three weeks ago” into “we saw the DKIM failure the day the DNS host reset our records”.

• Send logging. FluentSMTP, WP Mail SMTP Pro or your provider’s activity feed gives you a searchable record of every email: sent, delivered, bounced, opened where measurable. When a customer says “I got nothing”, you answer in thirty seconds with facts instead of resending blind.
• Bounce handling. Hard bounces (address does not exist – usually a typo at checkout) should trigger a human follow-up on the order phone number if there is one. Watch the bounce rate itself: above roughly 2% sustained, providers start throttling you. API senders handle suppression lists automatically; raw SMTP setups need you to pay attention.
• Open rates, with honesty. Apple Mail Privacy Protection preloads tracking pixels, so opens are inflated and always have been fuzzy. Use open rates as a trend line, not a truth: a confirmation open rate that falls off a cliff week-on-week means a placement problem, whatever the absolute number says.
• DMARC reports. A free monitor (Postmark’s DMARC tool, dmarc-digests, or your provider’s) turns the XML reports into a weekly digest. It is also how you discover someone spoofing your domain – which is a thing that happens to shops, because order emails are exactly what phishers imitate.

Finally, the testing matrix. Emails break silently when WooCommerce updates change templates, a plugin update changes hooks, or a theme change touches overrides. After every significant update, and monthly regardless, run the same fixed drill on staging or with a test product: place an order (confirmation), mark it completed (shipping/review email), refund it (refund email), trigger a password reset, and fire one of each custom email. Check each message in Gmail and Outlook, confirm the three authentication passes, glance at mail-tester, and check WooCommerce > Status for outdated template warnings. Fifteen minutes, scripted once, and it has caught broken emails on client stores more times than I can count – always before customers did.

Want your store’s emails handled properly?

I set up complete WooCommerce email systems for stores in Germany, the UK, the US and Australia: authenticated deliverability, branded templates by override or customizer, upgraded content per email, custom email classes and the monitoring to keep it all working – as part of my WooCommerce development service, at EUR 15 per hour or a fixed price quoted within 24 hours. See recent work in the portfolio or tell me about your store – I reply within 24 hours.

Frequently asked questions

What are WooCommerce emails?

WooCommerce emails are the transactional messages a store sends automatically at order and account events: order confirmation, shipping and completed-order notices, refunds, failed and on-hold orders, invoices, and account emails like password resets. A stock install ships eleven of them, configurable under WooCommerce > Settings > Emails.

Why do my WooCommerce emails go to spam?

Almost always because they are sent through PHP mail() from an unauthenticated shared server. Route them through an SMTP or API sending service and publish SPF, DKIM and DMARC records for your domain; that combination fixes the vast majority of spam-folder cases.

How do I customise WooCommerce email templates?

Three levels: the native settings (logo, colours, footer text), a customizer plugin like YayMail for drag-and-drop layout control, or template overrides in your child theme for full control. Overrides are the most durable option; plugins trade a dependency for owner-editability.

Do I need an SMTP plugin for WooCommerce?

Yes, in practice. WP Mail SMTP or FluentSMTP plus a transactional provider (Postmark, Brevo, Amazon SES) is the standard fix, costs between nothing and about EUR 15 per month for small stores, and takes under an hour to set up including DNS records.

Can I put discount codes in order confirmation emails?

I advise against it. Promotional content in transactional email raises legal risk in consent-based markets (Germany especially), and makes spam filters score your must-arrive emails like newsletters. Keep marketing in a consented newsletter stream.

When should a WooCommerce store ask for a review by email?

After the customer has actually received and used the product – typically 7-14 days after delivery, as a separate follow-up rather than inside the completed-order email. Earlier asks produce delivery complaints dressed up as product reviews.

Do WooCommerce emails break when the plugin updates?

They can, especially with template overrides or customizer plugins. Check WooCommerce > Status for outdated template warnings after each update and run a short test drill: place, complete and refund a test order, then verify each email arrives and renders correctly.