SMTP test works.
WooCommerce emails do not?

By OrderEmailFix · Reviewed October 10, 2026

Separate three different tests

WooCommerce's email settings documentation describes preview testing. WordPress also cautions that a successful mail-function result does not prove receipt. Compare the same notification and recipient wherever possible.

Confirm the expected order event

Record the email you expected: an admin New order alert, customer Processing order message, or customer Completed order message. Check the relevant notification's enablement rather than changing every email setting.

Inspect the affected order and its notes. Pending payment means payment has not been recorded; Processing generally means paid and awaiting fulfillment; On hold can mean payment confirmation is pending. Some virtual, downloadable orders bypass Processing. Match the expected message to the actual workflow using the official order-status guide.

If payment succeeded at the gateway but the order did not update, investigate its payment notification or status transition. Working SMTP cannot repair that missing event.

Find the order attempt, not the test message

On versions that support native email logging, open WooCommerce → Status → Logs and inspect transactional-emails for the order and email type. Disabled means the notification is off; Skipped indicates a missing condition; Failed records a sending error; Sent means successful handoff to the mail system. These outcomes are explained in WooCommerce's troubleshooting documentation.

Before concluding there was no attempt, check log enablement, date, retention, and severity threshold. Older installations may need a WordPress mail logger or provider logs. A password-reset message or SMTP test may not appear in WooCommerce's transactional log.

Follow the message into the sending provider

Search provider activity for the exact recipient and time. Check the selected account or message stream and distinguish your test from the checkout message. With Postmark, an absent API message requires checking the original API response; an SMTP connection failure can occur before message data reaches the service. Its missing-message guide explains those cases.

If activity shows a bounce, delay, or rejection, preserve the response and investigate that condition. If it shows delivery, inspect the recipient's mailbox handling instead of assuming the checkout trigger failed. Use our spam guide for sender and authentication checks.

If the checkout event fails before sending

Open the matching fatal-errors log and compare its timestamp with checkout. WooCommerce's error-log documentation explains what is captured; it does not cover every server timeout. A file named in a trace is evidence to investigate, not automatically the root cause.

Back up the site and reproduce the same workflow on staging before testing theme or plugin conflicts. Restore components methodically and retest after each relevant change. Follow the official conflict-testing process; do not disable a busy store's plugins as a first experiment.

Verify the affected flow after a correction

Use a staged order and the gateway's sandbox mode, recording the status, expected email, log outcome, and receipt. Test orders can trigger connected integrations. A preview or manual resend arriving is useful, but repeat checkout if automatic checkout notification was the original problem.

For a repair request, include your store URL, WooCommerce version, sending provider, which test succeeds, which notification fails, and redacted error evidence. Never include login passwords or API credentials in the initial description.