How WP Mail SMTP Broke My WooCommerce Order Emails and the Transactional Retry Fix I Used

If you’ve ever run a WooCommerce store, you know email notifications are the backbone of customer communications. Whether it’s confirming orders, sending invoices, or updating shipping statuses, missing emails can lead to confused, frustrated customers—and lost revenue. When I integrated the popular WP Mail SMTP plugin to improve deliverability, I never anticipated that it would silently begin breaking one of the most critical parts of my ecommerce flow: order emails.

TL;DR: After installing WP Mail SMTP to fix deliverability issues on my WooCommerce store, order confirmation emails stopped sending. Turns out, a conflict with email authentication and transactional overflow halted WooCommerce from firing key mail hooks. I resolved it by implementing a transactional retry queue combined with better SMTP failure logging. This guide explains what went wrong and how to prevent it from happening to you.

What Happened When I Installed WP Mail SMTP?

At first, switching to WP Mail SMTP seemed like a no-brainer. The plugin boasts smooth integration with third-party SMTP providers like SendGrid, Mailgun, and even Gmail, offering detailed email logs and a reliable method to bypass spam filters. My goal was to stop order emails from landing in spam folders or being blocked altogether due to common WordPress server mail issues.

The install and setup were seamless. I authenticated with Mailgun, configured sender domains, and started logging test emails. Everything worked perfectly. Or so I thought—until the orders started rolling in again.

No one was getting order confirmation emails. Not admins. Not customers. Just… silence.

Diagnosing the Problem

After realizing it wasn’t just a fluke, I dove into some diagnostics:

• I checked the WooCommerce email logs – they showed the order emails had been “sent.”
• Mailgun’s dashboard, however, showed no record of those specific transactional emails.
• Other WordPress emails, like password resets or contact form alerts, were coming through just fine.

This suggested a very specific problem: WooCommerce order emails were not being properly handed off to WP Mail SMTP’s sending layer. That was when I hit the forums, GitHub issues, and even turned to WP Mail SMTP’s and WooCommerce’s documentation.

The Culprit: WP Mail SMTP’s Custom Email Hook Handling

What I discovered was rather illuminating. WP Mail SMTP overrides the default wp_mail function in WordPress to allow SMTP-based sending. While this normally works seamlessly with general emails, transactional-heavy plugins like WooCommerce don’t just pass data linearly. There’s logic for queuing, hooks for status triggers, and gateways that behave differently if filters fail silently.

WP Mail SMTP, when misconfigured or when it encounters retries/exceptions, doesn’t always bubble up the error correctly. This can cause emails to be “marked as sent” by WooCommerce even if they never make it to the SMTP provider.

The breaking point came when order emails included attachments or custom invoice templates—these strained the SMTP provider’s payload thresholds. Instead of retrying or flagging the issue, the plugin failed silently.

The Temporary Fixes I Tried

Like many developers, my first approach was a mixture of hope and experimentation. Some things I tried:

• Disabling all custom email templates
• Switching SMTP providers (from Mailgun to SendGrid)
• Reauthenticating domain DKIM and SPF records
• Reverting to default WP mail without SMTP

Each of these had partial results. Emails would sometimes send, but with no pattern or reliability. It seemed like heavier payloads or peak server usage would tank the SMTP handshake—and it all happened without detailed logs unless you were actively tracing it with debugging enabled.

Implementing a Transactional Retry Queue

Ultimately, I knew I needed a structural solution that didn’t just rely on “hope and send.” I decided to build a simple transactional email retry queue using existing tooling and a custom function.

Key Steps to Implement the Retry System:

1. Log Failed Transactional Sends: I hooked into the phpmailer_init action and added a custom logger to catch any exceptions thrown during email send attempts.
2. Queue Emails on Failure: If a transaction email failed (especially WooCommerce emails), I stored the payload—headers, subject, body, recipient—in a custom post type.
3. Scheduled Retry Cron: Every 15 minutes, I ran a wp-cron job that retried the failed transactional emails in the queue and flushed them upon success or flagged them as “manual intervention required” after 3 tries.

The real game-changer was step #2. WooCommerce order objects change quickly—if you re-generate an order email URI or status later, the content can be different. This system ensured I captured the real email intent at the time it failed, and queued it as-is.

cron job interface, retry queue, email logs]

Improved Logging with Fail-Safe Overrides

I also modified the WP Mail SMTP plugin’s default logging by extending the PHPMailer exceptions and enabled fallback logging to a local email file archive if the SMTP provider was unreachable.

Here’s a snippet of what that override looked like:

add_action('phpmailer_init', function($phpmailer) {
    $phpmailer->action_function = function($result, $to, $subject, $message, $headers, $attachments) {
        if (!$result) {
            error_log("Failed to send transactional email to $to with subject $subject");
            // Save to retry queue logic here
        }
    };
});

This ensured errors were logged immediately and the queue handler could process them independently of WooCommerce or SMTP plugin behavior.

What You Can Do to Prevent This

If you’re currently running WooCommerce and WP Mail SMTP together, here are some immediate and preventive actions you can take:

• Enable WP Mail SMTP’s Email Logging: Visit WP Mail SMTP → Email Log and turn on logging for all emails.
• Use Lightweight Attachments: Avoid adding large PDFs or invoice files dynamically. Pre-generate or keep them under size limits.
• Test Transactional Flow Regularly: Make test purchases at least once a week to confirm email success.
• Set Up a Simple Retry Mechanism: Even if you don’t build a full retry queue, have a way to catch failed messages and retry them manually.
• Avoid Overloading a Single SMTP Provider: Use transactional and marketing email APIs separately.

Final Thoughts

This experience taught me that even the most popular plugins can clash in unpredictable ways—especially in an environment as customizable as WordPress. WP Mail SMTP is still a great tool, but it needs careful configuration when used with high-stakes plugins like WooCommerce.

Your transactional email system is not something you should trust blindly. Build in safety nets. Monitor failures. And more importantly, ensure customers never suffer from tech mishaps they can’t even see.

With the transactional retry system, my WooCommerce emails are now stable, reliable, and—even better—auditable. I sleep better knowing no customer is left wondering where their order is.