When emails go missing, everything slows down: customers don’t get order confirmations or password resets, support chases ghosts, and marketing loses trust in campaigns. The fastest way to cut through the guesswork is visibility. WP Email Log gives WordPress sites a clean, searchable record of every message your site attempts to send—recipient, subject, timestamp, headers, and status—so you can separate application bugs from deliverability issues in minutes. Prefer to trial the basics first? There’s a free version on WordPress.org: WP Email Log.
TL;DR (Should you use it?)
If your site sends transactional email—WooCommerce receipts, membership notices, password resets, contact-form alerts—this plugin is a low-effort safety net that pays off the first time something “mysteriously” fails. It won’t fix SPF/DKIM by itself, but it will tell you exactly what WordPress tried to send and when, which is step one to fixing the right layer.
Rating: 4.7 / 5
Best for: eCommerce, memberships/LMS, agencies, and any site where “we sent the email” matters
Skip if: your site barely sends email or all messaging is handled entirely off-site (e.g., via a headless stack and external ESP logs)
What WP Email Log actually does (and why it’s different)
-
Full logging of outgoing emails. Every call that flows through WordPress’s mail pipeline is logged with recipient, subject, status, timestamps, and raw headers.
-
Fast, filterable search. Find messages by subject, recipient, date range, or status when you’re triaging support tickets.
-
Deep inspection when needed. Click into an entry to inspect headers and see exactly how the message left your stack.
-
Operational add-ons. Re-send a message without recreating the event, auto-forward copies to a team inbox for oversight, or export slices of logs for audits and developer analysis.
The key difference from “it probably sent” is evidence. If the log shows a send with sane headers, you’re in deliverability land (SPF/DKIM/DMARC, provider filtering, IP reputation). If the log is silent, the application trigger didn’t fire—wrong hook, disabled template, dead cron, or a form that never called wp_mail().
Real-world problems it solves (every single week)
-
“I never got my order email.” Support can search the log by address, confirm the attempt, and move straight to spam checks and domain alignment instead of guessing.
-
Inconsistent password resets. Filter by subject, compare by recipient domain, and spot patterns (e.g., one corporate provider blocking your messages).
-
Contact-form black holes after updates. If a plugin update routed emails differently or stopped calling
wp_mail(), the absence of a log entry points to the fix. -
Scheduled jobs that “ran” but sent nothing. Logs reveal whether the job emitted any messages at all—if not, check cron; if yes, check SMTP/auth.
-
Header regressions. A theme or plugin tweak that changed From/Reply-To can tank deliverability. Headers in the log make this obvious.
Setup & first value (five minutes, really)
-
Install & activate. Add the plugin and confirm the Email Log menu appears.
-
Trigger a test email. Submit a contact form, run a password reset, or place a test order.
-
Open the log. You’ll see a new entry. Click it to view details (recipient, subject, timestamps, status, headers).
-
Act on what you see.
-
Logged but not received? Configure a real SMTP sender, align From with your authenticated domain, and set SPF/DKIM/DMARC.
-
No log entry? Fix the application layer (template settings, hooks, cron, form routing).
-
-
Enable add-ons if you need re-send, auto-forward to a shared inbox, or CSV exports for audits and devs.
How it fits into a reliable mail stack
-
Email generation (WordPress/plugins) → WP Email Log (observability) → SMTP/ESP (delivery) → Mailbox provider (filtering).
-
Use the log to verify generation and diagnose headers.
-
Use your SMTP/ESP dashboard (Postmark, SendGrid, SES, etc.) for delivery analytics and bounces.
-
Together they form end-to-end traceability.
What we like (Pros)
-
Instant clarity. You stop debating “did WordPress send it?” and start fixing either the app or deliverability layer.
-
Searchable evidence. Support can resolve tickets faster with timestamps and subjects, not hunches.
-
Add-ons that matter. Re-send saves time; auto-forward helps during high-risk changes; export gives devs real data.
-
Lightweight by design. The admin UI is focused and quick; no dashboard bloat.
-
Great for teams and agencies. Standardize a simple runbook: “Check Email Log → Check SMTP → Escalate.”
Where it could be better (Cons)
-
It logs—doesn’t deliver. You still need a proper SMTP plugin/service and domain authentication.
-
Retention is on you. You must set sane retention and pruning for privacy and performance.
-
Not a full SIEM. For enterprise-wide monitoring, you’ll still pair it with SMTP/ESP logs and alerting.
Who gets the most value
-
WooCommerce stores: Receipts, license keys, refunds—everything revenue-adjacent needs proof.
-
Membership/LMS sites: Onboarding, renewals, course notifications; logs reduce churn-causing failures.
-
Agencies: Faster triage across many clients; consistent SOPs and audit trails.
-
Teams in regulated niches: Headers + timestamps satisfy many audit/compliance questions.
Practical debugging playbook (copy/paste)
A) Order email “missing”
-
Search by customer email → entry found?
-
If yes, inspect headers; move to deliverability (spam, domain auth, SMTP/IP).
-
If no, check WooCommerce email settings/templates and order status transitions.
B) Resets fail for a specific provider
-
Filter by subject “Password Reset,” scan failures by domain.
-
Align From with your authenticated domain; verify SPF/DKIM/DMARC.
-
Consider rate limits and a warmed SMTP IP or reputable ESP.
C) Contact form stopped after updates
-
Submit a test; refresh the log.
-
No entry → form isn’t calling
wp_mail()→ fix plugin routing/settings. -
Entry exists but still no inbox → headers changed; fix From/Reply-To and test via SMTP.
D) Scheduled reports “ran,” no email
-
Check the time window in the log.
-
No entries → cron/job issue; yes entries → SMTP/auth/deliverability issue.
Privacy & retention (don’t gloss over this)
Email logs can include PII. Treat them like any operational record:
-
Retention: 30–90 days is typical—long enough to debug, not a second inbox.
-
Access: admins and trusted roles only.
-
Data minimization: avoid retaining full bodies unless necessary; headers + metadata usually suffice.
Pricing snapshot & value
The free version covers core visibility—ideal for stabilizing deliverability and building your runbook. When you need Re-send, Auto-forward, Export, and priority support, the PRO version (linked above) is the obvious next step. For most stores, one avoided support rabbit hole or a saved campaign launch covers the license.
Best practices to keep mail flowing
-
Use a real SMTP/ESP. Don’t rely on
wp_mail()+ PHP mail in production. -
Authenticate your domain. SPF, DKIM, and DMARC properly aligned—non-negotiable.
-
Standardize templates. Consistent From/Reply-To and stable HTML reduce spam flags.
-
Smoke test after changes. Any update touching email? Send a reset + place a test order → check the log.
-
Document your SOP. “When email breaks: Step 1 Email Log, Step 2 SMTP dashboard, Step 3 host/provider.”
Alternatives & how this compares
-
Only SMTP/ESP logs: useful, but they won’t show generation failures inside WordPress.
-
Full-blown monitoring tools: powerful but overkill for many sites (and still lack WP-level context).
-
“It probably sent” guessing: slow, expensive, and terrible for user trust.
WP Email Log wins by closing the observability gap inside WordPress itself—exactly where many failures originate.
Verdict
If you manage a site where emails matter (that’s most of them), WP Email Log is an easy recommendation. It won’t do the sending for you, but it will give you the truth: what WordPress tried to send and how. That single source of truth shortens support loops, speeds up root-cause analysis, and protects revenue when the stakes are high.
Score: 4.7 / 5 — Highly recommended as part of every production WordPress stack.