DMARC on Cloudflare, in Practice: Step by Step, With the Failure Modes

Two different jobs arrive under the same search. One is adding a DMARC TXT record to a zone that Cloudflare happens to host, which is ordinary DNS work. The other is Cloudflare DMARC Management, a product that receives and parses your aggregate reports so you do not have to read XML. They are unrelated, and the second one carries constraints worth knowing before you plan an architecture around it.

Adding the record by hand

A DMARC record is a TXT record at _dmarc in front of the domain it governs, and Cloudflare's DNS editor treats it like any other TXT record. For acme.com the name is _dmarc, and Cloudflare appends the zone, so entering the full _dmarc.acme.com produces _dmarc.acme.com.acme.com and a record nothing will find. Read the record back after saving rather than trusting the form.

A first record, for a domain that has not been monitored before:

_dmarc   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@acme.com"

One Cloudflare-specific thing helps here and one hurts. The helpful part is that Cloudflare's DNS proxying does not apply to TXT records, so nothing about the orange cloud affects DMARC. The unhelpful part is that a domain on Cloudflare is frequently a domain whose registrar is somewhere else, so before editing anything, confirm the nameservers actually point at Cloudflare. Editing the registrar's zone on a Cloudflare-resolved domain is the most common way to publish a record that does not exist.

What goes in the record, tag by tag, including the tags the 2026 specification added and retired, is covered in the DMARC record.

What DMARC Management actually is

Cloudflare's product does the report-processing job: it receives aggregate reports on your behalf and shows you which sources are sending as you and whether they pass. Cloudflare's documentation describes it as helping you "track every source that is sending emails from your domain and review DMARC reports for each source", and states it is "available to all Cloudflare customers with Cloudflare DNS".

The mechanism is the part to understand, because it changes your DNS record. Cloudflare's documentation says that when you enable it, "if a DMARC record is found in your zone, Cloudflare will add another rua entry to it using a Cloudflare email address so that Cloudflare can receive and process DMARC reports on your behalf". Your existing reporting address is not replaced. Cloudflare's is added alongside it, which is the right behaviour and is also a write to a record you may consider yours.

Publishing the recordOrdinary DNS work

• A TXT record at _dmarc in the zone
• Works on any domain Cloudflare resolves
• Subdomains and apex both fine
• You choose where reports go

DMARC ManagementThe report-processing product

• Requires Cloudflare DNS
• Apex domains only
• Adds its own rua entry to your record
• Reports parsed for you in the dashboard

The two constraints that decide whether you can use it

Apex domains only. Cloudflare's documentation is unambiguous that DMARC Management works only with "apex domains (for example, example.com, not blog.example.com) and not domains in subdomain setups". If your architecture puts outbound on subdomains of a parent, this product does not cover those names, and that is a design decision to make before you build rather than after.

It will not touch some SPF records. The same documentation carries a warning: "DMARC Management does not support modifications to SPF records when a CNAME record in your zone points to an external domain. Any changes to the SPF record could invalidate your DMARC policy, as Cloudflare cannot update the associated external DNS records." Cloudflare's own recommendation in that case is to manage SPF updates directly. Worth reading before assuming the product will keep your whole authentication set current.

There is a third consideration that is not a constraint so much as a caveat. The feature carries a beta label in Cloudflare's own documentation navigation, which is a reason to keep your own rua mailbox listed alongside Cloudflare's rather than relying on a single destination.

The rest of the authentication set, in the same panel

Since you are in the zone anyway, the other two authentication records live beside the DMARC one and the same Cloudflare-specific notes apply to both.

SPF is a TXT record on the domain itself rather than on a subdomain of it, and a domain may publish only one. The trap on Cloudflare is the same as on any panel: a vendor's onboarding says to add an SPF record, one already exists, and adding a second makes the domain's SPF evaluation ambiguous rather than adding a sender. Merge the new include: into the existing record instead, in front of the all mechanism, since anything after it is ignored. The ten-lookup limit is the constraint that eventually bites.

DKIM is a TXT or CNAME record at selector._domainkey, and which of the two you get is chosen by the platform that signs your mail rather than by you. If a platform hands you a CNAME, publish it as a CNAME: Cloudflare will accept a TXT record containing the same string and the lookup will then return the wrong kind of answer. Long DKIM keys are the other Cloudflare-adjacent detail, since a 2048-bit key exceeds what fits in a single TXT string and has to be published as concatenated strings.

Neither record is affected by Cloudflare's proxying, which applies to address records rather than to TXT or to the CNAMEs used for DKIM delegation.

How it compares to the alternatives

The case for it is that you are already paying nothing extra and the setup is a few clicks in a dashboard your team already uses. For a company with one apex domain and a handful of senders, that is a genuinely good answer and it removes a purchasing decision.

The case against is shape. An outbound programme running many sending domains wants per-domain history, alerting when a new source appears, and coverage of names that may not all be apex domains. Products built specifically for that job go further, and we compare the category in seven DMARC tools on what they actually do.

The other thing to weigh is where you want the concentration. Putting DNS, reporting and, on many setups, the CDN in front of your site with one vendor is convenient and it is also a single account whose loss takes several things at once. That is a judgement rather than a rule.

Before turning on DMARC Management

• ✓Yes: The domains you care about are apex domains, not subdomains
• ✓Yes: Cloudflare is the authoritative DNS for those zones
• ✓Yes: Your own rua mailbox stays listed alongside Cloudflare's
• ✓Yes: You know whether your SPF record is affected by the CNAME limitation
• ✕No: You expected it to manage records on subdomains too

Verifying, from outside the dashboard

A record that appears in the Cloudflare interface is not yet a record the internet can see, and the gap between the two is where most of the confusion sits.

Query the hostname from somewhere other than Cloudflare and read what comes back. _dmarc.yourdomain.com should return exactly one TXT record beginning v=DMARC1. Two records at that name is the state to look for hardest, because it can leave the domain with no usable policy at all, and it happens when a product adds a record while a person adds another.

Then wait for the evidence rather than the dashboard. Reports arrive daily from receivers that have seen your mail, so a domain sending nothing produces nothing, and a domain that just went live takes a day or so to show anything. Reading what those reports contain is its own skill, covered in how to read a DMARC report without a parser.

What this looks like on an outbound domain portfolio

Teams doing B2B outbound usually own many sending domains, and the natural instinct is to put them all in one Cloudflare account for the same reason they are all at one registrar: it is one place to look.

That works, with two caveats. Sending domains are usually apex domains in their own right rather than subdomains of a parent, which means the apex-only limit is not the blocker here that it is for a company sending from mail.acme.com. And the reporting question does not go away, because reports for thirty domains delivered into one dashboard still need somebody to read them, on a schedule, and to notice the domain that stopped reporting entirely.

Getting the reports to arrive at all has its own failure modes, particularly the cross-domain authorisation record needed when the reporting mailbox is on a different domain from the one being monitored, and DMARC aggregate reports covers those in full.

We authenticate every sending domain before it carries a message and run one message per campaign, so a domain that fails authentication does not get a second attempt with the same person. Monitoring is there to catch drift after launch rather than to find problems at launch, which is also why we carry more sending infrastructure than a campaign consumes and replace a problem domain rather than repair it in flight.

If you would rather not run the DNS and reporting layer across a portfolio, we operate the sending infrastructure as part of the engagement.

The short version

Publishing a DMARC record on Cloudflare is ordinary DNS: a TXT record at _dmarc, with the zone appended for you, so read it back after saving. Cloudflare DMARC Management is a separate product, available to any customer using Cloudflare DNS, that receives and parses your reports and adds its own address to your record's rua tag to do so. It works on apex domains only, it will not modify SPF records behind an external CNAME, and it carries a beta label, so keep your own reporting mailbox listed alongside it.

Vendor behaviour verified as of August 2026 against Cloudflare's published DMARC Management documentation. Verify current product limits with the vendor before relying on them.