What You Get Instead Of Running Easy WP SMTP Yourself

Not quite, and we are honest about the beta. Cloudflare Email Service is still in beta, and Cloudflare says its APIs may change. That belongs on this page, not in a support conversation after you have already moved a store’s receipts onto it.

It is Cloudflare’s email product for developers, combining outbound sending with inbound routing under one service. It is built for transactional mail: password resets, order confirmations, verification messages, and alerts. You can reach it from Workers using a native binding, from any platform over its REST API, or over authenticated SMTP. This plugin uses the REST API, which is what lets ordinary WordPress talk to it without custom code.

Email Routing handles mail coming in, forwarding messages sent to addresses on your domain somewhere else. Email Sending handles mail going out. They sit under the same Cloudflare Email Service umbrella but solve opposite problems. This plugin is concerned only with outbound mail from your WordPress site, so Routing is not required, and switching it on will not make your site’s email start sending.

Three things. A Cloudflare account on the Workers Paid plan, the domain you intend to send from onboarded for Email Sending on that account, and a Cloudflare API token with permission to send. Have those ready before you install, because the plugin’s job is to use them, not to create them. Setup inside WordPress takes a couple of minutes once the token is in hand.

Install and activate the plugin, then open its settings screen. Enter your Cloudflare Account ID and paste your Cloudflare API token. Set the from address and from name you want the site to use, save, then run the test send. If the test message arrives, WordPress is sending through Cloudflare and you are done.

Yes, as long as the plugin sends through wp_mail, which the overwhelming majority do. Because this plugin replaces wp_mail itself rather than hooking one plugin at a time, anything built on the standard WordPress mail function is covered the moment you activate it. The rare exception is a plugin that opens its own connection and bypasses wp_mail entirely. Those are uncommon.

Most shared hosts either block outbound mail or send it unauthenticated from an IP with no reputation attached. Mailbox providers see a message claiming to come from your domain with nothing backing that claim, so they drop it or file it as spam. Nothing errors along the way, which is why the site looks fine while receipts and password resets never land.

Each entry holds the recipient, the subject, the time the message went out, and the delivery status the send returned. That covers the question you usually have, which is whether the message left at all and when. If a customer says a receipt never arrived, you check the log first and know right away whether to look at your site or at their inbox.

For as long as you tell the plugin to keep them. Retention is a setting, so you decide how much history is worth holding on to. A low volume site can keep months without noticing. A busy store sending hundreds of messages a day will want a shorter window, because the log lives in your database and an unbounded table gets expensive to carry through every backup.

Yes, both, and they apply across the whole site. WordPress ships with a generic default sender that rarely matches anyone’s brand, and plugins tend to inherit it without asking. Setting the from address and from name in one place corrects every message the site produces, with no theme edits and no snippet in functions.php waiting to be wiped out by the next update.

Use the test send on the settings screen. It pushes a real message through the connection you configured and reports back what happened. A wrong token, a domain that has not been onboarded for sending, or a from address the account is not permitted to use will all surface right there during setup. That beats finding out when a customer tells you their receipt never came.