A DMARC policy of p=reject is supposed to protect a domain from spoofing. Under a specific combination of Cloudflare DNS, a CNAME-based DMARC delegation, and an ESP onboarding through Entri, that protection quietly disappears — and nothing in the dashboard tells you it happened.
The pattern looks like this. A domain owner sets up DMARC properly. They use a managed reporting platform that issues a CNAME record at _dmarc, pointing to a vendor-hosted DMARC policy of p=reject. Months later, a marketing team connects a new ESP. The ESP runs domain authentication through Entri, which programmatically writes the required DNS records to Cloudflare. Among those records: a fresh DMARC TXT record at _dmarc, usually v=DMARC1; p=none;.
At this point, the domain has two records at the same name: the existing CNAME and a new TXT. Per RFC 1912, that combination is invalid. A CNAME is supposed to be the only record type at a hostname. Most authoritative DNS providers reject the second record outright. Cloudflare doesn't. It accepts both, serves both, and the domain ends up with conflicting DMARC instructions at the same label.
What happens next is the part most domain owners don't realize. Per RFC 7489, when a DMARC receiver finds multiple records at _dmarc, it doesn't pick one — it ignores DMARC for that domain entirely. The p=reject policy stops being enforced. The domain is now spoofable, even though the dashboards on both the reporting platform and the ESP say everything is fine.
This is one of the cleaner examples of a class of failures we see constantly in audits: DNS that looks correct in every individual control panel, but is broken in the resolver.
Why the Conflict Exists in the First Place
The technical reason is a small but consequential gap between two RFCs and Cloudflare's behavior.
RFC 1912 section 2.4 is unambiguous: a CNAME record cannot coexist with any other record type at the same hostname. The reason is that a CNAME is a redirect — when a resolver asks for a record at the labeled hostname, the CNAME tells it to look elsewhere. If a TXT record also exists at that hostname, the resolver has no defined way to handle the conflict. Authoritative DNS implementations are expected to refuse the second record.
Most providers do. PowerDNS, BIND, Route 53, NS1, Google Cloud DNS — try to add a TXT to a hostname that already has a CNAME and you get an error. Cloudflare doesn't enforce this. Both records get accepted, both get served, and the conflict is invisible until something tries to resolve the name and gets back two answers it can't reconcile.
The DMARC side of the failure is governed by RFC 7489 section 6.6.3. When a receiver looks up the DMARC record for a domain, it issues a TXT query at _dmarc.<domain>. If the answer contains multiple TXT records starting with v=DMARC1, the receiver is required to discard them all and apply no DMARC policy. The reasoning is correct: the receiver has no way to know which record represents the domain owner's actual intent, so it can't safely enforce either one.
In the Cloudflare-plus-Entri scenario, the resolver gets back the TXT served directly at _dmarc and the TXT served via the CNAME target — two distinct DMARC records, both starting with v=DMARC1. RFC 7489 takes over and DMARC is bypassed entirely.
The root domain still has SPF and DKIM. Spoofing attempts that fail both will still be filtered by spam heuristics. But the strict pass/fail-then-reject decision that DMARC gives you — the thing organizations move to p=reject to obtain — is gone.
The ESP Onboarding Path That Triggers This
We have not seen this happen with manual DMARC configuration. It almost always traces back to an automated onboarding flow.
Entri is the most common vector. It's a service used by dozens of ESPs and SaaS platforms to let end users authenticate their domains in a few clicks. The user logs into their DNS provider through Entri's interface, and Entri writes the required SPF, DKIM, and (in some configurations) DMARC records on their behalf. It's a good user-experience improvement for platforms that need to onboard non-technical buyers. The problem is that the auto-deployment logic doesn't always check what's already there.
Specifically: when Entri pushes a DMARC record as part of an ESP setup, we routinely find it doesn't first query for an existing _dmarc record. It assumes none exists, writes a TXT, and lets the DNS provider handle whatever happens next. On every DNS provider that enforces RFC 1912, the write fails — the user sees an error and the support flow takes over. On Cloudflare, the write succeeds silently.
We see this consistently across audits. Across one recurring scenario type — a SaaS platform sending on behalf of hundreds of end-user domains — we find duplicate DMARC records on a meaningful subset of the active sending base. In one platform-level audit, our review of DNS configurations identified multiple domains with two DMARC records in place, and others with typos or missing records. Each one represented a tenant who thought their email was authenticated and protected, and was wrong on both counts.
The pattern is not unique to Entri or any one ESP. It surfaces wherever an automated DNS deployment writes a DMARC record without checking for an existing one. But Entri-on-Cloudflare is the combination we see most often, because the volume of platforms that have integrated Entri is large and the share of domains on Cloudflare DNS is significant.
How to Detect the Conflict
The cleanest way to detect the conflict is dig from a terminal. The dashboards lie to you in this scenario, because each individual control panel only shows the records it manages.
Start by querying TXT records at _dmarc:
dig +short TXT _dmarc.example.comIf you see two answers — one that looks like a DMARC policy (v=DMARC1; p=reject; rua=...) and another that also looks like a DMARC policy (v=DMARC1; p=none;) — you have the conflict. Receivers see exactly what you're seeing, and they're discarding both.
Next, query for a CNAME at the same name:
dig +short CNAME _dmarc.example.com
If this returns a value — typically pointing to a DMARC reporting vendor like *.dmarc.cc, *.dmarcian.com, or similar — and the previous TXT query also returned records, the CNAME and TXT are coexisting. That coexistence is what RFC 1912 prohibits and what Cloudflare permits.
For a more complete picture, run a DMARC validator that fetches the records from authoritative DNS rather than reading the Cloudflare dashboard. Tools like MXToolbox, dmarcian's analyzer, or any of the major DMARC monitoring platforms will report "multiple DMARC records found" or similar. The error language varies, but the underlying detection is the same: more than one TXT starting with v=DMARC1 at the lookup label.
The dashboard-only check is unreliable. The Cloudflare DNS dashboard shows both records as valid because Cloudflare doesn't flag the conflict. The reporting platform that owns the CNAME shows its policy as published. The ESP that pushed the TXT through Entri shows the domain as authenticated. Three vendors, three green checkmarks, and a domain that DMARC receivers are ignoring.
How to Fix It
The fix itself is straightforward; the harder part is making sure it doesn't recur.
Decide which DMARC source is authoritative. If you've delegated DMARC to a reporting platform via CNAME and you want the p=reject policy on that vendor's hosted record to be enforced, the CNAME is authoritative and the rogue TXT must be removed. If you'd rather manage DMARC directly via TXT, the CNAME comes out and you publish your own TXT record. The domain owner — not the ESP, not Entri — should make this call.
Remove the conflicting record. In Cloudflare's DNS dashboard, find both entries at _dmarc and delete whichever you've decided isn't authoritative. Verify with dig afterward that only one record type is being returned.
Audit other domains in the same Cloudflare account. If one domain hit this scenario, it's worth checking every other domain on the account that has connected an ESP through Entri or a similar auto-deployment tool. The same conflict pattern may exist on multiple zones. We typically find this clusters: an organization that uses a particular ESP across a portfolio of domains will see the same misconfiguration repeated on every one of them.
Block future overwrites at the platform layer. If you control the ESP integration on the sending side, configure the onboarding flow to skip DMARC deployment when an existing _dmarc record is detected. This is the fix that should exist upstream — every automated DNS deployment should check for conflicting records before writing — but in the absence of that fix, defensive configuration on whichever side you control is the next-best mitigation.
Set up DMARC reporting that monitors the policy itself, not just the message-level results. Most DMARC platforms alert when aggregate report volume drops to zero (an indication that DMARC is no longer being applied at all) or when the published policy changes unexpectedly. If you're not getting reports from receivers you'd normally expect to send them, the absence is the signal. We routinely find DMARC outages that lasted for weeks because no one noticed the reports had stopped arriving.
Why This Is a Symptom, Not the Whole Disease
The Cloudflare-Entri conflict is a clean technical case, but it's part of a much broader pattern that we see in nearly every DNS audit: email authentication that was correctly configured at one point in time and silently broke later.
The triggers vary. A migration to a new website provider that didn't preserve the old DKIM records. A CRM swap where someone forgot to re-authenticate the SendGrid subuser on the new infrastructure. A new ESP added through an Entri-style auto-deploy. A team member who didn't know about the existing DMARC record adding a second one through a different vendor's wizard. A DNS provider change that dropped the SPF record because it was on the wrong zone.
The common thread is that authentication is configured by one person at one moment and is then expected to keep working forever, with no monitoring and no review. It almost never does. DKIM signatures break. SPF includes accumulate cruft. DMARC records get duplicated. We've seen domains with two SPF records (which is invalid), DMARC records with typos, DKIM records published on www.example.com instead of the root, and DMARC monitoring reports flowing to addresses no one has read in years.
The fix is the same in every case: an inventory of every sending source, a verification that every authentication record is valid and aligned, and ongoing monitoring that catches drift. The Cloudflare scenario gets a blog post because the failure mode is sharp and identifiable. Most of the failures we find don't have a clean RFC violation to point at — they're just incremental decay in what was once a working configuration.
What to Take From This
The narrow takeaway: if your domain is on Cloudflare DNS, and you have either a CNAME-based DMARC delegation or any ESP that onboards through Entri, run dig +short TXT _dmarc.<your-domain> right now. If you get two records back, your DMARC policy is being ignored by receivers. The fix is fifteen seconds in the Cloudflare dashboard.
The broader takeaway: DMARC enforcement is a state, not a setting. Publishing a p=reject record once doesn't mean you're enforcing reject forever. Every change to your DNS, every new sending source, every ESP onboarding, every vendor migration is a potential break in the chain. The organizations that maintain durable DMARC enforcement aren't the ones that publish the strictest policies — they're the ones that monitor whether the policies are still being applied a month, six months, two years after publication.
For any organization sending email at meaningful volume, the cost of getting this wrong — silently undoing a p=reject policy and not knowing it — is asymmetric. The upside of having DMARC published is protection against domain spoofing. The downside of having DMARC silently bypassed is the same exposure as never having configured it in the first place, plus the false confidence that you have.
If you're not sure whether your DMARC policy is actually being enforced, SH Consulting audits DNS and email authentication across SendGrid, Microsoft 365, Google Workspace, and any ESP your team has connected — including the ones you've forgotten about. Book a 30-minute call to walk through what we'd check on your domains.
