WooCommerce Order Emails Not Sending? Here's the Real Fix

A customer places an order, the payment clears, and WooCommerce shows "Processing" right there in the admin — but nobody gets an email. Not the customer, sometimes not even you. If you've been staring at Settings > Emails wondering why everything looks "enabled" and nothing arrives, this one's for you.

The Symptom

You'll usually see one of these patterns:

• New orders appear in WooCommerce > Orders, but the customer never gets a confirmation.
• The store owner's "New order" notification stops arriving, even though customer emails work fine.
• Emails worked for weeks, then quietly stopped after a plugin or theme update.
• Some order statuses send email (Processing) but others don't (Completed, Refunded).

None of this throws a visible error on the checkout page — the order still goes through. That's exactly what makes it easy to miss until a customer emails you asking where their receipt is.

Why This Happens

WooCommerce doesn't send its own email — it hands the job to WordPress's wp_mail(), then queues the actual sending through Action Scheduler. That's two separate places things can quietly break.

1. An email type is disabled or misrouted

It sounds obvious, but it's the single most common cause. Go to WooCommerce > Settings > Emails and check each type individually — "Processing order," "Completed order," "New order" (this one goes to the admin, not the customer). A plugin update can silently reset a toggle, or a "recipient" field can get overwritten with a blank value during an import or migration.

2. Action Scheduler is backed up or stuck

Order emails fire from scheduled hooks like woocommerce_order_status_changed. If your Action Scheduler queue (WooCommerce > Status > Scheduled Actions) has a large backlog of "pending" or "failed" jobs, new email actions get stuck in line behind them. On busy stores with a lot of plugins hooking into checkout, this queue can grow faster than WP-Cron clears it — especially if WP-Cron itself is disabled or your site gets very little organic traffic to trigger it.

3. A conflicting SMTP or logging plugin

If you've got WP Mail SMTP, Post SMTP, FluentSMTP, or a security plugin all trying to hook wp_mail, only one of them actually wins. The others go silent without warning. This gets worse after a plugin update changes hook priority.

4. PHP mail() with no relay configured

If nothing is configured to use authenticated SMTP, WordPress falls back to PHP's built-in mail() function, which hands off to your server's local Exim/Sendmail. On shared cPanel hosting this often works fine — until the receiving mail server (Gmail, Outlook) starts rejecting it because the envelope sender doesn't match your domain's SPF record.

5. A third-party plugin unhooks the email action

PDF invoice plugins, order-bump plugins, and some custom checkout tweaks call remove_action() on WooCommerce's email hooks to replace the default template — and occasionally do it wrong, removing the hook without re-adding it.

6. It's not "not sending" — it's landing in spam

Worth ruling out early: if SPF, DKIM, or DMARC on the sending domain are misaligned, some providers deliver to spam or junk folders rather than bouncing. It looks identical to "no email" from the customer's side.

How to Fix It

Step 1 — Confirm the email type is actually on

In WooCommerce > Settings > Emails, click into the specific email type that's missing and check the "Enable this email notification" box. While you're there, use the built-in preview/send-test option if your WooCommerce version has one, so you're testing the template in isolation from checkout logic.

Step 2 — Check the Action Scheduler queue

Go to WooCommerce > Status > Scheduled Actions and filter by "Pending" and "Failed." If you see a growing backlog, the queue is the bottleneck, not the email settings. Clear it from the command line if you have SSH access:

wp action-scheduler run --hooks=woocommerce_order_status_changed
wp cron event run --due-now

If WP-Cron is disabled in wp-config.php (define('DISABLE_WP_CRON', true);), make sure a real system cron job is calling wp-cron.php at least every few minutes — otherwise nothing in that queue ever fires on its own.

Step 3 — Install a mail logger, temporarily or permanently

WP Mail SMTP's free logging feature (or WP Mail Logging) shows you every attempted send and whether it succeeded or failed at the PHP level. This tells you in seconds whether the problem is "WordPress never tried to send this" versus "WordPress sent it and something downstream dropped it."

Step 4 — Switch to authenticated SMTP

If the log shows send attempts failing, stop relying on PHP mail(). Configure WP Mail SMTP (or similar) with real SMTP credentials — either a cPanel mailbox on your own domain, or a transactional provider like SendGrid or Mailgun. Authenticated SMTP gives you a real delivery response instead of a silent drop.

Step 5 — Check deliverability on the server side

If you're on cPanel, open Email > Email Deliverability and confirm SPF, DKIM, and PTR all show as valid for the domain you're sending from. If you have SSH access, tail the mail log while placing a test order to see exactly what Exim did with the message:

tail -f /var/log/exim_mainlog | grep -i "order"

A line ending in a bounce or reject code is your answer — SPF alignment, a full mailbox, or greylisting are the usual suspects.

Step 6 — Isolate plugin conflicts

Deactivate PDF invoice, order-bump, or custom email-template plugins one at a time, placing a test order after each deactivation. If email starts working again, that plugin is either unhooking the WooCommerce email action or throwing a PHP error mid-template that kills the send silently.

Quick Reference

Preventing This Going Forward

• Use authenticated SMTP from day one instead of leaving WordPress on PHP mail().
• Keep a mail logging plugin active permanently — it costs nothing and saves an hour of guessing the next time this happens.
• Check Scheduled Actions occasionally on high-traffic stores; a growing "failed" count is an early warning sign, not just noise.
• Re-test all order email types after every WooCommerce core or checkout-plugin update.
• Keep SPF and DKIM records aligned with whatever service actually sends your mail — if you switch from cPanel mail to SendGrid, update SPF to include it.

Order emails are one of those things nobody notices until a customer is asking "where's my receipt?" A five-minute test order after any change to your email or checkout plugins is cheap insurance against that conversation.