First, separate an order problem from an email problem
Open the exact order and read its status, payment method, billing email and private order notes. WooCommerce explains that unpaid Pending payment orders do not trigger the same customer emails as an order that has reached Processing or Completed. If the customer was charged but the order is still pending, the job is not simply to resend an email: it may be a payment gateway or order-status handoff problem.
A clean starting question is: did the store create the right order, did payment reach the right state, and then did WooCommerce try to notify the right person? That keeps a customer-support message from accidentally masking a checkout issue.
- Confirm the order number, status and customer billing email address.
- Check the payment method and order notes before manually changing an order state.
- If payment evidence and the WooCommerce state disagree, preserve the evidence and investigate the handoff first.
Check which WooCommerce email should have been sent
WooCommerce has different emails for different moments. New order is normally for the store team; customers receive messages tied to their order state, such as processing, completed, refunded or an order-details/payment-link message sent manually. Go to WooCommerce > Settings > Emails and open the specific notification you expect. Check that it is enabled and that its recipient rules make sense for that order type.
Do not use a generic “confirmation” label as evidence. A physical-product order can remain Processing while fulfilment is under way, whereas a virtual or completed order follows a different customer path. The right test is whether the email configured for that status was enabled and eligible to send.
Use the transactional-email log to find the actual failure point
WooCommerce records its transactional email attempts. Create a controlled test order only if it is safe for the store, then open WooCommerce > Status > Logs and filter for transactional-emails. Match the log entry to the order and email type. WooCommerce labels attempts as Sent, Failed, Disabled or Skipped, which is far more useful than guessing from an inbox.
Sent means WooCommerce handed the message to the site mail system; it does not prove the customer received it. Failed means the mail-sending process returned an error. Disabled means the notification was switched off. Skipped usually means a required condition, such as a recipient, was missing. If no entry exists when one should, check fatal errors and plugin or theme conflicts in a safe test environment rather than disabling production components at random.
If WooCommerce sent it, investigate delivery—not the order
A Sent status shifts the question from WooCommerce to deliverability. Ask the customer to check spam and the exact billing email used at checkout. Then check that the From address uses the store’s own domain rather than a personal Gmail or Yahoo address. WooCommerce warns that a public-domain From address can be filtered or blocked because the sending server and declared sender do not match.
For a recurring business problem, use an authenticated transactional mail setup and review its delivery logs. Keep the change narrow: confirm the sender domain, authentication and mail-provider result. Do not change the customer’s order status just because an email went missing.
If the email failed, fix one layer and test the whole customer path
A Failed log usually points to the site’s mail-sending layer, hosting mail configuration or a conflict. Capture the error message, then have the technical owner check the relevant SMTP or mail-provider logs. Make one controlled change, run one real-looking test order or email preview, and confirm the resulting order status, transactional log and inbox outcome together.
Our view: order emails are part of the customer journey, not a cosmetic extra. A store can record payment correctly and still lose trust if the buyer has no receipt, order details or next step. The repair is complete only when the customer-facing message is working again.
Resend the right message without creating a second problem
Once the original order and email state are clear, use the relevant WooCommerce order action to send the correct customer message. For example, Order Details can share the invoice details and a payment link where that is appropriate. Tell the customer what you resent and what they should expect; do not make them wonder whether a duplicate charge or duplicate shipment is on its way.
Do not use a resend to paper over an unclear payment. If the order is Pending payment and the gateway record is uncertain, follow the payment evidence first. If the order is paid but the email was simply filtered, one clear resend and a support note is usually enough.
Set a simple operating rule for order-email incidents
For a single customer, keep a short incident note: order number, expected email, transactional-log result, delivery result and final customer message. For several missing emails after an update, gateway change or email-provider issue, treat it as a store incident. Pause unnecessary configuration changes, find the shared point of failure and test the repair on one controlled customer path before closing the issue.
This is where ongoing WooCommerce maintenance earns its place. The aim is not to make every store owner learn mail infrastructure. It is to make sure someone owns checkout, order status, customer emails and the verification after a fix—without quietly turning routine care into unlimited custom development.
Missing order email: what should you do next?
Choose the next move based on what the evidence shows, not on how urgent the inbox feels.
| What you find | Reasonable next move | Do not do this |
|---|---|---|
| Order is Pending payment | Check the payment and order-status handoff before expecting or resending a customer email. | Do not tell the customer payment succeeded or mark the order paid without evidence. |
| Transactional log says Disabled or Skipped | Enable the relevant email or fix the missing recipient/condition, then test one controlled order. | Do not send every customer a manual email while the notification remains misconfigured. |
| Transactional log says Failed | Capture the error and investigate the mail layer or conflict with the responsible technical owner. | Do not keep pressing resend or change live plugins blindly. |
| Transactional log says Sent, but customer has nothing | Check spam, billing address, sender-domain alignment and authenticated mail-provider delivery logs. | Do not change the order state to force a new message. |
| Several customers report missing emails | Treat it as an incident; isolate the shared change and test one repair end to end. | Do not assume each customer typoed their email address. |
Who should own the next move?
The owner should be able to see the order evidence and the customer impact.
Store owner
Handle one clear inbox or typo issue, resend the correct message once, and give the customer a simple next step.
Technical or email owner
Handle mail failures, sender authentication, delivery logs, plugin conflicts and any payment-to-order mismatch.
WooCommerce care team
Handle recurring incidents, controlled testing after a production change and the full checkout-to-email customer path.
Mistakes that turn a missing email into a trust problem
- Assuming a customer did not pay because they did not receive an email.
- Resending an email before checking whether the original order status and payment evidence are correct.
- Treating a Sent email log as proof the customer received the message.
- Changing live email, gateway or plugin settings while trying to solve one unclear order.
- Closing the ticket after a dashboard change without testing the actual customer inbox and order path.
The operator view
Order email failures are deceptively expensive. They create support work, make buyers doubt a legitimate purchase and leave fulfilment teams without a shared story. The reliable routine is unglamorous: prove the order state, prove the WooCommerce send attempt, prove delivery, then make the customer whole with one clear message.
- Keep payment, order-status and email evidence together in the incident note.
- Test the exact email that the relevant order status should trigger.
- Escalate patterns after a release or provider change instead of resolving them as isolated inbox tickets.
Frequently asked questions.
Why is WooCommerce not sending order confirmation emails?
Start by checking whether the order reached the status that should trigger the customer email and whether the relevant notification is enabled. Then review the WooCommerce transactional-email log. It can show whether the message was sent, failed, disabled or skipped. A sent message can still be filtered by the recipient’s inbox or a mail provider.
Does WooCommerce send an email for Pending payment orders?
Not necessarily. WooCommerce says unpaid Pending payment orders do not trigger the normal order emails. If a customer paid but the order is still pending, investigate the payment gateway or order-status handoff rather than treating it as only an email problem.
Where are WooCommerce email logs?
For WooCommerce transactional emails, go to WooCommerce > Status > Logs and filter for transactional-emails. Match the result to the order and email type. If the message was handed to your mail service but is not delivered, also check the SMTP or mail-provider logs.
Can I resend a WooCommerce order confirmation email?
Yes, but first confirm which email is appropriate for the order state and whether payment is clear. Use the order actions to send the relevant customer message once. Repeated resends can confuse the customer and do not fix a mail, payment or status problem underneath.
Can Superpress help when WooCommerce customer emails are not arriving?
Yes. Superpress can investigate the order, email trigger, mail delivery and customer path as part of WooCommerce care. Major mail-platform migrations, custom integrations or broader development stay clearly scoped rather than being assumed inside routine maintenance.
Research sources.
This guide was checked against current platform and search documentation before publication.