Troubleshooting WordPress email: a reference

A WordPress site’s password reset email never arrives. A WooCommerce order confirmation lands in the customer’s spam folder. A contact form appears to submit, the admin notification was supposed to go to the business owner, and the business owner is on the phone saying it never came. The usual next move is a search like “WordPress not sending email,” and the usual next move after that is a long troubleshooting post listing twenty things to check in sequence.

This reference takes the diagnostic the other way around. There are only four places a WordPress email can fail: the plugin that intercepts the send, the way the server hands the message out, the external service doing the actual delivery, or the inbox on the other end deciding whether to accept it. The symptom (silent send, bounce, spam placement) does not say which of the four places failed, and that is the whole reason WordPress email problems so often persist across multiple attempts at a fix. The method here is to find the place first, then look at the right thing. The full procedural walkthrough is troubleshoot WordPress email; the chain this diagnosis sits inside is how email works on WordPress.

The four stages, in order

1. The sending plugin layer. A mailer plugin (WP Mail SMTP, FluentSMTP, Post SMTP) intercepts wp_mail() and hands the message to the configured transport. A failure here looks like: the plugin’s log shows no entry for the expected message, or the entry shows a configuration-side error (authentication rejected, host unreachable).
2. The transport. Default WordPress hands the message to PHP’s mail() function, which delegates to the server’s local MTA. A failure here looks like: wp_mail() returns false, or returns true but no message ever lands because the host dropped it silently. This is the default-path failure most managed hosting exhibits.
3. The relay’s outbound infrastructure. The external email service accepts the message, authenticates it against your sending domain’s DNS records, and attempts delivery. A failure here looks like: the provider’s dashboard shows the message as rejected (bad credentials, suspended account, over quota) or the provider sends it but the authentication records on your domain do not back it up.
4. The receiver. Gmail, Outlook, Yahoo, or a corporate mail server accepts, defers, bounces, or files the message in spam. A failure here looks like: the provider’s log shows the message sent, but the recipient reports nothing arrived, or finds it in their spam folder.

Diagnosis moves top-down. If stage 1 shows no record of the message, stop and fix stage 1; stages 2 through 4 never ran. If stage 1 shows the message was handed off but stage 3 shows it rejected, the fix is in stage 3 (credentials, DNS, provider status). If stage 3 shows the message delivered but the recipient never got it, the fix is in stage 4 (authentication records, reputation, content).

Where to look at each stage

Stage 1. The mailer plugin’s log. WP Mail SMTP, FluentSMTP, and Post SMTP all record every attempted send. A missing entry is a stronger signal than a failed entry: it means the message never reached the mailer plugin, which means either wp_mail() was not called (a plugin bypassing it with a direct PHP mail() call), or the mailer plugin is not actually active for the message’s send path.

Stage 2. Only relevant if no mailer plugin is configured. The failure signal is wp_mail() returning false. WordPress does not retry and does not log the failure unless a plugin hooks wp_mail_failed. The wp_mail_failed hook debugging guide covers the hook.

Stage 3. The relay’s own dashboard. Postmark, SendGrid, Mailgun, Amazon SES, and SMTP2GO each show a Sent / Delivered / Bounced status per message. A message that appears in stage 1’s log as “sent” but is absent from the provider’s dashboard did not reach the provider; the credentials or endpoint are wrong. A message present at the provider but marked Bounced carries an SMTP response code; decoding the code is in reading SMTP bounce codes.

Stage 4. Receiver-side. For Gmail and Yahoo, the authentication codes (5.7.26, 5.7.27, 5.7.30, 5.7.40) point at missing or misaligned SPF, DKIM, or DMARC on the sending domain. For Microsoft 365, the 5.7.1 family carries three unrelated meanings distinguishable only by the accompanying prose. The SMTP field manual decodes the codes WordPress senders actually see.

Common WordPress-specific failure modes

Three failure shapes account for most WordPress email trouble tickets:

• The host silently dropped the message. Stage 2 failure. Default wp_mail() on managed hosting without an MTA, or with outbound SMTP ports blocked, returns true but the message vanishes. The fix is a mailer plugin routing through an external relay.
• The plugin bypassed wp_mail(). Older contact-form plugins and some payment-gateway notification code call PHP’s mail() directly, skipping the mailer plugin entirely. Diagnostic signal: the mailer plugin’s log shows no entry for messages the user expects to see. The fix is either a plugin update or a replacement plugin that routes through wp_mail().
• The authentication records do not align with the From: domain. Stage 4. The provider sends the message, Gmail checks SPF and DKIM against the From: domain, neither aligns, DMARC fails, the message bounces or lands in spam. The fix is DKIM alignment on the sending domain (provider’s custom-signature setup) and an SPF entry that covers the provider’s sending hosts. See SPF and DMARC.

When the symptom is “no error anywhere”

A send that produces no log entry, no bounce, no spam placement, and no inbox arrival is a stage 1 or stage 2 problem by elimination. Either wp_mail() was never called (something is bypassing it, or the triggering plugin’s send is failing before the call), or wp_mail() was called, returned true, and the message exited through the local MTA into a void. The diagnosis for the first case is a code search for direct mail() calls; the diagnosis for the second case is installing a mailer plugin and sending a test, which will show immediately whether the previous silence was a dropped transport.

The WordPress email FAQ covers the top-of-funnel questions this reference does not. The full procedural walkthrough for a live incident is troubleshoot WordPress email.