Troubleshooting

WordPress isn’t sending emails.

The form says thank you, the order goes through, and nothing lands in any inbox. Before trying fixes at random, answer one question: do your emails fail to leave the site, or leave and fail to arrive? The fix is different for each, and this page takes them in order.

Diagnosis · in order 10 minutes

01 · The mechanics

Why WordPress email breaks
without an error.

Nothing bounced, nothing warned you, and the site itself reported success. That silence is built into how WordPress sends email.

Every email your site produces, from the contact form to the password reset, goes through one function, wp_mail(). Out of the box it hands the message to the web server’s PHP mail() function: no authentication, no password, posted from whatever address the server chooses. Spammers loved that arrangement, so most hosting companies now throttle it, filter it or switch it off, and receiving servers distrust what still gets through.

Two properties of this setup matter for diagnosis. WordPress does not record what it sends, so there is no built-in list to consult. And when the receiving side discards the message as unauthenticated, nothing comes back: the failure is invisible from your side. Which is why step one is not a fix at all, it is getting visibility.

02 · Triage

One question first:
does the email leave at all?

Ten minutes with an email log answers it. Any logging plugin will do; Custom SMTP starts recording at activation, before any configuration.

STEP 01

Install a log

Install and activate Custom SMTP, or any plugin that logs email. From that moment, every message your site tries to send gets a row with its outcome.

STEP 02

Trigger the email

Submit the form, request a password reset, or use the plugin’s Send Test Email button. Then open the log and find the row it just created.

STEP 03

Read the row

Failed, with an error message: the email never left, go to 03. Sent, but nothing arrives: the problem is on the receiving side, go to 04.

Email Logsa failed row names its cause
The Email Logs screen in wp-admin: sent and failed messages listed with their status, and a failed row showing the exact SMTP error returned by the server.

03 · Not sent

The email
never leaves.

A failed row carries the error the server returned, and that sentence names the cause. These are the ones behind almost every “nothing sends” report.

  • Your host has restricted PHP mail(). Common on modern hosting, and the host is not wrong to do it. Do not ask for it back: unauthenticated mail lands in spam anyway. The fix is sending through an authenticated SMTP server instead, which is section 05.
  • “Could not authenticate”. The SMTP server refused the username or password. Providers with two-factor authentication expect an app password rather than your account password, and transactional providers expect an API key. Your provider guide says which one and where to create it.
  • Connection timed out, or refused. The request never reached the mail server. Check the host name for typos, then try the provider’s alternate port. If nothing passes on any port, your hosting company may block outbound SMTP connections; its support can confirm which ports are open.
  • Two plugins are fighting over the mailer. Two SMTP plugins active at once both reconfigure the same PHPMailer, and the loser’s settings silently vanish. Keep exactly one.
  • The form plugin never created the email. Form plugins have their own notification settings, separate from WordPress. If the log shows no row at all when you submit the form, the form’s notification is disabled or misaddressed; that is fixed inside the form plugin, not in WordPress.

The failure section of the docs matches the exact error messages, word for word, to their causes.

04 · Not delivered

“Sent”, but
never received.

Sent means a server accepted the message. What the receiving side did with it next is a judgement about your domain, and it happens in three DNS records.

  • Check the spam folder first. Obvious, and still the answer often enough that it stays at the top of this list.
  • The From address is not yours to send from. A message sent “from” an address at a domain that never authorised your server reads as forgery. Use an address at your own domain, or send through the provider that owns the address.
  • SPF, DKIM and DMARC are missing or point elsewhere. These three DNS records are how a receiving server decides your message is genuine. They are set at your DNS host, take a few minutes each, and the deliverability section explains all three in plain words.
  • The rest is in your provider’s dashboard. Once a provider accepts a message, its own activity log shows bounces and blocks the plugin cannot see. A new Amazon SES account in sandbox mode, for instance, silently delivers only to verified recipients.

05 · The durable fix

The fix: authenticated SMTP,
with a log kept on.

Every cause above ends at the same place: stop relying on unauthenticated server mail, send through a provider that vouches for you, and keep the log so the next failure has a visible cause.

You almost certainly have such a provider already: your hosting plan includes an SMTP server, and Gmail, Outlook, Brevo, SendGrid and the others all take authenticated mail from WordPress. Pick yours from the list below; each guide shows where the credentials live, the exact settings the preset fills in, and the pitfalls that provider hides.

Everything this page relies on, the SMTP sending, the log, the test buttons and the failure alerts, is in the free plugin. There is no paid tier holding the useful part back.

Pick your provider

Twelve step-by-step guides: Gmail, Outlook, Amazon SES, SendGrid, Mailgun, Brevo, Postmark, Mailjet, Zoho, Yahoo, iCloud and Scaleway, plus any SMTP server your host provides.

The provider guides

06 · FAQ

Questions that
keep coming back.

The short versions, with the long versions one link away.

Is it my host’s fault or WordPress’s?

Both, by design. WordPress hands email to the server’s mail() function; the host restricts that function because spammers abused it. Neither side is going to change, which is why the durable fix is authenticated SMTP rather than a support ticket.

My contact form says the message was sent.

The form plugin reports that it handed the message to WordPress, nothing more. Whether a mail server accepted it, and what the receiving side did next, is exactly what it cannot see. An email log shows the difference in one glance: a failed row with an error, or a sent row that the receiver then discarded.

Do I need a paid plugin to fix this?

No. Authenticated SMTP, an email log, previews, resend and failure alerts are all in the free Custom SMTP plugin, with no account to create and no pro version. Some other SMTP plugins put the log or the alerts behind a paid tier; that is a pricing choice, not a technical requirement.

Will deactivating plugins or switching themes fix it?

Only when the cause is two mailer plugins fighting, or a form plugin with its notifications off. The underlying problem, unauthenticated server mail that receivers distrust, stays whatever the theme. Diagnose with the log first; it is faster than elimination.

It worked for years and stopped without any change on my side.

Something changed off your site: the host tightened its mail policy, or a mailbox provider raised its authentication requirements, as the large ones periodically do. Your email was surviving on tolerance, and the tolerance ended. The fix is the same durable one, and it survives the next tightening too.

Already installed, still stuck?

The docs match each exact error message to its cause, screen by screen, and the support forum is read and answered.

Read the docs