On Page Navigation
On Page Navigation
August 16, 2026
WordPress email fails quietly. A customer resets a password and nothing arrives. An order goes through and the receipt never lands. Nothing errors, the site looks fine, and the first you hear of it is a support message weeks later. The usual cause is that most shared hosts either block outbound mail or send it unauthenticated from an address with no reputation behind it. A mailbox provider sees a message claiming to come from your domain with nothing backing that claim, so it drops the message or files it as spam.
MountDev Cloudflare Email SMTP is a free WordPress plugin that fixes the sending side of that problem by routing every message through Cloudflare Email Service over an authenticated connection. It is a narrow tool with a narrow job, which is the reason it exists. If you want the whole picture of what authenticated sending involves, our managed email service covers the surrounding territory.
The plugin replaces the wp_mail function itself. That single decision is what makes it comprehensive. Password resets, comment notifications, order receipts, form submissions and plugin alerts all take the same authenticated route, because they all call wp_mail underneath. You do not configure WooCommerce separately, and you do not configure your form plugin separately. Anything built on the standard WordPress mail function is covered the moment the plugin is active.
There is one exception worth knowing about. A plugin that opens its own connection and bypasses wp_mail entirely will not be affected. Those are uncommon, and the send log is how you find out whether you have one, because a message that never appears in the log never went through wp_mail.
The plugin connects to the Cloudflare SMTP host on port 465 and authenticates with a Cloudflare API token. The username is the literal string api_token and the password is the token value, which is a detail that catches people out because it does not look like a username and password pair. Configure it once and every message afterwards goes out against your own Cloudflare account rather than against whatever your host happens to permit that week.
Because the connection is a single provider rather than a picker, the settings screen asks for the fields Cloudflare actually needs and then stops. A general purpose SMTP plugin has to carry configuration for every service it supports, and most of that surface will never apply to your site. That breadth is a real advantage while you are still choosing a provider and a liability once you have chosen.
WordPress ships with a generic default sender name and address that rarely matches anyone's brand, and plugins tend to inherit that default without asking. The usual fix is a filter pasted into the theme functions file, which works until the theme updates and the snippet disappears with it. Nobody remembers why the emails suddenly changed.
The from address and from name live in the plugin settings instead, applied across the whole site. A theme update leaves them alone. If you have inherited a site where the sender has been wrong for a year, this is a two-field fix rather than a hunt through theme code somebody else wrote.
Every message the site sends is recorded with its recipient, subject, timestamp and the delivery status the send returned. That answers the question you actually have when somebody says an email never arrived, which is whether the message left at all and when. Without a log you are guessing at a mail queue you cannot see.
The log is a table in your own WordPress database. It is not pushed to a hosted dashboard, so there is no second account to hold and no copy of your email metadata sitting on somebody else's server. You query it like any other table, which matters if you ever need to answer a question the plugin screen does not answer.
You choose how long entries survive before the plugin clears them. The setting is really a trade. Enough history to settle a dispute, without a table that grows unchecked and turns up later as a database backup that has doubled in size on the busiest site you run. A low volume site can keep months of history without noticing. A store sending hundreds of messages a day wants a shorter window.
The settings screen sends a real test message through the connection you just configured and reports what happened. A wrong token, a domain that has not been onboarded for sending, or a from address the account will not permit all surface right there while you are still looking at the screen. The alternative is deploying and finding out from a customer whose receipt never came, which is a worse way to learn the same thing.
This plugin is for people who have already decided to send through Cloudflare. That is the single most useful thing to know before reading further, because it rules out a large group of readers honestly and quickly. The situations below are the ones where it is the right choice.
Your DNS is on Cloudflare, your Workers are on Cloudflare, and you are already paying for the Workers Paid plan. Bringing in a separate email vendor at that point adds a bill, an API key and another dashboard to keep track of, in exchange for a capability the account you already pay for includes. Keeping email on Cloudflare takes one vendor out of the stack, and the DNS records the service needs are added to a domain you already manage there.
Receipts and shipping notices are the messages customers notice the absence of, and unauthenticated host mail is usually where they disappear. Routing wp_mail through an authenticated service handles the delivery side of that. The log handles the other half, which is knowing which orders got their email and which did not, and being able to say so with a timestamp rather than an apology. If the underlying problem turns out to be the host rather than the authentication, that is a hosting conversation instead.
Rolling out one provider and one settings screen across thirty sites is a genuinely different job from rolling out a plugin that supports twenty providers. The configuration is identical on every site, the log sits in the same place on every site, and there is no per-site license key to track or renew. That predictability is worth more than flexibility once a fleet is large enough that you are documenting your own conventions, which is the same reason fleets end up on a standard maintenance routine.
You would happily never look at a host's sendmail configuration again. This hands outbound mail to a service with an API, a token and a status you can read, and it keeps the WordPress side down to one settings screen and one log table. There is nothing to debug in PHP once the token is right, which is the point.
This one is smaller than the others and comes up constantly. A site sends as WordPress from a wordpress@ address nobody reads, every plugin has inherited it, and the fix has been on somebody's list for months because it looks like it needs a developer. It does not. Set the two fields, save, and every message the site produces reads correctly from that point on. Whether the address you choose is one you can actually receive replies at is a separate question, and one worth answering with a real mailbox rather than a black hole.
If you are still comparing providers, install a multi-provider SMTP plugin instead. It is the better fit for where you are, and this one will get in your way, because switching providers with it means switching plugins. If your sending is bulk marketing rather than transactional mail, this is also the wrong tool, and the right one belongs to a platform built for marketing email with list management and unsubscribe handling attached. Cloudflare Email Service is built for transactional messages, and this plugin inherits that scope.
A plugin routes mail. It does not watch bounce rates, warm a sending domain, investigate a reputation problem or tell you that one mailbox provider started filtering you last Tuesday. Once outbound volume is high enough that those questions have owners, the plugin is one component of a larger arrangement rather than the whole answer, and managed transactional email is the shape that work takes.
Everything on this list belongs to Cloudflare rather than to WordPress, and none of it is something the plugin can arrange on your behalf. This is also why most setup problems start here rather than inside WordPress. Have all of it in hand before you install anything.
Your domain has to be using Cloudflare DNS. Cloudflare states this as a requirement for Email Service, and it is the prerequisite people miss most often because it sits underneath everything else. If your DNS is hosted elsewhere, that has to move first, and moving it is a separate piece of work with its own risks.
You need a Cloudflare account on the Workers Paid plan. Cloudflare documents sending to arbitrary recipients as a Workers Paid capability, with 3,000 outbound emails included per month and 0.35 US dollars per thousand after that, per account and aligned to your Cloudflare billing cycle. Sending to verified destination addresses in your own account is free on any plan, which is useful for testing and not useful for a real site, because your customers are not verified destinations. Those figures were checked against the Cloudflare Email Service pricing documentation on 16 August 2026, and Cloudflare can change them without telling us.
You need the sending domain onboarded for Email Sending. In the Cloudflare dashboard this is under Compute, then Email Service, then Email Sending, then Onboard Domain. Cloudflare adds MX, SPF and DKIM records against a cf-bounce subdomain of your domain, and a DMARC record on the _dmarc hostname. Cloudflare notes that DNS changes can take up to 24 hours to propagate globally although they usually complete within 15 minutes on Cloudflare DNS, so onboard the domain before the day you intend to switch a live store over.
Finally you need a Cloudflare API token with permission to send. Cloudflare documents the SMTP route as requiring a token with the Email Sending Edit permission, and the token has to belong to the account that owns the onboarded domain. A token from the wrong account will authenticate and then refuse your sender address, which is a confusing failure to read.
Install the plugin from the WordPress Plugin Directory through the Plugins screen in your own admin, the same way you install anything else, then activate it and open its settings screen.
Point it at the Cloudflare SMTP host on port 465. For the username enter the literal string api_token. For the password paste your Cloudflare API token. Cloudflare documents the same pairing for direct SMTP clients, so if you have ever sent a test message from a command line against this service, it is the identical credential shape.
Set the from address and the from name you want the whole site to use. The address has to be on the domain you onboarded. Then save.
Run the test send from the settings screen and wait for it to arrive. If it does, wp_mail is going through Cloudflare and every plugin on the site inherits that immediately, with nothing further to configure anywhere. If it does not, the error names the culprit, and the section below expands on what each answer means. Either way the log starts recording from that moment, so your first real send is already accounted for.
It is not free to send. The plugin costs nothing and has no paid tier, no license key and no feature held back behind an upgrade. The sending service behind it belongs to Cloudflare and it is not free. That distinction is the one thing on this page most worth reading twice, because the plugin listing says free and the bill arrives from somewhere else.
It is not multi-provider. It connects to Cloudflare Email Service and nothing else. If you switch providers you switch plugins, and the send log does not come with you.
It is not inbound mail. Cloudflare Email Routing forwards messages sent to addresses on your domain somewhere else. Email Sending is the outbound half. They sit under the same Cloudflare Email Service umbrella and they solve opposite problems, so turning Routing on will not make your site email start sending, and this plugin has no bearing on mail arriving.
It is not a deliverability programme. Authenticating your sending removes the most common reason messages disappear. It does not warm a domain, monitor bounce rates, manage a suppression list on your behalf or repair a reputation that was damaged before you arrived. The log tells you a message left. Whether it landed in an inbox or a spam folder is a question the log cannot answer.
It is not a bulk sending tool. Cloudflare builds Email Service for transactional messages, and there is no list management, segmentation or unsubscribe handling here because none of that belongs in an SMTP plugin.
It is not covered by Cloudflare support, and Cloudflare account questions are not covered by us. Questions about the plugin come to us. Questions about your plan, your domain onboarding or your API tokens go to Cloudflare, because we cannot see or change anything inside your account.
It is not a mature product underneath. Cloudflare still labels Email Sending as beta on its Email Service overview, and that belongs on this page rather than in a support conversation after you have moved a store's receipts onto it. Plenty of sites run it in production. Make that decision knowingly rather than assuming it carries the stability guarantee of a service that has been generally available for years.
Three causes account for nearly every failed setup, and they are worth checking in this order because each is faster to rule out than the one after it.
Start with the token. Confirm it was created on the account that owns the onboarded domain, that it carries the Email Sending Edit permission, and that it was pasted whole. A token copied with trailing whitespace fails in a way that looks exactly like a wrong token. Remember that the username field is the literal string api_token and not your email address, because entering an email address there is the most common single mistake in this setup.
Then check the domain and the from address. The sender domain must be onboarded for Email Sending on the account that owns the token, and Cloudflare will refuse a from address it does not recognise even when the token itself is valid. If the domain was onboarded recently, check the DNS records actually landed, and give propagation time before concluding anything. Cloudflare adds those records against your domain automatically only when the domain sits on Cloudflare DNS.
Then check whether the message went through wp_mail at all. Open the log. If the message you expected is not in it, the plugin never saw it, which means something bypassed wp_mail and no amount of SMTP configuration will change that. This is the case that wastes the most time, because it looks identical from the outside to a connection problem and has nothing to do with the connection.
If all three are clean and messages are being accepted but not arriving, you have moved from a sending problem to a deliverability problem. The log will show sends succeeding. Look at the recipient side, at your DMARC policy, and at whether the domain has any sending history at all. A domain that has never sent mail before is treated with suspicion for a while, and that is normal rather than a fault.
The feature list, the frequently asked questions and the download link are on the Email Delivery for Cloudflare product page. The Cloudflare getting started guide for Email Service is the authority on the account side, including domain onboarding and the SMTP connection details, and it is the page to check first if something on the Cloudflare side has changed since this was written.
If you are here because a site is behaving badly in more ways than one, our note on WordPress maintenance mode covers a related habit worth having. Our other free WordPress tool is the WordPress MCP connector, which is a different kind of thing entirely and documented in its own guide. The rest of what we have written for people already running something sits in the documentation library.