Log Emails hooks wp_mail to record the call arguments and then commits the actual log entry from the phpmailer_init action. That second hook is the one that matters: anything that does not pass through phpmailer_init is invisible to the plugin, regardless of what the wp_mail filter saw. Inside that constraint the plugin is a clean, narrowly scoped logger from the same vendor as Disable Emails, with which it pairs naturally on a development environment.
The plugin is maintained by 
WebAware, the Australian developer behind Disable Emails. Active installs sit above 6,000, the rating averages 5.0 across 11 reviews, and the current release (1.6.0, May 2026) tests against WordPress 7.0. The plugin requires WordPress 4.6 and PHP 7.4, ships under GPLv2 or later, and is free and donation-supported. There is no paid tier.
What it records
Each captured email becomes one post in a private custom post type (log_emails_log) whose admin screen lives at Tools > Log Emails. The post title carries the subject; the post content carries the message body; meta fields carry From (name and address), To, CC, BCC, Reply-To (added in 1.6.0), Content-Type, and the alternative plain-text body when present. Attachments are not recorded; the plugin reads Subject, Body, AltBody, and the From/Content-Type fields off the PHPMailer object and stops there.
The plugin removes the pre_post_content and content_save_pre filters before calling wp_insert_post, so KSES and other body sanitisers do not strip the message during storage. A log_emails_pre_insert action lets a site put filtering back if it wants to. The result is that the body in the log matches the body that would have been sent, including raw HTML that core would otherwise have rewritten.
The list table on the admin screen sorts and searches by subject and by recipient addresses (From, To, CC, BCC). The detail view renders the full headers, the body and alt body, and the Reply-To addresses. There is no resend action, no test-send tool, and no sender override; this is a logger, not a mailer-adjacent utility.
Where it hooks, and what falls out of view
Three hooks, all registered at priority 99999 so they run after every other listener on the chain:
wp_mailfilter: records the function’s arguments (to,subject,message,headers,attachments) into a class property and returns the args untouched.phpmailer_initaction: instantiates the log post, pullingBody,AltBody,Subject,From,FromName, andContentTypeoff the PHPMailer object and merging in the headers captured from the earlier filter.bp_email_set_tofilter: a BuddyPress fallback that records the recipient list when BuddyPress builds outbound mail through its own pipeline rather than callingwp_maildirectly.
The capture point is phpmailer_init. The wp_mail filter records args but does not write to the database; if phpmailer_init never fires, no log post is created. Four patterns trip this:
- A plugin that replaces the pluggable
wp_mail()with a version that never firesphpmailer_init. Post SMTP 4.0.2 does this in its default mailer mode, for SMTP and provider-API transports alike. Its replacement still applies thewp_mailfilter, so Log Emails records the arguments, but no log post is ever written. - A plugin that short-circuits
wp_mailvia thepre_wp_mailfilter (added in WordPress 5.7). The function returns the plugin’s response immediately andphpmailer_initdoesn’t run. Queue plugins such as Mail Queue work this way at enqueue time; when the queue drains, the stored message goes back throughwp_mail()and is captured then. - A plugin that calls PHP’s
mail()directly without going throughwp_mail. Rare in modern releases, present in older or single-purpose plugins. - A plugin that builds and ships its own outbound entirely (a marketing plugin with a bundled SDK, a transactional integration that calls a provider HTTP API from its own code).
Whether a mailer plugin breaks coverage depends on how it takes over the send, not on whether it talks SMTP or a provider API. We read the source of the current releases on 2026-10-22. WP Mail SMTP 4.10.3 leaves core’s wp_mail() in place and swaps the PHPMailer object, so phpmailer_init fires for every mailer it offers, Postmark and SendGrid included. FluentSMTP 2.4.1 replaces wp_mail() but fires phpmailer_init itself on every send, whichever connection is set. In both, Log Emails captures everything. Under Post SMTP 4.0.2 it captures nothing in the default mode and everything in the alternative “PHPMailer” mode, which leaves core’s wp_mail() in place. Host-provided SMTP goes through core’s wp_mail() and is captured.
Password obfuscation
Before each log post is inserted, the plugin runs the body and alt body through a regex that redacts any line containing the word “password” (case-insensitive). The replacement string is *** password redacted ***. The check is extended to the locale’s translation of “password” when the active locale is not English, so a German site obfuscates Passwort the same way.
The match is line-based and substring-based: anything between two line breaks that contains the literal “password” anywhere in it is redacted whole, not just the credential. A line that mentions a password policy in passing is redacted as aggressively as a line that leaks one. That is conservative on the privacy side and a source of false positives on the readability side; logged emails about password resets often render as a wall of redaction notices instead of the original copy.
This is also the entire privacy story. The plugin does not redact tokens, API keys, magic-link URLs, or anything else that a contact form or transactional plugin might put into a body. Treating the log table as containing personal data under GDPR or equivalent regimes remains the right default.
Purging, retention, uninstall
The plugin schedules a daily WP-Cron event (log_emails_purge) that deletes log posts older than the configured retention window. The single setting, at Settings > Log Emails, is the number of days to keep. The default is 30. Setting it to 0 disables purging entirely; every log is kept until manually deleted.
Storage cost is one wp_insert_post() call per outbound email. On a site sending a few hundred messages a day the table grows at the same rate as a publishing site posting a few hundred posts a day: noticeable in wp_posts row counts, invisible in real-world performance.
Uninstall removes the log_emails_limit_days option, clears the scheduled purge, and hard-deletes every log_emails_log post via wp_delete_post($post_id, true). There is no orphan cleanup concern after the plugin is removed.
A 2016 security fix (1.1.0) tightened access so that logged-in non-admin users could no longer read any log by guessing post IDs. Since then the CPT’s capabilities have been mapped to activate_plugins, with read_private_posts and publish_posts both set to do_not_allow. Only users who can install plugins see the log.
Where it sits against alternatives
Check & Log Email is the standalone-logger comparison. It hooks the wp_mail filter directly rather than recording through phpmailer_init, which means the Post SMTP coverage gap that catches Log Emails does not apply. The free version also ships a resend action, a test-send tool with custom headers, and a richer list-table UI. Active installs sit above 100,000. On a production site that needs logging only, Check & Log Email is generally the recommended choice.
WP Mail SMTP free does not log. The Pro tier ($49+/year) does. Log Emails is the path for the operator who wants logging on a working WP Mail SMTP free install and is not paying for Pro.
FluentSMTP and Post SMTP both include logging in their free versions. Adding Log Emails on top of either gains nothing. On FluentSMTP it records the same sends the mailer’s own log already holds. In Post SMTP’s default mode it records nothing, and the mailer’s own log is the only one of the two that sees the send.
Disable Emails, from the same vendor, is the canonical pairing. Disable Emails replaces wp_mail with a no-op so nothing leaves the box; Log Emails records what would have been sent. Together the pair is the standard “capture but do not deliver” setup for staging, development, and freshly imported environments. Disable Emails fires the standard post-send actions through its PHPMailer mock, so phpmailer_init runs and Log Emails captures normally.
Assessment
Log Emails is the right install on a development or staging environment paired with Disable Emails. The vendor designed the two together, the coverage they share is whatever passes through wp_mail and phpmailer_init, and that is the set the operator wants to inspect. The pair is free, narrowly scoped, and survives a database refresh without configuration drift.
It is the second-best free choice on a production site that needs logging without paying for it. Check & Log Email’s wp_mail-filter capture point sees the messages Log Emails misses, the resend action covers the recovery case Log Emails cannot, and the install base reflects the trade-off. The case for picking Log Emails over Check & Log Email on a production site is narrow: a preference for the smaller, more focused plugin, an existing relationship with the WebAware ecosystem, or a desire to mirror a dev environment that already runs the pair.
It is the wrong install on a site running Post SMTP in its default mailer mode. That mode never fires phpmailer_init, so the capture point is never reached. For that configuration the logger built into the mailer plugin, or a transport-level capture such as Mailpit or a host-side queue, is the correct layer. Sites whose mail is silently failing for unknown reasons should start at the WordPress email troubleshooting guide before changing the logger; the logger is a diagnostic surface, not a fix.
For the broader setup the plugin slots into, see how to set up WordPress email.
Plugin data verified August 2026 against 
wordpress.org/plugins/log-emails and the plugin source on the WordPress plugin SVN. Mailer coverage verified 2026-10-22 against the source of WP Mail SMTP 4.10.3, FluentSMTP 2.4.1 and Post SMTP 4.0.2.
Corrections
- 2026-10-22: an earlier version said Log Emails misses provider-API sends from WP Mail SMTP, FluentSMTP and Post SMTP because they short-circuit through
pre_wp_mail. None of them hookspre_wp_mail. Log Emails captures WP Mail SMTP and FluentSMTP sends in every mode, and misses every Post SMTP send in that plugin’s default mode.