I manage several WordPress sites. On each one, more emails go out than anyone would guess: contact notifications, password resets, order confirmations, alerts to site managers. The WordPress email log in FluentSMTP is the tool I check as soon as a client writes “I never got anything.” I used to look at the SMTP server logs from the command line. I had to match grep output and timestamps by hand. Now I open a page in the WordPress dashboard and it’s all right there.
Why I check the WordPress email log before the server logs
The typical case is always the same. A contact form that “isn’t arriving”. A client who never gets the password reset email. An order left without a confirmation. Without a log at hand, the first guess is the spam folder. Then the SMTP server logs. Then maybe the firewall. With FluentSMTP I skip those steps. I can see straight away whether WordPress actually tried to send that email. To whom, when, and with what response from the sending server.
FluentSMTP logs every call to wp_mail(). Not just emails from third-party plugins, but also the ones generated by core: new-user notifications, update reminders, error alerts. For every send, the log shows the sender, recipient, subject, full headers, and message body. And the response from the SMTP provider or API used. If an email failed, that server response is right there. I don’t have to guess it.
What I actually find in the sending log
The plugin supports dozens of connectors: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Also Google Workspace and Microsoft 365 via OAuth, as well as plain authenticated SMTP. On the sites I manage I almost always use authenticated SMTP with the client’s own domain. Sometimes a dedicated API, when the email volume grows. Either way, the WordPress email log doesn’t change. Every row has a status, sent or failed. There’s a button to review the content or resend the message, without the user having to repeat the action that triggered it.
Manual resending is the feature I use most. A form filled in twice because “it never arrived” becomes one click in the log. Not a fresh complaint from the client. For repeated failures I’ve set up notifications on Telegram. As soon as a connection stops working, I know before anyone writes to tell me. Instead of finding out from a support ticket.
The log isn’t only about notifications aimed at me or the client who manages the site. Every outgoing email the site generates towards third parties ends up there too: the order confirmation an online shop sends to its customer, a payment receipt, a shipping notice. If that confirmation doesn’t arrive, I see it in the WordPress email log exactly like an internal notification, with the same button to resend it to the right recipient without making them repeat the purchase.
How I set up FluentSMTP on the sites I manage
After connecting the right connector, I change the log retention. By default it stays on for a long time. I set it to 30-60 days, depending on the site’s traffic. That’s enough to trace back a problem reported late. Without filling the database with rows I’ll never look at. I then turn on at least one notification channel for failures, Telegram or Slack depending on the client. The log alone doesn’t alert anyone: it has to be opened to be read.
On sites with contact forms I also use Cisilino Site Defense Network to block bots. Less incoming spam means fewer emails generated by the forms. The log stays easier to read, with less noise to filter through when I’m looking for the right message.
SMTP credentials don’t stay in plain text in the database
One detail I always check before saving a connection: where the credentials end up. FluentSMTP encrypts them by default with WordPress’s own SALT keys, the ones already present in wp-config.php for session security. Encryption can be switched off, but the plugin itself flags that as not recommended. On the sites I manage I prefer another option: saving the API or SMTP password directly in wp-config.php, outside the database, by defining the constants before the plugin reads them. That way, even a database dump or unauthorised access to the dashboard doesn’t expose the sending provider’s key. It’s the same principle I apply elsewhere: fewer secrets in the database, the better.
Several connections together, not just one at a time
FluentSMTP lets you configure several connections together, not just one at a time. On one site I set a default connection and add a second one as a backup: if the first provider doesn’t respond, sending switches automatically to the backup connection, without me having to step in. Which connection gets used depends on the sender address: each connection has its own “From”, everything else goes through the default one, with the backup kicking in only if the default one really fails (a provider error, not an email that ended up in spam). It’s one of the reasons I prefer it to a single SMTP setup with no alternative: if SendGrid or Amazon SES has a problem for a few hours, the site keeps sending anyway, and I see it straight away in the WordPress email log. All included in the free version, with no paid pro version: you only pay the sending provider you choose, not the plugin.
A daily health check, not just when something breaks
Besides the row-by-row log, FluentSMTP runs a connection health check every day, automatically. If the provider stops responding, the alert arrives before a client writes to tell me “the site isn’t sending emails any more”. The same dashboard shows a chart with daily totals of successful and failed sends: useful for seeing at a glance whether a drop is normal or a sign that something is breaking, without having to open the WordPress email log row by row every time. There’s also a periodic email summary, with the week’s totals: it isn’t a failure alert, it’s a bulletin I skim through to know whether the sending volume is within the norm.
For anyone who, like me, manages several sites from the command line, FluentSMTP also exposes WP-CLI commands: a test send, a connection health check, statistics, and cleanup of old logs. I use them in the same scripts that already run on the servers for other maintenance checks, without having to open every site’s dashboard one by one.
The honest limits of the WordPress email log
It isn’t a magic solution. Retention is based on days, not on a maximum number of rows. On a site with a lot of transactional traffic the log table can grow quickly. It’s worth keeping an eye on it, or setting a shorter retention period. Failure notifications only arrive on the chat channels you’ve configured, not by email. That makes sense: an email warning about a failed email risks failing in turn too. But it’s worth knowing before relying on it.
Finally, the log records what happened on the WordPress side and the provider’s side. It doesn’t guarantee delivery into the recipient’s inbox. If an email is marked as sent but ends up in spam, that’s a domain reputation or SPF/DKIM configuration issue. Not something a log can fix on its own. It’s still the first place I look, before any other check.
The plugin is free and open source. Official page on wordpress.org, with no features locked behind a pro version. For anyone managing even a single site with a contact form, it’s worth installing just for the WordPress email log. The first time it turns “I never got the email” into a one-minute fix instead of half an hour, it’s paid for itself.
Leave a Reply