Short answer: by default WordPress hands email to the server’s basic mail() function, which has no authentication behind it. Modern providers increasingly reject that, so messages are silently dropped or filed as spam rather than bouncing visibly.
Why the failure is silent
There is rarely an error on screen. WordPress reports the message as sent because it handed it over successfully; what happened afterwards is invisible to it. That is why it surfaces indirectly — a customer never got their receipt, or you cannot receive a password reset when locked out.
Diagnose it in minutes
- Install a mail-logging plugin, or send a test to two different providers (a Gmail and an Outlook address). Delivery to one but not the other is an authentication problem, not a WordPress bug.
- Inspect the headers of a message that did arrive to see how it authenticated (look for
spf=passanddkim=pass). - Check the from address and its domain alignment.
The durable fix: authenticated SMTP
Send through an authenticated service instead of mail(): your provider’s SMTP or a dedicated transactional service. Configure host, port (587 with TLS, or 465 with SSL), username and password, and set a from address on a domain you control. Then publish and align SPF and DKIM DNS records for that domain, and a DMARC record. This is far more reliable than adjusting WordPress settings while the underlying authentication is missing.
Verify what the business depends on
Test the messages that matter — password reset, order confirmation, form notification and admin alerts — and confirm each lands in the inbox rather than spam. Check that the reply-to routes somewhere a human reads.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
WordPress can hand a message to the local mail function successfully while the recipient never receives it. Submission, transport, authentication and mailbox placement must be tested separately.
Log the message WordPress generated, including from, reply-to and recipient.
Send controlled tests to more than one mailbox provider.
Inspect received headers for SPF, DKIM and DMARC alignment.
Use an authenticated transactional provider and monitor bounces or suppressions.
What must be verified
- Password reset, form and order messages are generated.
- Authentication passes for the sending domain.
- Messages reach multiple providers and bounces are observable.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →