Building my own WordPress SMTP plugin
SMTP, logging, failover — all in one plugin for WordPress
Intro
I look after a busy client website, and for email we don’t like relying on self-hosted mail. We prefer using a third-party SMTP provider — Brevo is the preferred option.
The site owner also wants something most WordPress setups don’t really give you out of the box:
the ability to view emails that are being sent by the WordPress system
visibility on errors when they happen
and the ability to resend emails if something fails
To be fair, errors are rare — very rare — but in a complex setup they still happen occasionally. Especially after updating multiple plugins for newer versions of WordPress, and dealing with a few custom plugins that are quite complex in their own right.
Normally, solving this properly would mean using two or more plugins, or paying for a fairly advanced SMTP/logging solution.
I could have just bought one and moved on.
But as usual, I started thinking:
What can I actually do better for this client site?
That led me somewhere else.
Because once you start thinking about email visibility, you naturally run into another problem:
What happens if something goes wrong at scale?
For example, if a contact form gets hammered by bots, you might not notice immediately. Everything can look “normal” until your SMTP provider starts throttling or pausing service.
At that point, you’re reacting after the damage is already done.
So instead of just building another SMTP tool, I started combining ideas.
The problem I kept running into
SMTP in WordPress is usually split across multiple tools:
one plugin sends email
another stores logs
provider dashboards sit externally
failover (if it exists) is often paid or separate
troubleshooting becomes a cross-system puzzle
So when something breaks, you’re not looking at one system — you’re reconstructing what happened from fragments.
That’s the part I wanted to remove.
What I built
The plugin is called SMTP + Log Viewer for WordPress.
The idea became simple:
WordPress email should be observable, controllable, and resilient inside one system.
So instead of separating concerns, it combines:
SMTP routing (multiple providers)
email logging
resend capability
failover handling
debugging visibility
and a safety layer that monitors behaviour
All inside WordPress.
It runs in three modes
Not every site needs full control, so it can run in different ways:
Logger only — observe all outgoing WordPress email without changing delivery
SMTP + logging — full routing with full visibility
SMTP only — delivery-focused mode without storing logs
This makes it usable even if you just want visibility without changing infrastructure.
Failover isn’t optional anymore
Most SMTP setups assume your provider just works.
In reality, providers fail, throttle, or degrade silently.
So I built proper failover into the core:
Primary → Secondary → Backup
If one fails, email automatically moves down the chain.
No manual switching. No downtime panic. No digging through logs trying to work out what broke.
On top of that, you can see per-provider status and usage so you actually understand what’s happening over time.
Mail Safety (the part that changed the design)
This started as a defensive idea.
Contact forms and bots don’t just spam inboxes — they can quietly stress your email system in a way that doesn’t look obvious until limits are hit.
So instead of only counting emails, the plugin looks at behaviour patterns:
bursts of form submissions
unknown or unusual sources
plugin-generated email patterns
link behaviour in outgoing messages
From this it generates a simple state:
Normal → Watch → Throttle → Recovery
The aim isn’t to block legitimate email.
It’s to slow down abnormal behaviour early enough that you don’t end up discovering the problem after your provider has already reacted.
Why I built it this way
It came down to a simple frustration:
SMTP in WordPress combined in one plugin just makes sense to me.
I didn’t want multiple plugins, external dashboards, or paid upgrades just to understand what’s happening with email.
I also wanted proper control over provider chains.
So instead of a single SMTP connection, the plugin allows a chain setup — Provider A → Provider B → Provider C.
You can also set a switchover limit per provider. For example, if you’re on a free plan, you can define a threshold where Provider A automatically switches to Provider B once you hit a usage limit.
That way you can effectively extend free-tier sending limits across multiple providers, rather than getting cut off or throttled unexpectedly.
The goal is simple:
visibility without extra tools
control without external systems
failover without complexity
and predictable behaviour when limits are hit
So instead of stitching tools together, I built it as one system.
Where it is now
Right now it’s running in test mode on a live site.
Not a sandbox — real traffic, real email, real edge cases.
I’m watching:
provider switching under load
logging accuracy during real usage
failover behaviour in practice
and how the safety scoring reacts over time
Next step
Once I’m confident it’s working well on the live site — I really need about a month for the algorithm testing — I’ll make it available for download.