Why your WordPress site cannot send email, and the fix

WordPress sends mail through the web server's own PHP mail function, and a large share of hosts block that path on purpose, because mail fired straight out of a web server tends to land in spam and gets server IP addresses blacklisted. That policy is why contact form notifications vanish and password reset emails never arrive. The fix is to route WordPress through a real sending path, an SMTP plugin wired to a genuine mailbox or a transactional email provider, and then set SPF, DKIM and DMARC on the domain so receiving servers trust what arrives.

Why hosts block PHP mail

The host is making a rational call. Email deliverability runs on IP reputation, and a web server's IP is shared, busy serving pages, and unmonitored as a mail sender. One compromised script on one tenant starts firing spam, a blocklist adds the address, and every message from that server starts bouncing or disappearing for weeks. So hosting providers disable PHP mail or block outbound SMTP, and they are right to. From inside a broken contact form it looks like a bug. From the provider's side it is containment, and the sturdier fact underneath is that a web server was never a good mail sender.

What the failure looks like

The symptoms usually arrive before the explanation. Form submissions appear in the plugin's entries screen while the notification email never comes. Password resets say check your inbox, and the inbox holds nothing. Order confirmations, new user welcomes, comment notifications: all silent. The form plugin gets the blame and a one-star review, and the plugin is innocent; it handed the message to the host's mail path and that path is closed. Confirming the diagnosis is quick, because the established SMTP plugins ship a send-test-email button, and a test message that never arrives while the plugin reports success means the sending path itself is the problem.

The two real fixes

Option one: an SMTP plugin, WP Mail SMTP being the long-established name with FluentSMTP and others beside it, pointed at a real mailbox on your domain. That is the mailbox you already pay for, at Google Workspace, Microsoft 365, Fastmail or wherever the domain's mail lives. WordPress then sends as an authenticated mailbox through servers whose entire job is delivering mail.

Option two: a transactional email provider, Postmark, Mailgun, SendGrid and Amazon SES among them, connected with an API key, often through the same plugins. Providers add delivery monitoring, bounce handling and a log of every message sent, which starts to matter the day email carries order confirmations or password resets at volume.

For a brochure site with one contact form, either approach works, and the mailbox you already have is the simpler start. When email carries revenue, send through a provider and read the logs. One piece of hygiene applies to both: use an app password or an API key rather than the main account password, because the credentials stored in WordPress grant sending rights for the whole domain.

SPF, DKIM and DMARC, in plain sentences

Three DNS records decide whether receiving servers believe your mail.

SPF is a list. A TXT record on the domain states which mail servers are allowed to send as yourdomain.com, and a receiver checks the server that actually sent the message against it.

DKIM is a signature. Every message leaves your provider cryptographically signed, and the public key that verifies the signature is published in your DNS. A message that arrives unaltered verifies; a message tampered with in transit does not.

DMARC is the policy. It tells receivers what to do when SPF and DKIM fail, report it or reject it outright, and gives them an address to send failure reports to, which is how you learn that something else is sending as your domain.

Your provider generates these records for its own setup, and the remaining work is pasting them into DNS and running a validation check. All three, set up once, are most of the distance between mail that lands and mail that filters.

Why email belongs with a specialist

Web hosting and email hosting want opposite things from a server. Web traffic is bursty and benefits from caching at the edge; mail delivery needs a steady sending reputation, patient queue handling and feedback loops with the big receivers. A bundle that promises both from one box tends to deliver neither well, and this predates WordPress: the free email that came with cheap shared hosting was known for losing messages. Managed WordPress platforms that skip email entirely are being honest about the split. Cloudways runs the site and leaves mail to whoever does mail well, a policy we treat as a point in the platform's favor in the Cloudways review. Your site's host and your domain's mail provider are allowed to be different companies, and usually they should be.