Reading the log
Open Settings → WP Postman → Mail Log. Four numbers sit at the top:
Below the stats, each row shows a status dot, the subject line, recipient, sender, which delivery method handled it, and a timestamp. Click any row to expand full detail: exact recipients, sender with display name, sent timestamp in UTC, delivery method, an HTTP status code where one applies, and for failures, the specific error message returned.
Sent versus Delivered, and why it matters
This is the one distinction worth understanding before you draw any conclusion from the log.Sent: the message left your site successfully
Sent: the message left your site successfully
For SMTP-based methods (SMTP.com, Brevo, Mailgun, SendGrid, Gmail, Other SMTP), this is the only positive status you’ll ever see. Standard SMTP confirms that the receiving mail server accepted the message for further processing. It does not, and structurally cannot, confirm that the message landed in an inbox rather than a spam folder, or that it wasn’t silently dropped somewhere downstream. A row reading Sent for one of these methods is good news, but it isn’t proof of inbox placement.
Delivered: confirmed by the platform, relay method only
Delivered: confirmed by the platform, relay method only
Messages sent through the native WP Postman relay carry a transaction ID. Expanding one of these log rows shows a Fetch Live Status button that queries the delivery platform directly and can flip the row’s status from Sent to Delivered once the platform confirms the message reached its destination. This check also runs automatically in the background for recent messages. If you never see a row move to Delivered, that’s worth investigating (a bounce, a spam-folder placement your recipient hasn’t checked, or a genuinely stuck message), rather than assuming Sent was good enough.
A missing HTTP status code (shown as a dash) is normal for SMTP-based methods. Response codes are only populated for API-based sends, since standard SMTP reports success or failure through the protocol handshake itself rather than an HTTP status.
Message body preview
Each expanded row shows the message body as it was actually sent, rendered as HTML in a sandboxed frame if the message was HTML, or as plain text otherwise. This is frequently more useful than the subject and recipient alone, since a broken email template (a missing variable, an unrendered shortcode, a stray line of raw HTML) is usually invisible until you see the body exactly as WordPress generated it. Whether this preview is available depends on the Store Body setting, described below.Retention and storage settings
Two independent controls sit at the top of the Mail Log screen, both saved instantly with no separate Save button.Log Retention: situational, pick based on how you use the log
Log Retention: situational, pick based on how you use the log
Six options: Off, 1 Day, 7 Days, 1 Month, 6 Months, Forever. The default is 7 Days, which the plugin enforces by deleting expired rows every time the Mail Log screen loads.For most sites, 7 to 30 days is enough to catch and diagnose a delivery problem without the table growing indefinitely. Set it to Off only if you have a specific reason not to log at all, doing so means you lose your only record when a customer reports a missing password reset email. Reserve Forever for sites under a specific compliance or audit requirement, since an unbounded table on a high-volume sending site will eventually become large enough to slow down the Mail Log screen itself.
Store Body: situational, weigh debugging value against database size and content sensitivity
Store Body: situational, weigh debugging value against database size and content sensitivity
Defaults to on. When enabled, the full message body (HTML or plain text) is saved alongside every log entry, up to roughly 64KB per message, with anything longer truncated. When disabled, the log still records everything else (recipient, subject, status, error), just not the content of the message itself.Turn this off if your emails routinely contain sensitive content you’d rather not have sitting in a second location in your database, or if you’re on a storage-constrained hosting plan and sending genuinely high volume. Keep it on for most sites: being able to see the exact rendered body of a failed or malformed email is usually the fastest way to find a broken template, and it’s a much smaller cost than the time spent debugging blind.
Clearing the log
A Clear All button appears whenever the log has at least one entry. It truncates the entire table immediately.Using the log to troubleshoot
1
Filter by eye, not by field
The log doesn’t have a built-in filter or search box. For a small number of entries this doesn’t matter, for a busy site, narrow your search visually by scanning the status dots first, since Failed rows are the ones that need attention.
2
Open the failed row and read the exact error
The error message field is the literal response from the delivery method’s server or API, not a WP Postman-generated summary. An authentication failure, a rejected sender domain, and a connection timeout all produce distinctly different text here, and that text is the fastest path to the right fix in Delivery Method Configuration.
3
Cross-check against Debug Log for API-based failures
If the failed message was sent through the native WP Postman relay, the Debug Log tab holds the full raw request and response for the most recent attempt, useful when you need more detail than the summarized error message in the Mail Log row.
4
Send a fresh test after any fix
Once you’ve changed a setting based on what the log told you, send another test email and confirm the new attempt logs as Sent (or Delivered) before considering the issue closed.