# WooCommerce order emails aren’t arriving

> An order goes through, but neither you nor the customer get an email: this is one of the most common cases I deal with on WooCommerce, and the cause is almost never WooCommerce itself. The plugin generates the message correctly in the vast majority of cases; it’s the delivery to the inbox that fails, often without any error showing up in your dashboard.

- Source canonique : [https://allaux.fr/en/wordpress-woocommerce/problemes/emails-commande-non-recus](https://allaux.fr/en/wordpress-woocommerce/problemes/emails-commande-non-recus)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Open WooCommerce > Status > Logs and look for a fatal error at the exact time of the order: if the sending hook crashes, no message is even generated. Otherwise it is generated but never delivered. Check the recipient under WooCommerce > Settings > Emails, then replace PHP’s mail() function with an authenticated SMTP relay.

## How I go about it

1. **Checking WooCommerce settings** — I start with WooCommerce > Settings > Emails: I check that the email type involved (new order, processing, completed…) is actually enabled, and that the recipient field holds the right address, without a stray space or typo.
2. **Reading the WooCommerce logs** — I open WooCommerce > Status > Logs. If a plugin triggers a fatal error during the sending hook, it shows up there: usually the first lead when nothing goes out at all, not even to spam.
3. **Sending an isolated test** — I send a test email to tell apart a message that was never generated, rarer, from one that was generated but never delivered, by far the most common case on the stores I look at.
4. **Checking the transport** — By default, WordPress sends through wp_mail(), which relies on PHP’s mail() function. Many hosts block or heavily throttle it, and without proper SPF/DKIM alignment for the sending domain, the message lands in spam or vanishes.
5. **Setting up an authenticated SMTP relay** — The durable fix is almost always a transactional email service connected over authenticated SMTP, through a plugin that hooks into phpmailer_init instead of letting the server send directly.

## What I handle regularly

- The customer says they got no confirmation, even though the order is clearly there in the WordPress admin
- I stopped receiving "new order" notifications, even after checking spam
- It was working, then stopped from one day to the next with no change I’m aware of
- The password-reset email never arrives, while the order confirmation still works fine
- Emails do arrive eventually, but hours late

## Two very different problems behind one symptom

WooCommerce doesn’t handle sending itself: it builds the email content (new order, invoice, credit note…) then hands it to wp_mail(), WordPress’s native function. On most shared hosting, wp_mail() falls back to PHP’s mail(), which sends straight from the server with no authentication. This is what explains most emails that never arrive.

Without properly aligned SPF and DKIM records for the sending domain, major mail providers treat this traffic as suspicious: the message lands in spam, or gets silently rejected with no notice on the site’s side. That’s a deliverability problem, not a WooCommerce bug.

A rarer second case is a message that never even gets generated: a caching plugin caching the "order received" page can, if misconfigured, skip the hook responsible for sending it. Both situations look the same to the customer but get fixed very differently.

## What’s a setting, what needs development

> Checking that an email type is enabled and the recipient is correct is within reach of a merchant or a generalist, right in WooCommerce > Settings > Emails. Diagnosing a hook conflict, reading a fatal error in the logs, or properly setting up an authenticated SMTP relay with its API keys is the work I do.

## Worth reading too

- **WooCommerce payment problem** — Blocked order or failing webhook: another symptom hitting the same checkout flow. ([/wordpress-woocommerce/probleme-paiement](/wordpress-woocommerce/probleme-paiement))
- **WooCommerce maintenance** — Regular monitoring and work to stop this kind of failure happening again quietly. ([/services/maintenance](/services/maintenance))
- **WordPress & WooCommerce** — The overview page for the failures and evolutions I handle on these platforms. ([/wordpress-woocommerce](/wordpress-woocommerce))

## FAQ

### How do I know if it’s WooCommerce or my host?

By sending a test email from WooCommerce and checking the logs (Status > Logs). If nothing shows up on the WooCommerce side, the problem is almost always in how the server transports the email.

### Do I need a paid plugin to fix this?

Not necessarily a paid plugin, but almost always a third-party transactional email service connected over SMTP, many of which have a free tier that’s enough for an average store’s volume.

### Why do order emails work but not password ones?

They’re two different WordPress hooks. A plugin or customisation can end up interfering with one without touching the other, which explains this kind of seemingly illogical gap.

### Could I lose order history while this gets fixed?

No. The problem sits entirely at the notification-sending level, never at the order level, which stays recorded normally in the database throughout.
