Cloudflare Email Routing Breaks DMARC

If you set up Cloudflare Email Routing and your DMARC aggregate reports filled up with failures, and you don't know why. This is one of the most common DMARC troubleshooting questions. The answer is that Cloudflare Email Routing and DMARC have a structural conflict that requires deliberate configuration to resolve.

Here I explain, what your options are, and how to monitor your setup going forward.

What Cloudflare Email Routing actually does

Cloudflare Email Routing lets you receive email at your domain and forward it to a personal email address (Gmail, Fastmail, etc.) without hosting your own mail server. You add MX records pointing to Cloudflare, and Cloudflare accepts mail on your behalf and forwards it.

It's free, it's simple, and it breaks DMARC.

Why it breaks DMARC

When Cloudflare forwards a message, the original message's envelope sender and the forwarding path change:

Cloudflare receives the mail intended for you@yourdomain.com
Cloudflare re-injects it as a new message to your personal address, sending from Cloudflare's own infrastructure
The original SPF (which authorized the original sender's server) no longer applies
The original DKIM (signed by the original sender) may break during the re-injection process
DMARC alignment fails because the sending infrastructure is now Cloudflare's, not the original sender's

Your DMARC record is doing its job: it's rejecting mail that doesn't come from the authorized sending infrastructure. The problem is that Cloudflare's forwarding breaks the chain of authentication.

What your DMARC reports actually show

When Cloudflare is forwarding mail for your domain, your DMARC reports will show failures from Cloudflare's IP ranges, not failures from attackers, but legitimate forwarding failures.

Specifically:

SPF fails because Cloudflare's IPs aren't in the original sender's SPF record
DKIM may fail if headers were modified during re-injection
Alignment fails because the From domain doesn't match Cloudflare's sending domain

This is the correct behavior for DMARC. Cloudflare is forwarding, not sending legitimately on behalf of your domain.

Option 1: Use a subdomain for Cloudflare forwarding

The cleanest solution is to isolate Cloudflare Email Routing to a subdomain. Don't use your main domain for receiving forwarded mail.

Set up Cloudflare Email Routing on a subdomain like forwarded@yourdomain.com or routes@yourdomain.com. This subdomain has its own SPF, DKIM, and DMARC, separate from your main domain's authentication.

Your main domain stays hardlocked with strict DMARC. The subdomain handles forwarding with a more permissive policy (or p=none).

This works well if you control what addresses receive forwarded mail.

Option 2: Set up DKIM signing for Cloudflare

Some Cloudflare Enterprise customers can set up DKIM signing for forwarded messages. This requires Cloudflare's paid Email Security product and additional DNS configuration.

If you're on the free plan, this isn't available. You'll need to use the subdomain approach.

Option 3: Accept the forwarding limitation and adjust DMARC

If you can't change your forwarding setup, and Cloudflare Email Routing is important to you, the practical option is to set the subdomain's DMARC policy to p=none and accept the failures.

This is not ideal for security, it means you won't catch spoofing that targets your forwarding subdomain. But for a personal domain or a low-stakes forwarding setup, it's workable.

Option 4: Use a different email forwarding service

Some email forwarding services have worked around the DMARC forwarding problem by re-signing messages with the original sender's DKIM or by using SRS (Sender Rewriting Scheme) to preserve SPF. Not all services do this correctly.

If forwarding is critical to your setup, research whether your service handles DMARC compatibility.

How to monitor the situation

Set up DMARC aggregate reports for your domain, they'll show you exactly how many failures are coming from Cloudflare and whether the pattern changes.

A DMARC monitoring tool that lets you filter failures by sending source makes it easy to distinguish Cloudflare forwarding failures from actual spoofing attempts.

How to choose a DMARC monitoring provider

DMARC aggregate reports are XML files. Technically, you can receive and read them yourself, but in practice they are difficult to use without a reporting tool. A good DMARC provider turns those raw reports into something you can actually act on.

When choosing a DMARC provider, look for these features:

1. Source identification

The tool should group sending sources clearly, for example:

Google Workspace
Microsoft 365
Mailchimp
Cloudflare
Unknown sender
Possible spoofing source

This matters because Cloudflare Email Routing failures can look scary in raw reports. A good provider should make it obvious that the failures are coming from Cloudflare forwarding, not from random attackers.

2. Easy filtering by IP, source, and alignment result

You want to be able to filter reports by:

SPF pass or fail
DKIM pass or fail
DMARC pass or fail
Sending IP range
Sending source
Header From domain
Envelope sender domain

For this Cloudflare issue specifically, filtering by source is essential. It lets you separate expected forwarding failures from real unauthorized sending.

3. Clear SPF, DKIM, and DMARC alignment views

A good tool should not only say "DMARC failed." It should show why.

Look for reporting that explains:

Whether SPF passed
Whether SPF aligned
Whether DKIM passed
Whether DKIM aligned
Which domain was used for each check
Which policy was applied

This helps you tell the difference between a broken sending setup and normal forwarding behavior.

4. Unknown sender detection

The provider should highlight senders that are not recognized as legitimate sources for your domain.

This is especially useful if you are moving from p=none toward quarantine or reject. You need to know whether a failing source is something you control, a forwarding artifact, or actual spoofing.

5. Historical trends

Do not choose a provider that only shows isolated reports. You want trends over time.

Useful questions include:

Are Cloudflare failures consistent every day?
Did a new source appear suddenly?
Did failures increase after a DNS change?
Did legitimate mail stop authenticating after a provider migration?

Historical views make it much easier to diagnose whether something is a one-off issue or a real configuration problem.

6. Guidance for enforcement

The provider should help you understand when it is safe to move from:

p=none
to p=quarantine
to p=reject

For your main domain, the goal is usually to reach p=reject once all legitimate senders are aligned. For a forwarding-only subdomain, you may intentionally keep a more relaxed policy.

7. Pricing that fits your domain count and mail volume

Most DMARC tools price based on some mix of:

Number of domains
Number of report messages processed
Number of users or seats
Retention period
Advanced alerting features

For a personal domain, you probably do not need an enterprise product. For a business domain, especially one using multiple SaaS senders, paying for better visibility is usually worth it.

8. Alerting

At minimum, the tool should alert you when:

A new sending source appears
DMARC failures spike
A known sender starts failing
Your domain is being spoofed at volume
A DNS record becomes invalid

This is more useful than manually checking reports every week.

Practical recommendation

If you are using Cloudflare Email Routing on a personal domain, choose a DMARC provider that has good source filtering and clear alignment diagnostics. You do not necessarily need the most expensive tool.

If you are protecting a business domain, choose a provider that supports multiple domains, source classification, alerting, enforcement guidance, and long-term reporting. The goal is not just to collect reports. The goal is to safely get your main domain to p=reject without breaking legitimate mail.

What this means for Cloudflare Email Routing users

For this specific issue, your DMARC provider should make it easy to answer three questions:

Are the failures coming from Cloudflare forwarding?
Are there other unauthorized senders using my domain?
Can my main domain safely stay at p=reject while a forwarding subdomain uses a softer policy?

If the tool cannot answer those questions clearly, it is probably not the right DMARC provider for this setup.

How DMARCFlow handles Cloudflare Email Routing failures

Automatic source identification

DMARCFlow's ESP identification engine matches sending IPs against known infrastructure for over 25 major email platforms using CIDR range matching and reverse DNS patterns. When Cloudflare's forwarding IPs appear in your aggregate reports, they are classified automatically. You see Cloudflare as a labelled source rather than an unidentified IP cluster, the fastest way to confirm your failures are forwarding artifacts rather than spoofing attempts.

Alignment breakdown per source

For every sending source, DMARCFlow shows the SPF result, the SPF alignment status, the DKIM result, and the DKIM alignment status separately. Your main domain's legitimate senders, Google Workspace, Microsoft 365, Mailchimp, or whichever ESPs you use, appear as separate sources with their own alignment rows. You can confirm they are all passing while the Cloudflare forwarding path is the only source of failures.

Policy progression guidance for both domains

DMARCFlow tracks DMARC maturity on a six-level scale from Level 0 (no record) to Level 5 (p=reject, pct=100, strict alignment on both SPF and DKIM). It also runs an eleven-rule recommendation engine that generates prioritised actions based on your current configuration.

For a Cloudflare Email Routing setup, the recommendation engine fires the subdomain policy rules, ensuring your forwarding subdomain has an intentional policy rather than inheriting your main domain's enforcement. If your main domain is ready for p=reject but the forwarding subdomain is holding you back, DMARCFlow separates those assessments so you can advance your main domain without waiting.

Security score with letter grade

Every domain in DMARCFlow gets a security score from 0 to 100 and a letter grade from A to F. The score accounts for your policy level, alignment strictness, percentage enforcement, and authentication pass rate. With a split setup, main domain at p=reject and forwarding subdomain at p=none, you can see both scores side by side and understand exactly what each configuration is doing for your security posture.

Historical trend tracking

DMARCFlow tracks SPF pass rate, DKIM pass rate, and overall DMARC pass rate over time per domain, alongside source IP reliability scoring rated excellent, good, fair, or poor based on consistency. If your Cloudflare forwarding volume is stable and consistent, the trend analysis confirms it - useful evidence if you ever need to justify the subdomain policy to a security team or auditor.

Multi-domain management from one dashboard

DMARCFlow manages both your main domain and forwarding subdomain from a single dashboard. DNS health checks run separately for each domain, covering SPF, DKIM, DMARC, BIMI, and MTA-STS, so you can confirm both domains are correctly configured without switching between tools.

You can start monitoring your domain at dmarcflow.com. Add a DMARC record with your DMARCFlow reporting address and aggregate reports start arriving within 24 hours.

The short version

Cloudflare Email Routing breaks DMARC because forwarding changes the sending path. Your DMARC policy is working correctly. The failures are expected, not alarming.

The fix is structural: move forwarding to a subdomain with its own DMARC policy, keep your main domain at p=reject, and use a monitoring tool that separates forwarding failures from actual spoofing attempts.

Once that structure is in place, your DMARC reports become useful rather than noisy.