Fix WooCommerce order and low‑stock email delivery

If customers or staff aren’t seeing order confirmations or low‑stock alerts, the quickest reliable route is: 1) confirm WooCommerce is configured to send to the right addresses, 2) confirm WordPress actually generated the message, and 3) inspect delivery headers to see whether the message left your server or was rejected. Only after you can prove generation and a failed hand‑off should you change the mail transport (for example, enabling an authenticated SMTP relay).

Contents

Understand the layers that affect email
Check WooCommerce templates and recipient settings
Confirm WordPress generated the email (use a log)
End‑to‑end test and capture full headers
When to switch to an authenticated SMTP relay
Stock‑notification checklist and simulation
Host and recipient logs: what to request
Safety and limits

Understand the layers that affect email

Three distinct layers control whether a notification reaches an inbox: the template and recipient settings inside WooCommerce; WordPress handing the message to the server via wp_mail(); and the server/outbound transport plus recipient filters and authentication checks (SPF/DKIM/DMARC). The WooCommerce email settings page is where you control templates and recipient addresses, while wp_mail() documents how WordPress hands mail to the host. Deliverability and inbox placement are then governed by authentication and the sending infrastructure; WooCommerce’s email authentication guidance explains why branded authentication matters: Email authentication.

Check WooCommerce templates and recipient settings

Open WooCommerce → Settings → Emails and locate the notifications you expect (New order, Processing order, Low stock). Confirm each is enabled and that the recipient email address is correct; the official doc shows the exact screen and options: WooCommerce email docs.
Check the sender details (From name and From address) used by WooCommerce. A mismatched or generic sending address makes authentication harder later.
If you want to inspect or modify the message content, copy the template into your child theme instead of editing core files (the WooCommerce docs show the supported template override method).

Confirm WordPress generated the email (use a log)

Before changing how mail is delivered, confirm WooCommerce actually produced the message. Install an email‑logging plugin in your staging environment (for example WP Mail Logging), trigger the notification and check the plugin’s entry. The log proves wp_mail() was called and records message headers and the timestamp — essential evidence for the next step. The wp_mail() reference explains that a successful hand‑off from WordPress does not equal successful delivery, so the log is the critical proof of generation.

End‑to‑end test and capture full headers

Run the following safe test in staging and to an address you control (never use real customer addresses with live PII):

Set the email recipient for the specific notification to a personal inbox you control (temporarily) or add your address as a recipient in WooCommerce settings.
Place a test order (or change stock to trigger a low‑stock notice) in the staging copy so it does not affect live customers.
Open the received message in your mailbox and view the full/raw headers (Gmail: Show original). Save those headers and the Message‑ID and timestamp.
Inspect the headers for Received hops and authentication results (look for SPF/DKIM/DMARC results). A header chain that shows your site’s MTA handing the message to an authenticated relay — and SPF/DKIM passing — is what you want to see. If headers stop at your server with no outward hop or show authentication failures, delivery problems live between your server and the recipient.

Signs you can interpret quickly from headers: a) multiple Received lines showing onward delivery indicate the message left your host; b) an explicit “spf=pass” or “dkim=pass” helps deliverability; c) “spf=fail” or missing authentication is a reason to configure an authenticated relay. Use the WooCommerce authentication guidance when you interpret failing checks: Email authentication.

When to switch to an authenticated SMTP relay

If your logs show WordPress generated the mail but the headers reveal either no outward hop or failed authentication, configure an authenticated SMTP relay and retest. WooCommerce maintains guidance on recommended SMTP providers and why they reduce common delivery problems: SMTP providers for WooCommerce. Use a plugin/extension that supports authenticated connections and per‑message logs; WooCommerce’s SMTP & Email Logs extension documents those benefits: SMTP & Email Logs.

After you configure the SMTP relay, repeat the end‑to‑end test and re‑check headers and the SMTP provider’s dashboard for the delivery attempt and any error codes.

Stock‑notification checklist and simulation

Products → Inventory: confirm “Enable low stock notifications” is enabled and note the global Low stock threshold. (Product inventory docs.)
Per product: verify the product’s stock is managed (Manage stock = yes) and confirms the notification thresholds, or for variations, check the parent vs variation stock entries.
Confirm notification recipient(s) include the addresses you expect (site admin and any shared inbox).
Simulate the trigger in staging by lowering stock below the threshold and check the WP Mail Logging entry and the received headers as described above.

Host and recipient logs: what to request

If you’ve captured Message‑ID and timestamp but the SMTP provider or your mailbox shows no delivery attempts, request the following when contacting your host or the recipient’s mail admin:

From your host: outbound MTA logs for the precise timestamp/Message‑ID you recorded, and whether the host’s MTA accepted/queued or rejected the message. Hosts will need the exact timestamp and Message‑ID to locate the entry.
From the recipient’s mail admin: acceptance/quarantine/rejection logs tied to your Message‑ID or sending address and the exact timestamp. Without those logs you cannot prove acceptance or quarantine on the recipient side.

These are host‑level artifacts; you must obtain them from the relevant administrators. The evidence you captured earlier (mail log entry, raw headers, Message‑ID and timestamp) is what makes such requests actionable.

Safety and limits

Always test with inboxes you control. Never send customer PII to test addresses you do not own.
Do not expect guaranteed delivery: deliverability depends on authentication, sender reputation and recipient filters. The documentation on authentication explains the main controls you can change: Email authentication.
Host‑specific outbound limits and mail‑server configuration vary. If you suspect host throttling or blocking, ask your host for guidance and their documented outbound limits rather than applying universal numeric thresholds.

Quick safe test (one‑page checklist)

In staging, add your personal inbox as the notification recipient in WooCommerce → Settings → Emails.
Install WP Mail Logging (plugin), trigger the notification and confirm the log entry exists.
Open the message in your mailbox and view the full headers (Gmail: Show original), save raw headers and Message‑ID.
If headers show authentication failures or no outward hops, configure an authenticated SMTP provider (see recommended providers) and repeat the test.

Imagine a simple hypothetical test: you trigger a low‑stock alert and the WP Mail Logging shows wp_mail() ran at 14:02 (Message‑ID <12345@example.com>). You open your Gmail, choose “Show original” and see the header chain stops at your host with “spf=neutral” and no onward Received lines — that points to your host’s outbound delivery or authentication as the problem, not WooCommerce templates. That is the exact moment to enable an authenticated relay and retest.

Finish by recording the evidence: the WP Mail Logging entry, the saved raw headers, Message‑ID and the staging URL and the timestamp. Those items let host or SMTP support locate the exact transaction if you need to escalate.

Configure and test WooCommerce order and low‑stock emails