WordPress emails not sending is rarely one fault. Mail passes through four links: WordPress generating the message, the server handing it off, the receiving side accepting it, and the inbox deciding not to junk it. Any link can fail while the others work, and the fix for one link does nothing for another. Test them in order and you will find the break in minutes.
First, describe the symptom precisely
The four links produce four different symptoms, so naming yours narrows the search immediately.
- Nothing arrives anywhere, including spam, for any message type. Suspect link one or two.
- Some messages arrive and others do not. Suspect the plugin that generates the missing ones, not the mail chain.
- Everything lands in spam. Links three and four, authentication and reputation.
- Only certain recipients never receive it, often everyone at one company. Their mail server is rejecting you, and the bounce says why.
- Mail is slow, arriving hours late. A queue problem on the sending side, usually a throttled host.
WordPress emails not sending at all and WordPress mail landing in spam are genuinely different faults. Fixing the second when you have the first wastes an afternoon.
WordPress emails not sending? Test link one: generation
First, trigger a password-reset email for a test account from the login screen. If nothing arrives anywhere, including spam, the question is whether WordPress even attempted the send.
A logging plugin that records every outgoing message answers this permanently, and it is the single most useful tool for this class of fault. It shows you the recipient, subject, headers and result for every message the site tried to send. In other words, stop testing inboxes and start reading a send log.
The log settles the first fork immediately. When WordPress emails not sending is really a generation fault, the message never appears in the log at all, so the fault sits in the plugin that should have created it rather than in mail delivery. A message that appears as sent but never arrives moves you to link two.
Link 2: the handoff from your server
By default WordPress hands mail to the web server’s local mailer through PHP. Shared hosts frequently disable, throttle or sandbox that mailer. Consequently mail “sends” without error and dies silently, which is the most common shape of WordPress emails not sending.
The durable fix is routing mail through an authenticated sending service over SMTP or an API. Then every message has a delivery record you can read, and the sending identity belongs to a domain you control.
However, before switching, check the simplest cause. WordPress sends from wordpress@yourdomain.com unless something changes it, and a security or form plugin update that rewrites the From address to a domain you do not own gets the message rejected outright. Set the From address to a real mailbox on your own domain and much of this class disappears.
Also check the obvious server-side blocks. Some hosts close outbound ports 25, 465 and 587 by default, which breaks SMTP silently until you ask them to open it or use an API-based sender instead.
Link 3: authentication records
If mail leaves the server but never arrives, the receiving side is likely rejecting or junking it for failing authentication.
Specifically, your domain needs SPF, DKIM and DMARC records that match whoever actually sends the mail. SPF lists the servers allowed to send for your domain. DKIM signs each message so the receiver can verify it was not altered. DMARC tells receivers what to do when the first two fail, and it is the record that turns silent junking into visible policy.
After any change of sending service these records must change too. Stale records from a previous setup are one of the most common silent killers, because the old provider’s servers are still authorised and the new one is not.
Since February 2024, Gmail and Yahoo have enforced authentication and one-click unsubscribe for bulk senders, and both have tightened requirements since. So “it worked last year” is not evidence that it works today. Check your current records rather than trusting the setup notes from whenever the site was built.
Link 4: inbox placement and reputation
Delivered-but-junked is a reputation problem rather than a configuration problem, so it needs a different fix. It is also the version of WordPress emails not sending that owners discover last, because the site reports every send as a success.
Transactional messages such as order confirmations and password resets belong on a separate sending identity from marketing mail. Then a newsletter’s complaint rate cannot sink your receipts. If order emails matter to your business, this separation is the single highest-value change available.
Meanwhile, content matters more than people expect. Messages that are mostly one image, that link to a shortener, or that come from a brand-new domain all attract filtering regardless of perfect authentication.
Read the bounce, because it usually names the fault
When mail is rejected outright, the receiving server explains why in the bounce, and that text is worth more than any amount of guessing.
- 550 5.7.1 or “message rejected due to policy”. Authentication or reputation. Check SPF, DKIM and DMARC first.
- 550 5.1.1 “user unknown”. The address does not exist. A data problem, not a mail problem.
- 421 or 4.x.x codes. A temporary deferral, usually rate limiting. The message may still arrive later.
- “SPF check failed” or “DKIM signature did not verify”. Named plainly, and the fix is in DNS.
Your sending service’s dashboard shows these bounces. The local PHP mailer usually does not, which is one more reason to move off it.
How to test properly
Most failed tests are bad tests, so it is worth doing this part carefully.
Send to at least two providers, one of them Gmail or Outlook. Mail to an address on your own domain frequently never leaves the server, because the mail system delivers it locally and skips every step you were trying to test.
Then check the spam folder before declaring the message lost. Also allow a few minutes: deferrals are common on first contact between two servers, and a message that arrives in ten minutes is a throttling story rather than a delivery failure.
Finally, test the message type that is actually failing. Password resets, order receipts and form notifications are generated by different code, and proving one works says nothing about the others.
When the host is the limit
Shared hosts cap outbound mail, commonly a few hundred messages per hour, and some count every recipient separately. A store running a sale can hit that ceiling in minutes.
The symptom is distinctive. Mail flows normally, then stops, then resumes an hour later, and WordPress emails not sending becomes an intermittent complaint that never reproduces when you test it. Your host can confirm the limit and the current usage faster than any plugin can.
Moving transactional mail to a dedicated sending service removes the ceiling and, more usefully, gives you a log that shows exactly which messages were throttled.
Store owners: order emails are the priority
On WooCommerce, missing order emails often surface as “checkout is broken” even though payment worked perfectly. Our guide to WooCommerce checkout faults covers that path, and the mail chain here is the other half of the same customer experience.
Two WooCommerce specifics are worth knowing. Order emails fire on status transitions, so an order stuck at pending payment never triggers the receipt no matter how healthy your mail setup is. And each email type can be switched off individually in the WooCommerce email settings, which is a surprisingly common cause of one missing message while everything else works.
Contact forms follow the same chain
Form plugins hand their messages to WordPress in the same way everything else does. So a contact form that reports success while nothing arrives is not a form problem, and reinstalling the form plugin will not fix it.
Test the chain rather than the form. If a password reset also fails to arrive, the form is innocent and the fault is in link two or three.
Quick checklist
In short: name the symptom, install a send log, and trigger a test message. Then confirm the handoff to an authenticated sending service, verify that SPF, DKIM and DMARC match the actual sender, and test a real inbox at a major provider.
Consequently WordPress emails not sending becomes a solved class of problem instead of a recurring mystery. Keep the send log running afterwards, because the next failure then announces itself instead of being discovered by a customer.
When you want the chain traced for you
We diagnose the full chain with evidence at each link: the send log, the handoff, the authentication records, and a real inbox test. Then we fix the broken link and record what changed. That is how our WordPress support service works on every fault.
Tell us which emails are missing and since when. If the site is also throwing errors or refusing to load, start instead with urgent WordPress help, because a site that cannot send mail is often a site that cannot do several other things either.
The official wp_mail documentation covers what WordPress itself does and does not handle, which is less than most people assume. The wp_mail_failed hook is what a send log uses to capture the errors WordPress otherwise discards.