A CNAME on the _dmarc record: trap or legitimate practice?

The traps: exclusivity, vanished target, stacked caches, stubborn interfaces

A CNAME coexists with nothing. The DNS RFCs are categorical: a name carrying an alias may carry no other record. Adding a second TXT at _dmarc — a verification token requested by a third-party tool, a temporary test record — is therefore impossible. Good interfaces refuse the creation; bad ones accept it and produce a zone whose behavior depends on which server happens to answer. The day a vendor requires "a TXT at _dmarc" to validate anything at all, the alias forces the detour through the target.

The target that vanishes. This is the most insidious scenario. A cancelled collector subscription, a central zone dropped during a migration, a typo in the target: _dmarc.example.com now resolves to NXDOMAIN, and the policy evaporates — with no alert of any kind, because nothing visibly breaks. Legitimate mail keeps flowing; there is simply no policy left for receivers to apply, spoofing becomes possible again, and the bulk-sender requirements of the major providers are no longer met. One nuance from DMARCbis: for a subdomain, the Tree Walk climbs the hierarchy and lands on the organizational domain's policy — a partial safety net. For the organizational domain itself, nothing catches the fall. The visible symptom often arrives weeks later, when someone notices that the reports have stopped arriving.

TTLs stack up. A delegated chain keeps two records alive, hence two TTLs and two independent caches. A policy change made at the target propagates according to the target's TTL, but the alias itself stays cached at resolvers: the real propagation delay becomes harder to predict than with a direct TXT, and a very long TTL on either link can slow down a hardening step — or, more troubling, an emergency rollback.

Stubborn interfaces. The last obstacle is prosaic: some consumer-grade DNS managers refuse a CNAME on a name starting with an underscore, or validate _dmarc as TXT only. The workaround goes through the raw zone editor or the API where they exist — and where they do not, the construct is simply unavailable at that provider.

A policy in someone else's hands

The previous traps were technical; this one is about governance, and it weighs more. An alias toward a name controlled by a third party amounts to handing that third party the power to write the domain's DMARC policy. Whatever the target publishes, receivers apply: a p=reject quietly relaxed to p=none, a redirected rua address, a modified sp= tag — all of it becomes possible without a single change appearing in the domain owner's zone. The provider's zone also becomes an attack surface: compromising it means compromising the policy of every customer behind it.

The reading grid is simple. An alias toward a zone owned by the same organization (the group's central zone) pools without surrendering sovereignty: control stays in-house, only the location changes. An alias toward a third party is a genuine delegation decision and deserves the same treatment as any outsourcing: a contractual clause on reversibility, independent monitoring of what the target actually publishes, and a tested exit procedure — because on departure day, taking back control boils down to replacing the alias with a direct TXT, provided the right content to publish is known.

The DKIM parallel: routine for selectors, debated for _dmarc

The irony of the debate is that the very same construct is practiced daily without anyone batting an eye — on the DKIM side. Wiring up an email router almost always involves selector CNAMEs: s1._domainkey.example.com pointing at a name hosted by SendGrid, Mailjet, Brevo or Amazon SES, which publishes the public key and rotates it without any customer intervention. That delegated rotation is even a security argument: keys change more often than if every customer had to edit its own zone.

Why does the same technique pass without debate there and raise eyebrows here? Because the scopes are not comparable. A DKIM selector is technical material, tied to one sending flow, individually revocable, and one among several: its compromise or its disappearance degrades one flow, not the domain. The _dmarc record, by contrast, is unique and governs the treatment of all the domain's mail — and, through sp and the Tree Walk, that of its subdomains. Delegating a selector means handing over one apartment key; delegating _dmarc means handing over the building's master key. Same technique, different stakes — hence different trust requirements.

When a direct TXT remains the better choice

The practical conclusion draws itself. The direct TXT remains the default in most situations: one or two domains to manage, a stable policy that changes three times in a domain's lifetime, a team that wants its configuration readable in its own zone without following a chain. The alias would bring no real saving there and would add one more moving part.

The CNAME earns its place in two deliberate cases: the large fleet driven from a central zone of the same organization — the operational gain is massive and sovereignty stays intact — and the conscious delegation to a provider, documented as such, with monitoring and an exit door. Between the two, the rule fits in one sentence: the alias is a tool of scale and delegation, not a default setting; at small scale and with nothing to delegate, it has only drawbacks.

Verifying a delegated chain with dig

The verification fits in two commands. The first follows the chain the way a receiver would:

$ dig +short _dmarc.example.com TXT
dmarc.group-example.com.
"v=DMARC1; p=reject; rua=mailto:reports@group-example.com"

The first line shows the alias, the second the TXT read at the end: that value is what receivers will apply. The second command isolates each link: dig +short _dmarc.example.com CNAME confirms the exact target, then dig +short dmarc.group-example.com TXT queries the target directly. The checkpoints: a single-hop chain, a target answering with exactly one TXT starting with v=DMARC1, no stray record at the same name, and reasonable TTLs on both sides. An NXDOMAIN on any link means an evaporated policy — a case for immediate correction, not leisurely investigation. And because the chain can break on the target's side without any change in the domain's own zone, automated periodic verification beats a one-off check at deployment time.

In summary

A _dmarc in CNAME form is neither heresy nor a harmless setting. DNS fully allows it: the alias delegates the entire name, resolution follows the chain, and the TXT read at the end is authoritative for every receiver. Two uses justify it — delegation to a report collector, and fleet management from a central zone. Against that, four documented traps: CNAME exclusivity, which forbids any other record at the same name; a target that can vanish and take the policy with it without an alert; TTLs that stack up; and DNS interfaces that reject the construct. The deciding factor remains governance: an alias toward the organization's own central zone pools without giving anything up; an alias toward a third party delegates the power to write the policy and deserves to be treated as outsourcing. At small scale, the direct TXT keeps every one of its advantages.

To settle the question for a specific domain, the free DMARC analysis follows CNAME chains exactly as a receiving server would and shows the policy actually read at the end — alias included, link by link. And when an entire fleet rests on this construct, opening an account keeps every link under continuous watch: a target that evaporates then gets detected within hours, not when the first forged message carries the domain's name.