A small SMTP plugin that does three things and nothing else: it sends your mail\nover SMTP, it writes down what happened, and it tells a webhook when a message\nfails.<\/p>\n\n
We built it because the SMTP plugin we had relied on for years kept growing.\nMore features, more integrations, more settings \u2014 most of which we simply\ndidn't need. Eventually, that added complexity started causing problems on\nproduction sites.<\/p>\n\n
Many alternatives had gone the same way: email logs behind paid tiers, API\nproviders, OAuth flows, deliverability dashboards, upgrade banners, and entire\nmail suites around what should be a simple job.<\/p>\n\n
We wanted the opposite: connect to a mail server, send the email, log the\nresult, and stay out of the way.<\/p>\n\n
Email is critical infrastructure. Every additional feature is another dependency\nand another potential failure point \u2014 and when mail breaks, customers notice\nimmediately.<\/p>\n\n
So we built the slim alternative we wanted ourselves, and we run it in our own\nproduction environment and on our client sites.<\/p>\n\n
What it does<\/strong><\/p>\n\n What it deliberately does not do<\/strong><\/p>\n\n No API providers, no OAuth, no fallback connections, no deliverability score, no\ndashboard widget, no newsletter integration, no pro tier, no advertising for\none, and no upsell notices. If you need those, one of the big plugins will serve\nyou better, and that is a fine outcome.<\/p>\n\n Safety rails<\/strong><\/p>\n\n Every<\/strong> setting can be defined as a constant in define( 'WONDERFUL_SMTP_MAILER_AND_LOG_HOST', getenv( 'SMTP_HOST' ) );\n define( 'WONDERFUL_SMTP_MAILER_AND_LOG_PASSWORD', getenv( 'SMTP_PASSWORD' ) );<\/p>\n\n A defined constant wins over the settings field, and the field is then shown\nread-only so the two cannot silently disagree.<\/p><\/li>\n How it is built<\/strong><\/p>\n\n Development is test driven, and the suite covers the behaviour that decides\nwhether your mail actually leaves the building: that an unconfigured plugin keeps\nits hands off PHPMailer entirely, that \"none\" really disables TLS instead of\nquietly upgrading, that a sender another plugin set on purpose survives, that a\ncorrupt delivery-mode value falls back to sending rather than silently swallowing\nyour mail, that log-only mode never once reaches the mailer, that the retention\npurge deletes what is past the cutoff and nothing else, and that a webhook fires\nwith the failure details but no credentials.<\/p>\n\n Those tests run together with the WordPress coding standards, a PHP 7.4\ncompatibility lint and WordPress.org's own Plugin Check every single time, before\na release is built at all. An error in any of them stops the release \u2014 the\npipeline refuses, it is not a checklist someone waves through.<\/p>\n\n The tests themselves stay in the repository and are not part of this download.\nNothing ships here that your site does not need at runtime: a small set of PHP\nclasses and four assets, with no vendor directory and no framework.<\/p>\n\n That discipline is also why the feature list is short. Every feature is a promise\nthat has to keep working.<\/p>\n\n This plugin contacts two kinds of external endpoints, both of which you\nconfigure yourself. It has no vendor backend, sends no telemetry, and phones\nhome nowhere.<\/p>\n\n 1. Your SMTP server<\/strong><\/p>\n\n The host you enter in the settings receives your outgoing messages: sender,\nrecipients, subject, body, attachments, and \u2014 if authentication is enabled \u2014 the\nusername and password you configured. This is the entire purpose of the plugin.\nWhich company that server belongs to, and which terms and privacy policy apply,\nis determined by you when you enter the host name. No connection is made until\nyou configure one.<\/p>\n\n 2. Your failure webhook (optional, off by default)<\/strong><\/p>\n\n If, and only if, you fill in the webhook field, a JSON request of the form\n {\"text\": \"...\"} is sent to that URL whenever a message fails. It contains your\nsite URL, the recipient address, the subject and the error the mail server\nreturned. It contains no message body and no credentials. Nothing is sent while\nthe field is empty. The receiving service is one you choose \u2014 Zapier, n8n, Make,\nSlack or your own endpoint \u2014 and its terms and privacy policy apply to what you\nsend it.<\/p>\n\n Message contents and log entries stay in your own database. No data is\ntransmitted to Wonderful Plugins.<\/p>\n\n\n No. Without an SMTP host the plugin does not touch outgoing mail at all and\nWordPress keeps using PHP The connection check opens a session with your mail server, negotiates\nencryption, logs in and hangs up. Nothing is sent and nothing is logged, so you\ncan run it as often as you like while you are getting the settings right. The\ntest message actually delivers an email and records it in the log, which also\nproves that logging works.<\/p><\/dd>\n Read the SMTP conversation printed underneath the error. It is the unedited\nexchange with your mail server, and the reason is almost always in the last few\nlines \u2014 wrong credentials, a blocked port, or a sender your provider will not\naccept.<\/p><\/dd>\n In the WordPress options table, unless you define them as constants in\n wp-config.php, which is what we recommend for production. The password is\nnever echoed back into the settings form.<\/p><\/dd>\n Yes. Open the message and click the attachment. The download only ever serves a\nfile this site itself attached to that logged email \u2014 the request names a log\nentry and a position in its attachment list, never a path \u2014 and a resend\nre-attaches whatever is still on disk. Files deleted since are marked as gone.<\/p><\/dd>\n Because the log records where an attachment was<\/em>, not the file itself. Some\nplugins keep what they send \u2014 the well-known WooCommerce invoice plugins file\ntheir PDFs away and can hand them back later. Plenty of others do not: form\nuploads written to a temporary directory, one-off exports, reports generated for\na single send. Those are gone within the hour, and a resend then goes out without\nthem.<\/p>\n\n With storage on, a copy is kept regardless of what the sending plugin does, for\nas many days as you choose.<\/p>\n\n Copies are off by default because they are customer documents sitting on disk.\nWhen you turn them on they go into a directory that denies web access and carries\nan A daily job deletes copies past the period you set. Setting it to 0 keeps a copy\nfor as long as its log entry lives \u2014 deleting the entry always takes its copies\nwith it, so a file is never left on disk with no record pointing at it.\nDeactivating the plugin deletes them all, and uninstalling removes the\ndirectory. Once a copy is gone the\nmessage shows the attachment struck through as no longer available, and warns you\nbefore you resend rather than quietly sending it short.<\/p><\/dd>\n Yes \u2014 it has to, otherwise the resend button could not work. Log entries live in\nyour own database and are deleted after the retention period you set, 30 days by\ndefault. Set it to 0 to keep everything.<\/p><\/dd>\n Open SMTP Mailer \u2192 Email Log<\/strong> and set the two date fields above the table.\nThe counters at the top follow the filter, so you also get the delivery numbers\nfor exactly the period you picked. Entries older than your retention setting are\ngone for good, so pick that setting with the audit trail you want in mind.<\/p><\/dd>\n Set Delivery mode<\/strong> to \"Log only\". Every message is still recorded in full \u2014\nrecipient, subject, headers and body \u2014 and none of them reaches the mail server.\n wp_mail() still reports success, so plugins that check its return value behave\nnormally. Suppressed messages show up in the log as \"Not sent\" and are not\ncounted as delivered.<\/p><\/dd>\n No. Resending is always a deliberate click. That is intentional: automatic\nretries against a misconfigured server are how a mail problem becomes a mail\nflood.<\/p><\/dd>\n No. Staying small is the point of the plugin.<\/p><\/dd>\n\n<\/dl>\n\n\n\n
wp_mail()<\/code> call over your SMTP server \u2014 WooCommerce, contact\nforms, core password resets, all of it, without touching their code.<\/li>\ndocker-compose<\/code> passed in.<\/li>\n\n
mail()<\/code> \u2014 installing it cannot take your email\ndown.<\/li>\nwp-config.php<\/code>, following\none mechanical rule: the option name in upper case. That keeps credentials out\nof the database and out of any dump copied to a staging site, and lets a Docker\ncontainer pass them in as environment variables:<\/p>\n\nwp_mail()<\/code> keeps reporting success \u2014 and the\nperson who needs the warning is the one wondering why a customer never got\ntheir confirmation.<\/li>\nExternal services<\/h3>\n\n
\n
wp-config.php<\/code> instead.<\/li>\n\n
I installed it but configured nothing. Did my email break?<\/h3><\/dt>\n
mail()<\/code> exactly as before.<\/p><\/dd>\nWhat is the difference between the connection check and the test message?<\/h3><\/dt>\n
The test message fails. What now?<\/h3><\/dt>\n
Where are my credentials stored?<\/h3><\/dt>\n
Can I get an attachment back out of the log?<\/h3><\/dt>\n
Why would I turn on attachment storage?<\/h3><\/dt>\n
index.php<\/code>, and each file is stored under a random 32-character name with a\nneutral .bin<\/code> extension \u2014 so nothing there is guessable, and nothing there is\nsomething a web server would execute even if the directory protection were\nbypassed. The original filename lives in the database and is restored on\ndownload. Files over 10 MB are never copied.<\/p>\n\nDoes the log store the message body?<\/h3><\/dt>\n
How do I find an old log entry?<\/h3><\/dt>\n
How do I stop a staging site from mailing real customers?<\/h3><\/dt>\n
Does anything retry automatically?<\/h3><\/dt>\n
Will this grow into a pro version later?<\/h3><\/dt>\n
1.0.1<\/h4>\n\n
\n
1.0.0<\/h4>\n\n
\n