How to Set Up WordPress Email Logging for Debugging SMTP

The first time my WooCommerce order emails went missing, I wasted hours guessing. I checked spam folders, reset contact forms, and even switched hosts. Nothing gave me a straight answer.

What finally helped was WordPress email logging. Once I could see every email attempt (and the exact error text), the problem stopped being mysterious. It turned into a normal fix.

In this guide, I’ll show you how I set up email logging alongside SMTP, how I read the logs without getting lost, and an optional developer-only way to capture wp_mail() failures even if you don’t want a full plugin.

What WordPress email logging actually tells you (and what it doesn’t)

WordPress sends most site emails through wp_mail(). That includes password resets, form notifications, WooCommerce receipts, membership emails, and admin alerts. When something breaks, WordPress usually fails quietly. You might see nothing on-screen, and your customer just never gets the message.

Email logging changes that because it records details like:

• the recipient address
• subject and headers (sometimes)
• timestamp
• send status (sent, failed)
• the raw error returned by the mailer or SMTP server

That last part is the gold. A log that says “SMTP connect() failed” points you in a totally different direction than “535 Authentication failed”.

Still, logging has limits. A “sent” status only means your site handed the email to your SMTP provider successfully. After that, deliverability depends on inbox rules, SPF/DKIM/DMARC, and provider reputation. So I treat the log as the first checkpoint, not the finish line.

If I had to sum it up, email logging tells me whether WordPress tried, and what happened when it tried.

One more practical note: logs can store sensitive data. Some plugins log message bodies. That’s convenient, but it can also capture password reset links and customer details. Later in the post, I’ll show how I keep retention short and access locked down.

Set up SMTP plus email logging (my go-to plugin workflow)

You can mix and match tools (one plugin for SMTP, another for logs), but I prefer a single plugin that does both. In March 2026, one of the simplest free options I’ve used is FluentSMTP because it focuses on delivery and includes logging without a lot of upsells getting in the way.

Here’s the exact setup flow I follow:

1. In WordPress, go to Plugins > Add New.
2. Search for “FluentSMTP”, then Install Now and Activate.
3. Open FluentSMTP > Settings.
4. Choose your mail service (or pick “Other SMTP” if you’re using custom SMTP).
5. Enter your SMTP details:
   • SMTP Host
   • SMTP Port (commonly 587 for TLS, 465 for SSL)
   • Encryption (TLS/STARTTLS vs SSL)
   • Username and Password (or OAuth if supported)
6. Save settings, then send a test email from the plugin’s tools page.
7. Open FluentSMTP > Email Logs and confirm the test email appears.

A quick personal rule: I always set the “From Email” to a real address on my domain (like [email protected]). When I let plugins spoof random “From” addresses, DMARC policies can slap the email down.

If you’re running Contact Form 7, that “From” issue shows up a lot. I usually fix replies by setting a proper Reply-To header instead of making the From address pretend to be the visitor. This guide helps: setting up Reply-To email in Contact Form 7.

Best practices I apply right after logging is enabled

I do these immediately, because logs plus SMTP can expose more than you expect:

• Use OAuth or app passwords when available. It reduces account risk compared to your main mailbox password.
• Avoid plaintext SMTP passwords when possible. If your stack supports it, store secrets in environment variables or server-side config, not in the database.
• Limit log retention. I keep logs for debugging windows (like 7 to 30 days), then purge.
• Restrict who can view logs. Admins only, and never on shared accounts.

Also, if your log fills with “noise” emails (auto-updates, plugin notices), it gets harder to spot real failures. When I’m actively debugging, I sometimes reduce those background emails. Here’s how I’ve done it for core and plugin updates: disable WordPress auto-update emails.

Read email logs like a detective (common SMTP mistakes and what they show)

Once logging is on, the main skill is reading the error and mapping it to one fix. Below is the checklist I keep in my head, written out as a quick reference.

Here’s a table of common SMTP misconfigurations and the clues they leave in logs.

What’s wrong	What the email log often shows	What I fix first
Wrong host or firewall blocks SMTP	“Could not connect to SMTP host”, timeouts	Confirm host, then test ports 587/465 with your provider
Wrong port or encryption mismatch	TLS/SSL handshake errors, connection dropped	Switch 465 (SSL) vs 587 (TLS/STARTTLS) to match docs
Bad username/password	“535 Authentication failed”, “Invalid login”	Re-create app password, confirm no extra spaces
“From Email” not allowed by provider	“Sender address rejected”, “From not verified”	Set From to an authorized domain address
Hosting blocks outbound SMTP	Connection refused, intermittent failures	Use a mail API provider, or ask host to allow outbound SMTP
Email “sent” but never arrives	Status success, no SMTP error	Check provider message activity, then SPF/DKIM/DMARC

When I need more detail on the “why”, I like plugins that store debug events, not just pass/fail. Easy WP SMTP documents that idea well, and it’s a helpful way to think about troubleshooting even if you use a different tool: Easy WP SMTP debugging sending issues.

Don’t stop at WordPress, confirm deliverability with your provider

If your WordPress log shows success, I immediately check the SMTP provider’s message activity (delivery events, bounces, blocks). Many transactional services show this per-message, and it’s the fastest way to confirm whether the email left their system or got rejected downstream.

If you’re still deciding between SMTP plugins, I also keep a second option in mind for tricky sites because it supports alerts and backup connections: Post SMTP plugin with email logs.

Optional developer setup: log wp_mail() failures with a tiny mu-plugin

Sometimes I don’t want a full SMTP plugin on a staging site, but I still want proof that wp_mail() is failing. For that, I add a tiny must-use plugin that listens for failures and writes a line to a log file.

1. Create a folder: wp-content/mu-plugins/
2. Create a file: wp-content/mu-plugins/wp-mail-fail-log.php
3. Paste this minimal snippet (keep the path as-is unless you prefer a different location):

<?php
/** Plugin Name: WP Mail Fail Logger */
add_action('wp_mail_failed', function($wp_error){
$file = WP_CONTENT_DIR . '/uploads/wp-mail-failures.log';
$line = date('c') . ' | ' . $wp_error->get_error_message() . PHP_EOL;
error_log($line, 3, $file);
});

This stores entries at wp-content/uploads/wp-mail-failures.log. After that, I lock it down with server permissions and keep retention short. If you ever log email addresses or message content, treat that file like sensitive data.

Conclusion

When email delivery breaks, guessing feels like trying to fix a car with the hood closed. WordPress email logging opens the hood, because you can finally see what WordPress tried to do and how SMTP responded. Set up logging, send a test, then use the error text to make one targeted change at a time. After you see “sent”, confirm it in your SMTP provider’s message activity so you know it actually reached the next hop.