WordPress Not Sending Any Emails? Here's the Real Cause.

What is the problem?

Every email WordPress sends — a password reset, a comment notification, a form submission, a plugin alert — goes through the same core function, wp_mail(). By default, that function hands the message to PHP's built-in mail() function, which depends entirely on how your hosting server is configured to send outbound mail. When that chain breaks, every WordPress email fails the same way, regardless of what triggered it or which plugin was involved.

Quick answer: install a mail-logging plugin (like WP Mail Logging) first. It shows you exactly what WordPress attempted to send and whether the server accepted or rejected it, which tells you immediately whether this is a WordPress-side problem or a mail-delivery problem happening after WordPress has already done its part.

The most important thing to establish early is scope: is this every single WordPress email, or just one specific type from one specific plugin? If it's everything, the fix is almost always proper SMTP configuration. If it's isolated to one plugin's notifications, check that plugin's own email settings before assuming a server-wide problem.

Common symptoms

• Password reset emails never arrive, for any user, including administrators
• Contact form submissions (Contact Form 7, WPForms, Gravity Forms) appear to submit successfully but the notification email never reaches its destination
• New comment or new user registration notifications stop arriving
• No error is shown anywhere — WordPress behaves as though the email was sent successfully
• It started right after a host migration, a hosting plan change, or a new security plugin being installed
• Emails intermittently arrive for some addresses (like Gmail) but not others, suggesting a spam or authentication issue rather than a total block

Why does this happen?

PHP's default mail() function, which wp_mail() falls back to without any additional configuration, sends email in a way that's frequently blocked, rate-limited, or left unauthenticated by shared hosting providers — many hosts restrict it deliberately to prevent their servers from being used for spam. Even when it isn't blocked outright, mail sent this way often lacks the SPF, DKIM and DMARC authentication that modern receiving mail servers (Gmail, Outlook, Yahoo) increasingly require before they'll accept a message into someone's inbox rather than silently dropping or spam-filtering it.

Because wp_mail() reports success the moment it hands the message to the server, not once delivery is confirmed, WordPress itself has no visibility into any of this. From its perspective, everything worked; the failure happens entirely downstream, invisible unless you specifically check for it.

Common technical causes

• PHP's mail() function blocked or disabled by the host, common on budget shared hosting and increasingly common generally as hosts tighten anti-spam policy
• No SPF, DKIM or DMARC records configured for the sending domain, causing receiving servers to reject or spam-filter messages that do get sent
• An expired or misconfigured SMTP plugin, sending with credentials or a connection setting that quietly stopped working after a password change or provider update
• A plugin conflict interrupting the email-sending process before wp_mail() is called, particularly after a recent plugin or theme update
• WP-Cron not firing reliably on a low-traffic site, delaying any email a plugin schedules to send via a background task rather than immediately
• The “from” address using a domain the sending method isn't authorized for, which many receiving servers and some SMTP providers reject outright

How to diagnose it

1. Install a mail-logging plugin (WP Mail Logging is free and lightweight) and trigger a test — a password reset is the fastest reliable trigger. Check whether WordPress even attempted to send it, and what response it got back.
2. Confirm the scope — test a password reset, a contact form, and any other email type in use. If all fail, this is a site-wide delivery problem, not something isolated to one plugin.
3. Check whether an SMTP plugin is already installed and, if so, use its built-in test-email tool to confirm current credentials genuinely still work.
4. Check the recipient's spam/junk folder and, if you can, the message headers of anything that did arrive, for SPF or DKIM alignment failures.
5. Check your host's documentation or support for whether PHP's mail() function is restricted or disabled on your specific plan.

How to fix it, step by step

1. Set up SMTP through a proper transactional email provider (Brevo, SendGrid, Amazon SES, or your host's own SMTP service if they offer one) using a plugin like WP Mail SMTP, rather than relying on PHP's default mail function.
2. Add the SPF, DKIM and DMARC DNS records your provider gives you for the sending domain — this step is what actually gets messages accepted into inboxes rather than spam-filtered.
3. Send a real test email through the plugin's testing tool after setup, then trigger an actual password reset to confirm the full flow works end to end.
4. If credentials had expired, generate fresh ones from your provider and update them in the SMTP plugin's settings.
5. Set up a genuine server-level cron job hitting wp-cron.php on a schedule if WP-Cron reliability was contributing, rather than depending on visitor traffic to trigger scheduled sends.
6. Re-test every email type in use on the site (password reset, contact form, any plugin notifications) rather than assuming one successful test covers all of them.

When this needs professional help

Installing a mail-logging plugin and checking an existing SMTP setup's test button are realistic to do yourself. It's worth bringing in a developer when:

• You need SMTP configured from scratch, including choosing a provider and setting up DNS authentication records correctly
• Emails are sending but consistently landing in spam despite authentication being in place, which needs a proper deliverability review
• The mail log shows a PHP error interrupting the send that needs tracing back to a specific plugin or piece of custom code
• The site depends on transactional email (password resets, order confirmations, form leads) and needs this fixed reliably, not through repeated trial and error

How I can help

A site that silently fails to send email loses leads and locks out users without ever showing an error, which makes it one of the more consequential quiet failures a WordPress site can have. I set up proper SMTP with authenticated DNS records, confirm every email type on the site with a real end-to-end test, and check deliverability rather than stopping at “the test email arrived.”