Order Is Confirmed, but the Customer Never Received the Email—How to Trace It

The checkout says the order is complete, the payment may already be captured, and the order appears in the store dashboard—but the customer never receives a confirmation email. Sending the message again can solve the immediate support request, but it does not explain whether the original notification was never created, failed during sending, or was rejected after it left the store.

The reliable way to diagnose this problem is to trace one order through four checkpoints: order state, notification event, mail service and recipient mailbox. Each checkpoint produces different evidence and requires a different fix.

Use a real test order with a mailbox you control. Record the order number, customer address, order status, payment status, checkout time and expected notification. Avoid changing templates, DNS and plugins at the same time; that destroys the evidence needed to find the first failure.

Confirm the order exists before troubleshooting email

Open the store's order dashboard and find the exact transaction. If no order record exists, the email system may have had nothing to confirm. A successful payment authorization does not always prove that the order-creation step completed.

Check whether the order is paid, pending, failed, canceled, on hold or incomplete. Many stores send different notifications at different status transitions. A message expected after payment may not be generated while the order remains pending.

If money was captured but the order record is missing, stop here and follow our payment-successful-but-no-order diagnostic. Email troubleshooting cannot repair a missing commerce event.

If the order exists, confirm that the customer email stored on the order is complete and correctly spelled. Compare it with the address the customer intended to use. Browser autofill, guest checkout typing errors and copied spaces can direct a perfectly delivered message to the wrong mailbox.

Determine whether one customer or every customer is affected

Place test orders using addresses at two unrelated mailbox providers, such as a business-domain mailbox and a consumer mailbox. If only one destination fails, the store probably generated and sent the message; recipient filtering, suppression or address reputation becomes the stronger lead.

If every destination fails, inspect the notification configuration and sending path. Also compare customer confirmations with admin notifications. If the store owner receives an order alert but the customer does not, the shared order event works and the problem is likely specific to the customer template, recipient field or automation.

Record when the failure began. A clear start time often connects it to a template edit, plugin update, SMTP change, DNS change, new sending domain, automation change or checkout customization.

Verify that the confirmation notification is enabled

Open the store's email or notification settings and confirm that the order-confirmation message is active. Do not assume a default notification remained enabled after a migration, automation cleanup or template redesign.

Check the trigger, not just the template. The event might be defined as order placed, payment received, order processing or another status. Compare that trigger with the test order's actual timeline. A valid template tied to the wrong event will never run.

If conditions are attached, inspect country, product, sales channel, payment method, customer type and order-value filters. Temporarily test with the simplest eligible order rather than deleting production conditions.

Use the platform's preview or test-email feature only to validate template rendering and sender access. A test email does not prove that a live order triggers the automation or supplies every required variable.

Inspect the notification or automation history

Look for an automation run, notification timeline entry, transactional-email log or private order note for the exact order. The useful states are not generated, skipped, queued, sent, deferred, bounced or failed.

No record usually points back to the trigger, order status, missing recipient or disabled notification. A failed record points to the sending service or template. A sent record means the platform handed the message to another system; the next investigation belongs to delivery, authentication and the recipient mailbox.

Capture the timestamp, message identifier and error text without copying payment details or unnecessary customer data. Those values allow your platform or email provider to trace a single message across systems.

Check whether template changes broke generation

Transactional templates use dynamic fields for customer name, order number, products, totals, addresses and links. Removing required blocks or damaging template syntax can stop generation or produce incomplete messages. If the problem began after editing, compare the current template with the default.

Restore or duplicate the original template in a controlled test. Keep branding changes outside protected dynamic sections. Verify that the sender address, reply-to address, subject and recipient field all resolve to valid values.

Pay special attention to custom code that replaces the platform's standard confirmation. A custom webhook or automation must handle retries, duplicate events and temporary provider failures. Logging only the initial request is not enough; record the final provider response.

Separate sending from delivery

A dashboard status of sent usually means the commerce platform or website passed the message to a mail system. It does not guarantee inbox placement. Check the SMTP or transactional-email provider's activity log for accepted, delivered, deferred, bounced, blocked, suppressed or complained status.

If the address is suppressed, find out why before removing it. Repeated hard bounces, spam complaints and invalid addresses are legitimate reasons to stop sending. Removing suppression without correcting the cause can damage the sending domain's reputation.

If the provider accepted the message but shows no delivery event, use its message ID when contacting support. If it shows delivered, ask the recipient to search All Mail and check Spam, Junk, Promotions, Quarantine and mailbox rules.

Validate the sender domain and authentication

For WordPress and custom sending setups, use a From address on a domain you control. Sending from a public mailbox address through an unrelated web server creates an identity mismatch that can be filtered or rejected.

Confirm that the domain's SPF record authorizes every service that sends on its behalf. Check DKIM signing and verify that DMARC alignment matches the visible From domain. Do not publish a second independent SPF record; combine authorized senders into one valid policy according to your email provider's instructions.

After DNS changes, send a fresh test and inspect the received message headers for SPF, DKIM and DMARC results. Authentication improves trust but does not guarantee delivery, so continue to content, reputation and recipient filtering if all three pass.

Platform-specific checks

Wix Stores

Wix Stores sends customer emails through Wix Automations. In Checkout settings, open Emails & Notifications and confirm that Order confirmation is active. Place an actual test order; Wix suggests temporarily using a manual payment method when you need to avoid a real charge.

If a template edit caused the issue, inspect the Send an email action and consider resetting the template to its default version. Do not remove highlighted dynamic sections that Wix uses to insert products, prices and order details. If your test receives mail but the customer does not, ask them to check Spam, Junk and Bulk folders or consult their email host.

Shopify

Open the order timeline and locate the confirmation notification. Shopify allows the order email to be resent to the customer or sent to yourself as a copy. This is useful both for recovery and for comparing whether the same generated message reaches different providers.

If notifications are missing across customers, inspect recent template edits and sender configuration. If only one provider fails, test an alternate email address and review the original mailbox's filtering. Remember that a resend succeeding does not explain why the first attempt failed; retain both timeline entries.

WooCommerce

In WooCommerce, confirm that the relevant customer email is enabled under Settings and that the order reaches the status that triggers it. Then open WooCommerce Status logs and inspect the transactional-emails source for the test order.

A Sent entry means WooCommerce handed the email to the site's mail system. Failed, Disabled and Skipped entries point to different repairs. A missing log entry suggests the trigger never ran or a conflict interrupted execution. WooCommerce uses WordPress mail by default, so hosting mail configuration or an SMTP provider may control the next step.

For a broader comparison with non-commerce submissions, see our contact-form delivery troubleshooting guide. It explains how to distinguish form storage, notification generation and inbox delivery.

Test the customer experience, not only the email

A confirmation email should not be the customer's only proof of purchase. The checkout success page should show a clear order number and next steps. Signed-in customers should be able to see the order in their account, and support staff should be able to retrieve it without asking for payment details.

Do not tell customers to place the order again until you have checked the order and payment records. A missing email can lead to duplicate purchases when the original order is already valid.

If checkout itself offers no way to pay, resolve that earlier failure with the missing payment-methods guide.

If a coupon or promotion changes the order unexpectedly, preserve that cart and use the rejected coupon-code diagnostic before repeating the transaction.

Run a complete acceptance test

Test guest and signed-in checkout, immediate and delayed payment, physical and digital products, refunds, shipping updates and canceled orders. Use at least two recipient providers. Confirm that each event generates the correct notification once and that links, totals, taxes, addresses and product details are accurate.

Review mobile rendering, plain-text fallback, reply-to behavior and accessibility. Keep the subject descriptive, use a recognizable sender name and avoid promotional language that makes a transactional message look like an advertisement.

After the fix, monitor bounces, deferrals and complaints for several days. Document the exact cause, the setting changed, the test order and the provider result. This turns a one-off rescue into a repeatable release check.

Trace the first missing handoff

The fastest diagnosis follows the message in order: valid order, correct status, enabled notification, successful generation, accepted send, authenticated domain and recipient delivery. Stop at the first missing handoff. That is where the repair belongs.

If confirmations remain inconsistent after these checks, contact Webcurry for an ecommerce notification review. Bring one order number, its timeline, the intended recipient and any provider status so the investigation can begin with evidence.