WooCommerce email notifications are part of the store’s operational workflow, but configuring a template does not by itself prove that a message will reach an inbox. A store may have correctly written subjects and headings while an email remains disabled, is not triggered by the expected order status, or is affected by the hosting mail system, authentication or recipient-side filtering.
The main configuration area is WooCommerce > Settings > Emails. From there, store owners and implementers can review notifications, define the sender identity, adjust shared design settings, customize individual messages, preview desktop and mobile layouts, send a test email and investigate transactional-email logs. The most reliable approach is to treat these as separate steps: first match notifications to the store’s workflow, then test both appearance and delivery behavior.
What WooCommerce email notifications do
Administrative and customer-facing messages
WooCommerce built-in transactional messages generally serve two connected purposes. Administrative notifications help the store team respond to events affecting order handling. Customer-facing messages communicate order progress, refunds, account actions and other stages of the customer relationship.
Administrative examples include New order, Cancelled order and Failed order. Customer messages can include Processing order, Completed order, Refunded order, Customer note, Reset password and New account. These names describe available notification types, not a universal checklist that every store must enable.
Extensions, themes and custom code may add notifications or settings. Consequently, the email screen should be reviewed in the context of the store’s payment methods, order statuses, fulfillment process, account usage and installed extensions. The practical question is not how to activate every possible message, but which messages support a real operational or customer-communication need.
Which notifications to review before launch
Build the list around actual store workflows
Begin by mapping the store’s order process. Ask which events require a store team member to act and which events should be communicated to the customer. This produces a more useful configuration than copying a fixed list, because the appropriate notifications depend on how orders move through the store.
For store operations, review New order, Cancelled order and Failed order. A new order may require fulfillment attention, while a cancellation or failed payment may require a different response. Check the recipients for administrative notifications, since these messages can expose recipient settings and commonly default to the site administrator email for applicable store-management messages.
For customers, review messages that match the order lifecycle, including Processing order, Completed order and Refunded order. Consider Customer note when the store uses notes for customer communication. Also review Reset password and New account if customers create or manage accounts.
- Review: match each administrative alert to an action the store team actually performs.
- Consider enabling: customer messages that correspond to the store’s order and account stages.
- Disable when unsuitable: messages that do not match the store’s process, payment flow or customer-account usage.
- Recheck extensions: additional notifications may be supplied by installed extensions, themes or custom code.
After making changes, test the expected status transitions rather than assuming that a notification will be generated for every order. A pending-payment order, for example, may not produce the message expected for a later status. Notification selection should therefore remain a workflow decision, not a claim that one set is mandatory for every store.
Configure the WooCommerce email sender identity
From versus Reply-to
In WooCommerce > Settings > Emails, configure the visible sender through the From name and From address fields. The name identifies the store or sending identity in the recipient’s mail client, while the address is the sender address associated with the message.
WooCommerce recommends using an email address on the store’s domain. This keeps the visible sender aligned with the website’s identity and provides a clear basis for reviewing domain authentication. If replies should go to another operational inbox, configure the separate Reply-to name and Reply-to address when that option is available.
From and Reply-to are not the same setting. The From fields define the sender identity presented by the message; Reply-to can direct responses to a different address. After saving these values, review the sending domain and mail-system configuration with the relevant host or mail provider. Authentication checks may include SPF, DKIM and DMARC, where applicable.
Correct sender fields do not guarantee inbox placement. Avoid using a spoofed or unrelated public-domain From address, and do not treat a successful test send as proof that every recipient will receive the message.
Customize the global WooCommerce email template
Shared appearance versus notification content
Shared template settings control the visual foundation used across WooCommerce emails. Depending on the available settings, you can configure a logo, footer text and colors. When Email improvements is enabled, additional controls can include logo width, header alignment and font family.
These global settings should be considered separately from the content of a particular notification. A logo or color change affects shared presentation, while a subject, heading or additional message belongs to an individual email. Reviewing the global appearance first helps maintain a consistent baseline before making notification-specific edits.
Global styling is also not a substitute for delivery testing. A polished template can still be disabled, skipped because of an order workflow, or affected by the site’s mail system. Treat design review and delivery diagnosis as related but separate checks.
Customize an individual WooCommerce order email
Per-email controls and message formats
To edit one notification, open WooCommerce > Settings > Emails, select the relevant email and choose Manage. The exact controls depend on the selected notification. Administrative and customer-facing emails do not necessarily expose the same recipient options.
Depending on the email, the editing screen can include an enable or disable control, recipients, subject, email heading, additional content, email type, Cc and Bcc fields. Administrative messages may expose configurable recipients, while customer-facing messages generally do not use the same recipient configuration. Review each screen instead of assuming that settings from one email apply to another.
Use the subject and heading to make the message’s purpose clear. Additional content can provide notification-specific information alongside the standard transactional content. Where supported, placeholders can be used for site and order data, but they should be reviewed in the context of the selected email rather than copied without checking.
WooCommerce supports Plain Text, HTML and Multipart email types. Choose the format according to the message and the store’s communication requirements. Plain-text fields have character limitations, and long product names or variations may be truncated. Preview the final result after changing the format or adding longer content.
Cc and Bcc should be configured only when those fields are available and there is a clear operational reason. Keep customer data protected when documenting settings or taking screenshots; do not expose customer email addresses in examples, test documentation or incident notes.
Preview and send a WooCommerce email test
A practical pre-launch test sequence
WooCommerce provides an Email Preview section where you can choose a store email and inspect its desktop or mobile rendering. Use both views when available, because a layout that appears acceptable on a wide screen may require a different review on a smaller display.
Next, use Send a test email with a controlled test address. Individual email editing screens can also provide preview and test controls. Check the visible sender name and address, the Reply-to behavior, subject, heading, additional content, branding and selected format. This test is useful for rendering and for confirming that WooCommerce can make a sending attempt.
- Preview the selected email in desktop and mobile views.
- Send a test message to a controlled address.
- Check formatting, sender identity and reply behavior.
- Trigger a realistic test order or status change where transactional behavior must be verified.
- Compare the result with the notification’s enabled state and expected recipients.
A test email or successful handoff does not guarantee inbox delivery for every recipient. Authentication, hosting, SMTP configuration, recipient-side filtering and sender reputation can affect the final result. Keep template rendering checks separate from those delivery checks.
Troubleshoot WooCommerce emails that are missing or not received
Read the transactional-email log before changing infrastructure
When a WooCommerce email is missing, first identify which part of the process failed. The problem may involve configuration, message generation, the site’s mail system or the recipient’s inbox. Changing infrastructure before checking the notification and order workflow can obscure a simple disabled or skipped message.
Start by confirming that the order status should trigger the expected notification. Then confirm that the notification is enabled and that applicable administrative recipients are configured. If the status is still pending or otherwise different from the expected trigger, the relevant customer or administrative email may not have been generated.
For a recorded attempt, inspect WooCommerce > Status > Logs and use the transactional-emails source. The log can show statuses such as Sent, Failed, Disabled or Skipped. These entries help distinguish an email that was not meant to send from one that encountered a sending problem.
Disabled or Skipped points back toward notification state or workflow conditions. A Failed result supports checking the site’s mail system, hosting configuration or SMTP setup. A Sent result indicates a sending attempt or handoff, not proof of inbox placement. Continue by checking spam filtering and the receiving side.
WooCommerce generates the email content and passes it through WordPress’s wp_mail() process. Actual delivery can depend on the hosting mail system or an SMTP provider. If configuration appears correct, review the branded sending domain and authentication instructions with the relevant provider, including SPF, DKIM and DMARC where applicable. Treat an SMTP or delivery-service change as an implementation option, not as a universal solution or endorsement.
Protect customer data while inspecting logs and documenting incidents. Use controlled test addresses, avoid publishing raw recipient information and diagnose the expected order status and notification state before replacing plugins or changing infrastructure.
WooCommerce email notifications are easiest to manage as a workflow rather than as isolated template fields. Review administrative and customer messages against the store’s real order and account processes, then configure a domain-based sender and a separate Reply-to address when needed. Keep shared branding distinct from individual subjects, headings, content and recipients.
Before launch, preview desktop and mobile layouts, send a controlled test and verify a realistic order or status transition. If a message is missing, check its trigger, enabled state and transactional-email log before investigating hosting, SMTP or authentication. Remember that a successful send attempt is not a guarantee of inbox delivery. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.