WooCommerce order emails not sending: what I check first

Someone has paid. The order sits on Processing or Completed in WooCommerce. The customer never got a confirmation, or you never got the new-order alert. That is the classic silent-email panic, and it is usually fixable without rebuilding the whole store.

I treat missing order emails as a checklist, not a mystery. Below is the order I work through on live Woo shops when mail has gone quiet.

Confirm WooCommerce emails are actually enabled

Start in WooCommerce → Settings → Emails. Open each relevant template (New order, Processing order, Completed order, Customer invoice) and check it is enabled. A toggle gets flicked during a migration or a "temporary" test more often than people admit.

While you are there, confirm the From name and From address look sensible. A random wordpress@ host address is a spam magnet. I prefer a real mailbox on the shop domain, even if SMTP will handle delivery later.

Use Woo's own "preview" or a test order to a mailbox you control. If preview works but live orders stay silent, the problem is usually delivery or a status mismatch, not the template HTML.

Match order status to the email type

Woo only fires certain emails when an order hits a matching status. Payment plugins sometimes leave orders on Pending or On hold when you expect Processing. Custom status plugins add their own names, and stock emails never listen to those.

I open the order notes and check the status trail. If the order never passed through Processing, the customer Processing email never had a reason to send. Same story for Completed when fulfilment plugins skip that step.

• Pending payment: often no customer "order received" flow you expect
• On hold: common with BACS or manual review
• Processing: usual paid-and-ready path for physical goods
• Completed: often used for digital or auto-fulfilled items

If a plugin changes status via a custom hook, the core email may never run. That is a code or plugin issue, not "email is broken".

SMTP plugin versus bare PHP mail

Shared hosts still allow PHP mail(), but deliverability is rough. I almost always put FluentSMTP, WP Mail SMTP, or similar in front with a proper provider (Amazon SES, Mailgun, Postmark, Google Workspace SMTP).

Check the SMTP plugin log for the exact order timestamp. A green "sent" in the plugin means WordPress handed the message off. A hard bounce or auth error means credentials, blocked ports, or a quota problem.

If there is no SMTP plugin and the host blocks outbound port 25/465/587, Woo will look fine while nothing leaves the server. That is a hosting ticket, not a WooCommerce setting.

Spam folders and blocked sending hosts

Ask the customer (and yourself) to check spam and promotions. Then check the domain's SPF, DKIM, and DMARC if you control DNS. Order mail from a mismatched From domain fails quietly at big inboxes.

Some hosts rate-limit or blacklist abusive shared IPs. If every site on the box suddenly stops landing in Gmail, the IP reputation is toast. SMTP through a dedicated ESP sidesteps that mess.

Theme or plugin conflict after an update

After a Woo, theme, or mail-related plugin update, email hooks can break. Typical culprits: custom email templates in a child theme, "improve Woo emails" plugins, membership add-ons, and old code that plumbs woocommerce_email filters incorrectly.

My quick isolation path on a staging copy:

1. Switch to a default theme briefly
2. Disable non-essential plugins, keep Woo and the SMTP plugin
3. Place a test order
4. Re-enable in small batches until mail stops again

If mail returns with a default theme, the child theme template override is the suspect. If it returns after disabling a plugin, that plugin's email customisation needs a proper fix, not another "temporary" patch.

Action Scheduler and failed queued emails

Woo queues a lot of work in Action Scheduler. Failed or stuck actions mean emails never leave the queue. In WooCommerce → Status → Scheduled Actions, filter for failed or pending items around woocommerce_email or order hooks.

A stuck cron (disabled WP-Cron on a host that never hit the real system cron) leaves actions Pending forever. Check that the site's cron is actually running. Retry failed email actions after you fix SMTP or the conflicting plugin, then place a fresh test order rather than assuming an old queue item will magically recover.

When to stop guessing

If settings are enabled, status matches the template, SMTP logs show a clean handoff, DNS looks sound, and Action Scheduler is clear, stop shotgun-disabling plugins on production. At that point you want logs, a staging clone, and someone who has seen the weird edge cases (custom order statuses, headless checkouts, or email content filters eating the message).

Most silent order emails come down to a disabled template, a status that never fired the right hook, or SMTP that never authenticated. Work those three first, then spam and queue. Cheers, and get that confirmation landing where it should.