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
Continue the diagnosis
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 →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Why doesn't WordPress show an error when an email fails to deliver?+
WordPress hands email off to the server's basic mail() function, which has no authentication behind it, and reports the message as sent because it handed it over successfully. What happens to it afterward, whether it's dropped or filed as spam, is invisible to WordPress, so failures surface indirectly, like a customer never getting a receipt.
How can I tell if this is a WordPress problem or an email authentication problem?+
Send a test email to two different providers, for example a Gmail and an Outlook address. Delivery to one but not the other indicates an authentication problem specific to how that provider evaluates your sending domain, not a bug in WordPress itself.
Is installing an SMTP plugin enough on its own, or do I need to do more?+
Configuring authenticated SMTP is necessary but not sufficient. You also need to publish and align SPF and DKIM DNS records for the sending domain, plus a DMARC record, since adjusting WordPress settings while the underlying domain authentication is missing won't reliably fix delivery.
How do I confirm an email is actually authenticating properly once I've made changes?+
Inspect the headers of a message that arrived and look for spf=pass and dkim=pass. Then specifically test the messages the business depends on, password resets, order confirmations, form notifications, and admin alerts, confirming each lands in the inbox rather than spam.