WooCommerce Emails: Are Your Customers Actually Receiving Them?

The Silent Problem

A customer places an order. They don’t receive a confirmation. They call. You check: the order is there, the payment went through, but the email never left.

This is one of the most common WooCommerce issues. According to the WooCommerce team themselves, over 1% of all their support interactions involve email troubleshooting (source: developer.woocommerce.com). And the worst part is that most merchants don’t even know their emails aren’t going out — until a customer complains.

Until now, diagnosing the problem required a third-party plugin (WP Mail Log, WP Mail SMTP, etc.) to capture sends and see what was failing. With WooCommerce 10.9, transactional email logging becomes native.

What WooCommerce 10.9 Changes

A new EmailLogger class hooks into four internal WooCommerce hooks:

woocommerce_email_sent fires after every transactional email dispatch, with a success/failure boolean. woocommerce_email_disabled fires when an email type is disabled in settings. woocommerce_email_skipped fires when WooCommerce skips a send for a technical reason (no recipient, for example). And wp_mail_failed, WordPress’s global failure hook, captures actual PHPMailer/SMTP errors (“SMTP connect() failed”, “Could not authenticate”, etc.).

Everything writes to WooCommerce’s standard logger (wc_get_logger()) under a new source, transactional-emails. It respects your store’s existing configuration: file or database handler, log level threshold, retention — whatever you’ve already set up in WooCommerce > Status > Logs.

Three Severity Levels

Each log entry uses a severity level that lets you filter quickly:

INFO — the email was sent successfully. In production, you probably don’t need to see these. If your store is configured to “errors only”, they won’t show up.

NOTICE — the email wasn’t sent, but intentionally. Either the email type is disabled in WooCommerce settings, or the recipient was missing. It’s not an error, it’s expected behavior.

WARNING — the email failed. This is what you care about. The log includes the actual SMTP error message, which lets you diagnose directly: wrong credentials, unreachable SMTP server, blocked port, etc.

Each entry includes a structured context:

[
    'source'     => 'transactional-emails',
    'email_type' => 'customer_processing_order',
    'status'     => 'sent', // or 'failed', 'disabled', 'skipped'
    'recipient'  => 'jdoe',  // username, never the email address
    'order'      => 12345,
]

Emails Also Show Up in Order Notes

Beyond logs, emails tied to an order now appear directly in the order notes (WooCommerce > Orders > select any order). You can see which emails were sent for that order and whether they succeeded or failed.

If you’ve moved to the WooCommerce block checkout, nothing changes here: post-order emails fire in exactly the same way, and logging captures them identically.

An interesting design choice: only emails that WooCommerce actually attempted to send show up in notes. Disabled or skipped emails (no recipient) don’t appear there, keeping the view clean. If you need that information, it’s in the logs.

Privacy First: No Email Addresses in Logs

The WooCommerce team made an important choice: no email addresses are written to logs. The recipient field contains the matching WordPress username (via get_user_by( 'email' )), or guest if the customer doesn’t have an account.

PHPMailer error messages sometimes contain the email address in plain text (“Could not send to [email protected]”). These messages go through a redact_emails() function that scrubs addresses before writing to the log.

This detail matters for GDPR compliance: your log files don’t contain personally identifiable data.

Real-World Diagnostic Scenarios

”My customer didn’t receive their order confirmation”

Go to WooCommerce > Status > Logs, filter by source transactional-emails and search for the order number. You’ll immediately see whether the email was sent (INFO), failed (WARNING) with the error message, or was disabled (NOTICE).

”Emails were going out, then they stopped”

Look for WARNING entries in the logs. If you see a series of “SMTP connect() failed” starting from a specific date, it’s probably a change on the hosting side or an expired SMTP password. The error message will tell you exactly what changed.

”I don’t know which emails are active”

Entries with the disabled status show you which email types you’ve turned off in WooCommerce > Settings > Emails. This is useful when taking over an existing store and trying to understand the current configuration.

Customizing the Behavior

Disabling Email Logging

If you’re already using a dedicated logging plugin or want to reduce log volume:

add_filter( 'woocommerce_email_log_enabled', '__return_false' );

Disabling for a Specific Email Type

add_filter( 'woocommerce_email_log_enabled', function( $enabled, $email_id ) {
    // Don't log new order emails (admin)
    if ( $email_id === 'new_order' ) {
        return false;
    }
    return $enabled;
}, 10, 2 );

Adding Information to the Log

The woocommerce_email_log_context filter lets you modify the context array before it’s written. If you want to add a custom field (the main product ID from the order, for example), this is where you do it:

add_filter( 'woocommerce_email_log_context', function( $context ) {
    if ( isset( $context['order'] ) ) {
        $order = wc_get_order( $context['order'] );
        if ( $order ) {
            $items = $order->get_items();
            $first_item = reset( $items );
            if ( $first_item ) {
                $context['main_product'] = $first_item->get_product_id();
            }
        }
    }
    return $context;
} );

What This Doesn’t Fix

Logging tells you what happened, not what will happen. If your SMTP server is misconfigured, the log will show you the errors — but it’s up to you to fix them.

The most common causes of email delivery failure remain the same:

Shared hosting that blocks wp_mail() or limits hourly sends. External SMTP services (SendGrid, Mailgun, Amazon SES) with expired credentials. SMTP plugins conflicting with other plugins — and every added extension has a cost, as I explain in my article on the impact of third-party scripts and plugins on WooCommerce. Misconfigured DNS (missing SPF, DKIM, DMARC records) causing emails to land in spam.

Native logging lets you detect the problem quickly. To fix it, you’ll often need a reliable external SMTP service and proper DNS configuration. More broadly, reliably-delivered emails are part of a properly optimized WooCommerce store, right alongside speed and stability.

Known Limitation

wp_mail_failed is a global WordPress hook. It fires for every wp_mail() failure on the site, not just WooCommerce ones. If another plugin’s email fails between the start and end of a WooCommerce send, the captured error could be attributed to the wrong email.

In practice, this is rare. And it only affects the human-readable error message — email_type and status are always accurate. The WooCommerce team has documented this limitation in the code.

The Takeaway

WooCommerce 10.9 adds a diagnostic tool that should have existed a long time ago. No more installing a third-party plugin just to know if your emails are going out. The logs are structured, privacy-respecting, and integrate into the existing logging system.

If you run a WooCommerce store, the first thing to do after updating to 10.9: check your logs over a few days. You might discover silent delivery failures that have been going on for months.

Having WooCommerce emails that aren’t going out and can’t figure out why? Request a free audit — I’ll diagnose the issue and recommend the right solution for your setup.