Available for projects & agency overflow · Quick reply, from the person who does the work

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.

Describe my issue Send a message

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.

Worth reading too

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

besoin
etat
constructeur (facultatif)
extensions (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.