DMARC and Cloudflare Email Routing

Cloudflare Email Routing is not a mailbox provider like the others: it forwards mail received on your domain to an existing inbox. It is not for sending. That distinction changes the DMARC setup entirely — and simplifies it a great deal.

Your domain sends nothing. Say so.

If all your outgoing mail leaves from somewhere else — Gmail, iCloud, a platform — and Cloudflare only routes what comes in, then no server is legitimate for sending under that domain through Email Routing. This is the simplest and safest case there is:

v=spf1 -all
v=DMARC1; p=reject; rua=mailto:your-address@yourdomain.com

A domain that does not send can go straight to reject with no observation period: there is nothing to break. It is in fact the one case where skipping the steps is the right call. One caveat: if you also send from this domain, that configuration blocks your own mail — go back to the normal progression.

What Cloudflare does for you

Forwarding breaks SPF by construction: the message reaches the final recipient from Cloudflare’s servers, not the original sender’s. Two mechanisms avoid the breakage:

• Envelope rewriting (Sender Rewriting Scheme): Cloudflare replaces the envelope address with one of its own, which makes SPF pass on arrival.
• ARC: the authentication results observed on receipt are sealed and passed to the final provider, which can take them into account instead of rejecting legitimate mail.

Since 3 July 2025, Cloudflare requires incoming mail to pass SPF or DKIM to be forwarded. A poorly authenticated sender will therefore not reach you — that is the expected behaviour, not a defect.

Common mistakes

• Assuming Email Routing lets you send. It does not. Sending goes through another service, and that service is what must appear in your SPF and sign with DKIM.
• Publishing a permissive SPF « just in case » on a receive-only domain. That is an open door with nothing in return.
• Non-delivery reports are not forwarded. A message that bounces at the final destination does not make its way back to the original sender: watch your reports so you do not find out too late.
• Forgetting subdomains. Without sp= they inherit the parent policy — which here is usually exactly what you want.

Once it is in place, Clarsend reads your reports and shows you what passes, what fails, and who is sending without your knowledge.