Email authentication has three layers — SPF, DKIM, and DMARC — and a common mistake made by those using Cloudflare Email Routing is assuming that activating the service resolves all three at once. Cloudflare configures SPF for receipt automatically, handles DKIM via ARC on forwarded emails, and does not configure DMARC for you. If you use a separate shipping provider, the SPF and DKIM for that provider need to be added manually. Confusing these roles leads to rejected email—sometimes your own.
What SPF does and what Cloudflare adds
SPF (Sender Policy Framework) is a TXT record in your DNS zone that lists the servers authorized to send email through your domain. When a receiving server accepts an email claiming to be from seudominio.com, it queries seudominio.com's SPF to check if the sending IP is on the list.
When you enable Email Routing, Cloudflare automatically adds a include:_spf.mx.cloudflare.net to your domain's SPF. This authorizes Cloudflare's servers to receive email for your domain — which makes sense, because they are the servers that will accept incoming messages before forwarding them.
The point that requires attention: if you also use an outbound shipping provider — Resend, SendGrid, Amazon SES, Mailgun — this provider has its own servers that need to appear in your SPF. The final SPF record must include both Cloudflare and the shipping provider. An example with Resend:
v=spf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all
SPF has a limit of 10 DNS lookups per evaluation. Each include: counts as a lookup and can trigger more recursive lookups. With many providers combined, it is possible to exceed this limit — which makes SPF fail for all senders, not just some. Tools like MXToolbox and dmarcian have validators that count lookups and alert you before it becomes a problem.
DKIM when receiving and sending
DKIM (DomainKeys Identified Mail) works via asymmetric encryption: the sending server signs the email with a private key, and the receiving server verifies the signature against the public key published as a TXT record in the sending domain's DNS.
For emails received and forwarded via Email Routing, Cloudflare uses ARC (Authenticated Received Chain). ARC is a set of headers that records the email authentication chain as it passes through intermediaries — in this case, the Cloudflare server. When Cloudflare forwards an email, it adds ARC headers that tell the end receiving server: "I received this email, the original DKIM signature was valid at the time it arrived here, and I am resigning it to preserve that information." Cloudflare re-signs with its own DKIM key when forwarding.
For emails sent by your outbound provider, DKIM works differently. Resend, SES, or any other sending provider will ask you to add one or more TXT records to your DNS zone with their DKIM public key. You add these records to the Cloudflare dashboard, and the provider uses the corresponding private key to sign emails going out through your domain. Cloudflare doesn't generate or manage this key — you just host the TXT record that the provider created.
DMARC: what to configure and in what order
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits in a TXT record in _dmarc.seudominio.com and defines what receiving servers should do when an email fails SPF and DKIM simultaneously. It also defines where to send authentication reports.
Cloudflare doesn't configure DMARC for you. You create the record manually. A reasonable initial record:
v=DMARC1; p=none; rua=mailto:dmarc@seudominio.com; ruf=mailto:dmarc@seudominio.com; pct=100
p=none means “monitor, don’t reject”. Reports arrive at the addresses defined in rua (daily aggregate reports) and ruf (failure forensic reports). These reports in XML format show which IPs are sending email through your domain and what the SPF/DKIM result is for each one.
The correct sequence is this: activate p=none first, wait for at least a week of reports, verify that all legitimate senders — the sending provider, the form servers, the marketing tools — appear as aligned in SPF or DKIM. Only after confirming this alignment do you move to p=quarantine (suspicious emails go to spam) and eventually p=reject (suspicious emails are rejected upon reception).
Activating p=reject before adding the sending provider's SPF and DKIM records is the most common error. The result: your own emails start to be rejected by destination servers because they go out through Resend or SES but SPF doesn't include those servers yet, or the DKIM record hasn't been added yet. DMARC fails, and with p=reject the email is rejected — silently from the sender's perspective.
What to check before changing DMARC policy
Before moving from p=none to any more restrictive policy, it is worth checking three things in the aggregate reports: that Cloudflare appears as SPF aligned for incoming emails that you forward to your own accounts, that the sending provider appears as DKIM aligned for outgoing emails, and that there are no unexpected IPs sending email through your domain — which would indicate a configuration of another service that you did not map or misuse.
Tools like dmarcian, Postmark (which has a free DMARC parser), and MXToolbox make XML reports easy to read. It's worth the time invested. A domain with properly configured DMARC has less chance of having forged emails accepted by recipients — and less chance of having legitimate emails rejected due to configuration failure.
Also read
- The limitations of Cloudflare Email Routing that the tutorial doesn't mention
- Cloudflare Email Routing: receive email on your domain — and what's not included
- Cloudflare KV: What does globally distributed mean when you need to write
- Cloudflare Workers vs Pages: the difference that matters before you choose
- Email Routing vs Improvmx vs Forward Email: honest comparison
- Email Routing + Workers: process emails programmatically on edge