A successful `wp_mail()` return means WordPress handed a message to its mail library; it does not prove that a receiving inbox accepted it. Delivery has several custody changes, and each needs evidence.
Use the sequence below as a diagnostic method, not as a promise that one setting fits every host; verify its example paths, privileges, and backup assumptions while working to separate wp_mail formatting, MTA or SMTP submission, DNS authentication, recipient filtering, and bounce handling.
Likely failure paths
- The host has no working local mail transfer agent or blocks PHP mail.
- SMTP credentials, encryption, sender identity, or port settings are wrong.
- SPF, DKIM, DMARC, reputation, or message content causes rejection or spam placement.
The branches are ordered to protect the strongest evidence around this possibility: the host has no working local mail transfer agent or blocks PHP mail. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Integration failures happen at custody boundaries; wordPress can format a request successfully while DNS, TLS, a proxy, remote service, authentication layer, or receiving provider rejects the next step; record what each boundary accepted—not just what the WordPress screen announced; in this guide, the practical goal is to separate wp_mail formatting, MTA or SMTP submission, DNS authentication, recipient filtering, and bounce handling.
A controlled investigation
- Send a uniquely identified test and log the application result without logging the message body or password.
- Inspect SMTP/MTA transaction and bounce logs for the recipient and timestamp.
- Verify the From domain’s SPF/DKIM/DMARC configuration and envelope sender alignment.
- Test two unrelated recipient providers and check spam folders.
The sequence moves from observation toward intervention. Preserve the result of the final check—test two unrelated recipient providers and check spam folders—because it provides a useful comparison after the repair.
One practical branch through the failure
The opening hypothesis is the host has no working local mail transfer agent or blocks PHP mail. Test it with the least invasive observation available: send a uniquely identified test and log the application result without logging the message body or password. Do not change configuration until the observation has been saved with a timestamp.
When that evidence is consistent with the hypothesis, stage this repair: configure a reputable authenticated SMTP or transactional provider with a verified sending domain. Otherwise, preserve the current state and advance to the next branch. This keeps rollback simple and prevents a second change from masking the first.
Make the smallest durable change
- Configure a reputable authenticated SMTP or transactional provider with a verified sending domain.
- Use a From address controlled by the site; keep the visitor address in Reply-To for contact forms.
- Process bounces and remove invalid recipients rather than repeatedly retrying.
Before applying “Configure a reputable authenticated SMTP or transactional provider with a verified sending domain,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can confirm acceptance in provider logs and receipt at multiple mailbox providers; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Separate generation from SMTP acceptance
On staging, send one traceable message to an inbox you control, then compare WordPress’s boolean result with the mail-provider event log.
wp eval 'var_dump( wp_mail(
"you-control@example.net",
"Fulmemo delivery test 2026-08-29T09:00Z",
"Trace this message in the configured mail provider."
) );'Interpretation and safety: A true value means WordPress handed the message to its mail layer; it does not prove inbox delivery. Replace the address and timestamp, and never test against an uninvolved recipient.
Close the incident with evidence
- Confirm acceptance in provider logs and receipt at multiple mailbox providers.
- Test password reset and administrative notifications, not just a plugin test message.
- Monitor bounce and complaint signals after deployment.
One successful refresh is not closure. Keep the incident open until you can also test password reset and administrative notifications, not just a plugin test message, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
A useful escalation contains the UTC timestamp, destination host or route, sanitized request/response headers, status and application error code, correlation ID, retry behavior, and the source IP when relevant; never send live credentials in a ticket; include the result of this first observation: send a uniquely identified test and log the application result without logging the message body or password.
State what was tested, including the result of “Send a uniquely identified test and log the application result without logging the message body or password,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Do not trade visibility for a green screen
- Do not publish SMTP credentials in wp-config examples or screenshots.
- Do not infer deliverability from a green ‘sent’ notice in WordPress.
Change record
Primary references
- WordPress mail — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Configure a reputable authenticated SMTP or transactional provider with a verified sending domain”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.