DKIM, SPF, and DMARC for Cloudflare Email Routing
Cloudflare Email Routing hides a lot of plumbing — but it does not hide the deliverability contract. SPF, DKIM, and DMARC are still records you publish, alignment rules you satisfy, and reports you read. This is the field-tested walkthrough: what Cloudflare sets up for you, what you still own, and the failure modes that show up only in production.
What the three records actually do
SPF (Sender Policy Framework) is the list of hosts allowed to send mail for your domain. Receiving servers check the HELO of the sending server against the SPF record and either pass, softfail, or fail the message. It is one DNS lookup, one short answer.
DKIM (DomainKeys Identified Mail) is a cryptographic signature in the message header. The receiving server fetches the public key from DNS, verifies the signature over the canonicalized body and selected headers, and decides whether the message was tampered with in transit. DKIM is what survives relays rewriting the body.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy record that ties SPF and DKIM together. It says what to do with messages that fail either check, and where to send aggregate reports about the failures. DMARC is the part most teams skip — and the part most inbox providers use to decide your reputation.
What Cloudflare Email Routing handles for you
Once you enable Email Routing on a zone, Cloudflare publishes a DKIM record for the zone under a cf-...._domainkey hostname and starts signing outbound messages from your domain with that key. Rotation is automatic — you do not have to manage a private key, and you do not have to update the DNS record when the key changes.
Email Routing also writes the MX records that point at Cloudflare’s mail exchangers, and rewrites any third-party MX out of the way. The platform is doing exactly one job — being the front door for inbound mail and the signing identity for outbound mail — and the DKIM contract is the most important piece.
SPF: the part you still publish
Email Routing does not publish an SPF record for you, because SPF lives at the zone apex and Cloudflare will not second-guess whatever you have there. For a Cloudflare-only setup, the record is short:
@ IN TXT "v=spf1 include:_spf.mx.cloudflare.net -all"
The -all is the important part: it is a hard fail, not a soft fail. Inbox providers treat soft fails as a hint and hard fails as a contract. If you want to keep sending from anywhere else, list it in the same record — include:_spf.google.com for Workspace, ip4:192.0.2.10 for a static IP. The ten-lookup DNS limit is real; if you have more than two includes, audit the chain.
DKIM: usually automatic
After Email Routing is active, Cloudflare publishes the DKIM public key as a TXT record on a selector subdomain. You can find the exact selector in the dashboard under Email → Email Routing → DKIM. It looks something like cf2024-1._domainkey.yourdomain.com and resolves to a long base64 string.
You do not need to publish a second DKIM record for Cloudflare to sign mail correctly. If you also send mail through a third-party (Workspace, Mailgun, Postmark), publish a second DKIM record on a different selector so receiving servers can verify both. The DKIM signature in the header carries the selector, so the receiver knows which key to look up.
DMARC: the policy record most teams skip
DMARC is the policy record that says what to do when a message fails SPF or DKIM alignment. The minimum viable record for a domain that has been on Cloudflare for a while is:
_dmarc IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100"
Start with p=none if you have not been watching your reports yet, then move to p=quarantine after a fortnight, then p=reject once you are confident no legitimate mail is failing. The rua address is where receiving servers send the XML aggregate reports — set up a mailbox or a forwarding rule that catches them before they bounce.
The two failure modes that show up most often are misalignment (the SPF domain or DKIM d= does not match the visible From domain) and reports ignored (a bouncing rua mailbox causes receiving servers to stop sending them). Both are operator-level issues; the fix is the same: read the reports, fix the alignment, keep the mailbox alive.
Monitoring and reporting
DMARC aggregate reports arrive daily as compressed XML files. Parsing them by hand is unpleasant; most teams use a free or paid parser (Postmark has one, Google has dig and a Postfix parser, dmarcian is the canonical SaaS). The thing to watch for is a sudden shift in pass rate — if Cloudflare’s DKIM signature suddenly fails alignment, it is almost always because someone rotated a record without updating the matching selector.
For real-time signal, set up a postmaster account at Gmail, Outlook, and Yahoo. Each one has its own reputation dashboard; the data is coarser than DMARC reports but it catches problems a day or two earlier. Treat the dashboard red dots as paging events, not as weekly status updates.
Where to read more
The sending mail from your Cloudflare domain post covers the outbound side, and the Workers-native routing tour walks through the receive-side runtime. For the broader architecture, see Flowmails for indie developers and the pricing page for the per-domain and per-volume breakdown.
