WooCommerce Not Sending Emails? Diagnose It in the Right Order

WooCommerce not sending emails is usually your server's PHP mail() function failing silently, not WooCommerce. WordPress hands every message to wp_mail(), which hands it to the host. Check WooCommerce → Status → Logs, filter for transactional-emails, and see whether the message was sent, failed, or skipped — then move to SMTP before touching anything else.

WooCommerce sends mail using wp_mail(), a core WordPress function, and as the official troubleshooting page puts it, when email is not being sent the issue is often not with WooCommerce itself but with the core email function on your web host (source). The log tells you which half of the problem you have: a delivery problem or a trigger problem.

Fast diagnostic checklist

Work top to bottom. The first two rows are the culprit in most tickets.

Cause 1: PHP mail() is doing the sending

On a default install, nothing in your stack is an email service. WordPress calls wp_mail(), which calls the server's mail transport, and the message leaves from a shared IP with no authentication tying it to your domain. It works often enough to look fine in testing and badly enough to lose real orders.

Start with the log, because it separates the two failure modes. Go to WooCommerce → Status → Logs and filter for the transactional-emails source. Entries are labelled Sent at INFO level when the message was handed to the mail system, Failed at WARNING when the mail system returned an error, Disabled when the notification is off, and Skipped when a required condition such as a recipient is missing (source). Log files themselves live in the wc-logs subdirectory of your uploads folder (source), so you can tail them on a server without loading the admin.

Failed entries mean the handoff broke, and the fix is a real sender. WooCommerce's documentation recommends a dedicated SMTP provider that will send the email for you — in practice, an SMTP plugin pointed at Postmark, Mailgun, SendGrid, Amazon SES, or similar. The gain is not only deliverability but visibility: bounces, rejections, and complaint rates become data instead of silence.

Cause 2: the order never reached a status that sends an email

This one masquerades as a mail failure and is not one. WooCommerce fires customer emails on order status transitions, and orders sitting in Pending payment — "the order has been received, but no payment has been made" — do not generate them. An order must reach Processing, where payment has been received and stock reduced, or beyond (source).

So an Orders screen full of Pending payment rows is a payment callback problem, not an email problem: the gateway is not returning, or its webhook is blocked before it reaches PHP. Notifications map to transitions — New order on receipt, Processing order after payment, Completed order when marked complete, Order on-hold when an order moves there from Pending, Cancelled, or Failed (source). Change one order's status manually and watch the log.

Cause 3: mail is sending but landing in spam

The log says Sent, the customer says nothing arrived. This is deliverability, and it has hardened. Gmail requires all senders to set up SPF or DKIM for their sending domains, keep valid forward and reverse DNS, use TLS, and hold spam rates below 0.3%. Senders of more than 5,000 messages a day also need DMARC, with the From header domain aligned to the SPF or DKIM domain — in force since February 1, 2024 (source).

Two moves. Fix the From address at WooCommerce → Settings → Emails: use an address on your own domain, since a public @gmail.com or @yahoo.com address is likely to cause emails to land in spam folders (source). Then publish the DNS records your provider gives you — SPF, DKIM keys, and a DMARC record. Start DMARC at p=none so you can read reports before enforcing.

Cause 4: the notification is disabled, has no recipient, or the template is broken

Open WooCommerce → Settings → Emails and check each notification you expect. Admin-facing emails such as New order and Failed order have a recipient field that is easy to leave empty after a staff change; customer emails can simply be switched off. A Disabled or Skipped log entry is a settings problem, not a server problem.

Template overrides are the quieter version. Emails are customized by copying a file from wp-content/plugins/woocommerce/templates/emails/ into wp-content/themes/yourtheme/woocommerce/emails/, after which your copy overrides core (source). Core templates update and your overrides do not, so an override written years ago can throw a fatal error and kill the send. WooCommerce → Status flags outdated templates; treat that list as a to-do.

Cause 5: a plugin is intercepting wp_mail()

Because wp_mail() is pluggable, any plugin can replace it wholesale, and several categories do: SMTP plugins, marketing suites, security plugins, membership tools. Load two and one silently wins. The symptom is specific — sending stopped the day something was installed, or one email type disappeared while the rest kept working.

Bisect on staging, never production: deactivate half your plugins, test, repeat. Switching to a default theme in the same pass rules out theme filters on recipients and headers. Then keep exactly one thing responsible for sending mail.

Cause 6: an Action Scheduler backlog is delaying delivery

WooCommerce can defer transactional emails to a background queue instead of sending them inside the checkout request, which speeds up checkout but couples delivery to your job queue (source). Many plugins queue their own mail the same way. A backed-up queue makes mail late, not lost.

Action Scheduler claims 25 actions per batch, runs one concurrent batch, and processes for a maximum of 30 seconds per request by default (source), which a busy store can outrun. Check WooCommerce → Status → Scheduled Actions for past-due actions, then drain with wp action-scheduler run --batch-size=100 (source). If nothing runs at all, confirm the scheduler spawns with wp cron test (source).

How to test delivery properly

A test order proves trigger and transport together — but only test that after you can see each layer separately.

1. Test the transport alone. Run wp eval 'var_dump( wp_mail( "[email protected]", "Test", "Body" ) );'. A false return means the handoff failed inside WordPress, before any network or spam question arises.
2. Log what leaves. Install a mail logging plugin such as WP Mail Logging, place a test order, and read the entry under Tools. WooCommerce's own guidance uses exactly this to establish whether the message was sent.
3. Test across receivers. Send to Gmail, Outlook, and a corporate domain. Passing one and failing another is an authentication result, not a server fault.
4. Read the headers. In the delivered message, check the Authentication-Results header for spf=pass and dkim=pass on your own domain. That is the check the receiving side actually ran.
5. Watch the provider dashboard. Bounces and complaints only become data once a provider is sending for you.

How to stop it recurring

Send through a provider that reports back, and alert on its bounce and complaint rates instead of waiting for a customer to say the receipt never came. Monitor the transactional-emails log for Failed entries. Keep WP-Cron on a per-minute system schedule so queued mail is never traffic-dependent. Test plugin and theme updates on staging with a real test order — that is where template overrides and wp_mail() conflicts surface. And read DMARC reports monthly; authentication degrades quietly when a provider rotates keys.

How Urumi handles this

Missing order emails are a support-ticket failure: nothing errors, the store looks healthy, and you hear about it from a customer. Platform-level monitoring shortens that. On Urumi the managed APM covers the background queue and the transactional-email log alongside web requests, so a spike in Failed sends, a stalled queue, or a checkout that stops advancing orders past Pending payment raises an alert rather than a ticket. It does not replace a transactional provider — you still need one — it just makes the failure visible while it is small. Do Amore migrated to Urumi with zero downtime and every custom plugin intact, email flows included. Detail on the managed WooCommerce platform page.

Frequently asked questions

Why are my WooCommerce order emails not sending?

Most often the host's PHP mail() function is failing or being blocked, since WooCommerce sends through WordPress's wp_mail(). Check WooCommerce → Status → Logs under the transactional-emails source: a Failed entry points at the transport, while Skipped or Disabled points at your email settings.

How do I test if WooCommerce emails are working?

Run wp eval 'var_dump( wp_mail( "[email protected]", "Test", "Body" ) );' to test the transport in isolation, then place a test order with a mail logging plugin active to confirm the trigger fires. Send to at least two different mailbox providers, and read the Authentication-Results header on what arrives.

Do I need an SMTP plugin for WooCommerce?

For any store taking real orders, yes. WooCommerce's documentation recommends a dedicated SMTP provider that sends the email for you, because the default path gives you no authentication, no bounce data, and no evidence a message was accepted.

Why do WooCommerce emails go to spam?

Usually a From address that does not match your site's domain, or missing authentication. Gmail requires SPF or DKIM from all senders and SPF, DKIM, and DMARC from senders of over 5,000 messages a day, with the From domain aligned to one of them.

If mail failures came alongside slow checkout or timeouts under load, the root cause is capacity rather than configuration — see why WooCommerce slows down under load and what managed WooCommerce hosting must include.

Last reviewed September 2026. Competitor details come from their public pages on the dates linked; check them before you buy.