Using Cloudflare Email Routing Without Breaking DMARC

If you set up Cloudflare Email Routing without adjusting your DNS records, your transactional email will start failing DMARC. Specifically: Cloudflare Email Sending (their SMTP relay) requires its own SPF mechanism and DKIM configuration, separate from your inbound MX setup. DMARCFlow can help you verify alignment during this process, but the DNS changes are yours to make.

Two Cloudflare Email Scenarios and Why Only One Affects DMARC

Inbound: Cloudflare Email Routing
When someone sends mail to your domain, their mail server delivers it to the MX records you set in Cloudflare. Cloudflare then forwards that mail to wherever you configured it. This part has no effect on your outbound DMARC validation. Recipient servers check your DMARC record against the sending server, not your inbound MX handler.

Outbound: Cloudflare Email Sending
When you send transactional mail through Cloudflare's SMTP relay (smtp.mx.cloudflare.net), Cloudflare acts as your sending mail server. Your SPF record must include include:cfmail.com. Your DKIM configuration must cover Cloudflare's signing. If your DMARC record still only authorizes your old MTA, your emails fail alignment.

The concrete problem: most people enable Cloudflare Email Sending and forget to update their SPF record. Within hours, their password reset emails start failing DMARC at Gmail, Microsoft, and Apple. By the time they notice, support tickets are already piling up.

SPF Configuration for Cloudflare Email Sending

Add Cloudflare's SPF mechanism to your existing SPF record. If you were already sending through another provider, add both:

v=spf1 include:_spf.google.com include:cfmail.com ~all

Replace _spf.google.com with your actual provider's SPF mechanism. The ~all softfail is intentional during the testing phase. Once you have confirmed all legitimate senders are covered in your aggregate reports, move to -all for a hard fail.

If you use Cloudflare Email Sending for multiple domains, each domain needs its own SPF record with its own cfmail.com include. Shared SPF records across domains do not work correctly here.

During the observation phase, Cloudflare aggregate reports show you exactly which sending IPs are passing or failing for each domain. DMARCFlow aggregates this data across all your domains so you can spot gaps before moving to enforcement.

DKIM Signing for Cloudflare Outbound Email

Cloudflare Email Sending supports DKIM signing, but it is not automatic. To enable it:

1. Cloudflare dashboard, go to Email > Email Sending
2. Find DKIM signing and turn it on
3. Add the CNAME record Cloudflare shows you

The record looks like:

cloudflare._domainkey.yourdomain.com  CNAME  cfmail._domainkey.cloudflare.net

Once the DNS propagates, Cloudflare signs your outgoing mail with a DKIM key tied to your domain. Recipient servers then validate both SPF and DKIM, giving you two passing checks instead of one.

Without DKIM signing, you rely entirely on SPF alignment. That works, but DKIM gives you a second line of defense and makes forensic reports easier to interpret.

Your DMARC Record When Using Cloudflare SMTP

A working baseline record for a domain using Cloudflare Email Sending alongside another provider:

v=DMARC1; p=quarantine; rua=mailto:reports@yourdomain.com; sp=reject; pct=100

The sp=reject applies your policy to subdomains. If Cloudflare only handles specific subdomains, use a less strict sp value for those.

Start at p=none. Yes, this means recipient servers accept mail regardless of alignment, but they also send aggregate reports. Those reports are your only way to see what is actually passing before you enforce a policy that might block legitimate mail.

Two weeks minimum for the observation phase. Four weeks is better. Look specifically for failures from sources you control, which indicate missing entries in your SPF record.

How Cloudflare Email Routing Forwarding Affects DMARC

Cloudflare Email Routing is MX-level. When a message arrives at your MX, Cloudflare receives it and forwards it to your configured destination. The DMARC check runs at the time of delivery to the final mailbox provider. Your original domain's DMARC record does not apply to the forwarding chain.

Where things actually break: if you use Cloudflare Workers to modify email headers or the From address before forwarding, you can destroy DMARC alignment. Cloudflare's documentation recommends keeping header modifications minimal. Specifically, do not change the From address in a Worker unless you are comfortable with alignment failures.

For most users, Cloudflare Email Routing forwarding does not affect their outbound DMARC at all. The confusion comes from mixing up inbound and outbound email flows.

The Observation Phase - Start at p=none and Actually Use the Reports

p=none is not a delay tactic. It is the working phase where you collect data. Without aggregate reports, you have no visibility into what is actually passing or failing.

Your ruamailto destination receives XML aggregate reports. Parsing those by hand is painful. DMARCFlow processes them and shows you per-domain breakdowns: which sending IPs are passing, which are failing, and which sources you did not know were sending mail.

For Cloudflare Email Sending specifically, the aggregate report tells you whether Cloudflare's IPs are passing alignment. If you see failures where you expected passes, your SPF record is missing cfmail.com or DKIM signing is not yet active.

Move to p=quarantine only after two consecutive weeks with zero failures from your known sending sources. Move to p=reject after another clean period.

FAQ

Does Cloudflare Email Routing change my DMARC record?
No. Cloudflare Email Routing handles inbound delivery. Your DMARC record applies to outbound email. Changing your MX records does not require a DMARC change unless you also change how you send outbound mail.

Can I use Cloudflare Email Sending and Google Workspace at the same time?
Yes. Your SPF record can include both include:_spf.google.com and include:cfmail.com. Enable DKIM signing for both Cloudflare and Google Workspace, and make sure your DMARC policy applies to both senders.

What happens if I set p=reject immediately?
Your legitimate transactional email gets rejected. Password resets, order confirmations, and notification emails all fail DMARC alignment because your SPF record is incomplete. The observation phase exists to prevent this.

How do I check if my Cloudflare-sent email is passing DMARC?
Your aggregate reports are the source of truth. If you see failures from Cloudflare IPs in the reports, verify your SPF includes cfmail.com and that DKIM signing is enabled in the Cloudflare dashboard.

Can I use a subdomain for Cloudflare while keeping the root domain on another provider?
Yes. Set sp=reject on your root domain and use a less strict subdomain policy. This isolates any Cloudflare-specific issues to that subdomain rather than risking your root domain mail.

Bottom Line

Cloudflare Email Routing (inbound) requires no DMARC changes. Cloudflare Email Sending (outbound SMTP relay) requires three DNS updates:

Add include:cfmail.com to your SPF record
Enable DKIM signing in the Cloudflare dashboard and add the CNAME record
Set your DMARC record to p=none with an ruamailto address

DMARCFlow is the practical way to make use of those reports during observation. Without a tool that parses aggregate reports, you are reading raw XML files or ignoring the data entirely. Two to four weeks of clean aggregate reports, confirmed through DMARCFlow, is what tells you when it is safe to move to p=quarantine and eventually p=reject.