A true result from wp_mail() means WordPress passed the message to its configured mailer without an immediate error. It does not mean the SMTP server accepted it, the recipient gateway delivered it or the user saw it in the inbox.
Keep the true result as one checkpoint and continue tracing the same controlled message.
Create a traceable test
Use a synthetic recipient you control, a unique subject reference and no personal data. Record the exact time, site environment and code path that called wp_mail().
Test the real form or application action as well as any mail-plugin test screen. A test screen may use different headers, recipient and execution timing.
Avoid looping many tests; rate limits can obscure the original issue.
Interpret the return value correctly
WordPress builds the message with PHPMailer and applies mail-related hooks before attempting delivery. A true boolean means no synchronous failure was reported at that stage.
If WordPress uses local PHP mail, the operating system may accept the message into a local queue that later rejects it. With SMTP, a plugin may log more specific connection and provider responses.
The return value cannot describe spam filtering, quarantine or a later bounce.
Capture WordPress mail failures safely
For a short controlled diagnostic, a developer can log only the error code and message from the wp_mail_failed hook. Do not log the full mail data on a production site because it may include recipients, form contents and attachments.
add_action('wp_mail_failed', function (WP_Error $error): void {
error_log(
'WordPress mail failure: ' .
sanitize_text_field($error->get_error_code()) . ' | ' .
sanitize_text_field($error->get_error_message())
);
});Place temporary code in an appropriate development mechanism, retain a rollback and remove it after testing. Keep error logs outside public access.
Identify the active transport
Determine whether mail goes through PHP mail, sendmail, a hosting relay, SMTP or an API-based transactional provider. Check the active plugin and hosting configuration rather than assuming an installed SMTP plugin owns every message.
Review the From address, return path and actual sending domain. Use an authenticated domain address in From and the visitor in Reply-To.
If local mail is used, inspect the cPanel or Plesk mail queue and delivery log with authorised access.
Search the provider by message
Find the unique test in the SMTP or transactional provider’s activity log. Note whether it was accepted, deferred, bounced, rejected or suppressed and record the provider message ID.
If it is absent, the message did not reach that provider despite the WordPress result; inspect routing, local queues and plugin ownership.
If rejected, use the exact response code to repair credentials, sender authorisation, rate limits or recipient status.
Inspect authentication and bounces
Check SPF, DKIM and DMARC for the actual provider and From domain. A website A record does not authorise email, and MX normally controls inbound routing rather than WordPress sending.
Monitor the authenticated return-path mailbox for non-delivery reports. Some bounces arrive after the original request has completed, so they cannot change the earlier PHP boolean.
Do not create a second SPF record or publish private DKIM keys.
Trace the recipient gateway
After provider acceptance, ask the authorised mail administrator to search by message ID, timestamp, sender and recipient. Review organisation quarantine, transport rules, aliases, distribution groups and mailbox quota.
Testing only Gmail is insufficient when the real recipient uses Microsoft 365, Google Workspace or another corporate gateway with different policies.
Inspect a delivered copy’s full headers without publishing personal addresses.
Verify the complete delivery result
After fixing the identified handoff, call the real action once with a new reference. Confirm the wp_mail() result, local/provider acceptance, authentication results and final mailbox arrival.
Check Reply-To, attachments and conditional recipients. Keep a protected delivery log or provider alert appropriate to the site’s lead volume.
Request urgent repair when local and provider logs disagree, bounces are unclear or submissions are commercially important. Share timestamps and redacted codes—never credentials or message bodies.