WordPress plugin - Matteo Cisilino

WordPress email log: why I check it with FluentSMTP

matteocisilino — Sat, 31 Oct 2026 08:00:00 +0000

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.

The post WordPress email log: why I check it with FluentSMTP first appeared on Matteo Cisilino.

CSDN manual: introduction

matteocisilino — Fri, 30 Oct 2026 16:05:18 +0000

This CSDN manual explains how to use Cisilino Site Defense Network, a WordPress plugin that protects your site from abusive login attempts. I have written it for anyone who manages a site and wants to understand what each tab does before touching it. Here I describe version 1.0.15.

What is Cisilino Site Defense Network

Cisilino Site Defense Network, CSDN for short, is a WordPress plugin. It counts failed logins for each IP address. When an IP reaches the threshold, it blocks it by writing it into the site’s .htaccess file.

The plugin works on its own, with no configuration at all. Connecting it to an external panel is optional. If you don’t configure that connection, the plugin makes no outbound calls whatsoever.

You will find it in the WordPress side menu, at the item marked by point 1 in the image: Settings > Cisilino Site Defense Network. Inside are ten tabs, listed at point 3.

What it does

The plugin brings together several defences, all managed from that one page.

Automatic blocking of IPs that fail the login too many times, with a whitelist for trusted networks.
Manual blocking and unblocking of a single IP, even for a set time.
Optional rules for .htaccess: no PHP in uploads, no directory listing, sensitive files protected.
Security HTTP headers and automatic logout of inactive administrators.
A policy on who can create new users.
A limit on authors’ publishing, and on comments and Contact Form 7 submissions from guests.
A log of the site’s activity and an integrity check of the plugin’s files.
A PHP error log, which you can switch on when you need it.

What the plugin doesn’t do

This CSDN manual also covers the plugin’s limits, and it’s worth knowing them straight away. The plugin is not a web application firewall: it doesn’t analyse the content of requests. The word IDS in the tab name refers to file and folder access rules, not a genuine intrusion detection system.

It doesn’t prevent file tampering: it only detects it, and anyone who already has write access can bypass the check.
It doesn’t make a copy of .htaccess before changing it.
It doesn’t offer a Content-Security-Policy header.
It doesn’t hide the user list exposed by the WordPress REST API.
It has no list of email domains and no captcha for registrations.
On a server that ignores .htaccess, such as nginx, the server-level rules have no effect.

Warning: a plugin reduces risk, it doesn’t eliminate it. Keep WordPress, themes and plugins up to date, and back up your site, even if you use CSDN.

Requirements

WordPress 5.8 or later, and PHP 7.4 or later.
Apache, or a compatible LiteSpeed, for IP blocking and hardening. The .htaccess file must be writable.
An account with permission to manage settings. On a single site this is manage_options. On a multisite network you need the super admin.
For the panel, optional: an https address, a customer code and an API key.

Updates arrive through WordPress’s normal mechanism, under Plugins > Updates. The plugin is built for the WordPress.org directory, where it has its official page: that’s the right place to check which version is published.

How to read the CSDN manual

You can read the chapters in order or jump straight to the one you need. Every chapter has an image with a map of the page and numbered red circles: number 1 marks the menu item, 2 the active tab, and the rest mark the sections.

If this is your first time, start with installation and the first run. If something isn’t working, go straight to the troubleshooting chapter. These are the chapters:

One note to avoid confusion. Manually blocking and unblocking an IP, and the whitelist, live in the General tab, not in Blocked IPs. The same applies to the upload monitoring form.

All the field and button labels throughout this CSDN manual are copied exactly as you see them in the plugin. To get started, move on to the next chapter: Installing and activating Cisilino Site Defense Network.

The post CSDN manual: introduction first appeared on Matteo Cisilino.