All packsTransactional Email Deliverability CoreSolve
dmarc effective record subdomain vs root domain resolution
Which DMARC record actually governs your mail subdomain?
Mailbox providers check the mail subdomain's own DMARC record first and only fall back to the root domain's if none exists -- getting this resolution order wrong misreads your own compliance status.
What goes wrong
A domain sending mail from a dedicated subdomain (mail.yourdomain.com) has two DMARC records that could apply: one at _dmarc.mail.yourdomain.com and one at _dmarc.yourdomain.com. A DNS checker that only looks at the root record, or only at the subdomain record, can report the wrong effective policy -- either falsely flagging a properly staged subdomain rollout as unprotected, or missing that the root record is silently governing mail it was never meant to.
Why agents get it wrong
DMARC's actual resolution order -- check the exact subdomain first, walk up to the organizational domain only if nothing exists there -- is specified in the DMARC RFC, not something obvious from just knowing DMARC records exist. A checker that queries only one of the two levels will look like it's working, right up until the specific case (a record at one level but not the other) that the simplified version doesn't handle.
What Transactional Email Deliverability Core pre-decides
The pack's checkRecords() function implements the same resolution order receiving mail servers actually use: the effective DMARC record is _dmarc.mail.yourdomain.com if present, otherwise it falls back to _dmarc.yourdomain.com. This is exactly what lets a buyer with other root-domain senders escalate DMARC enforcement only on the mail subdomain, and have the DNS checker correctly report that as the record actually in force.
Source: ARCHITECTURE.md 'DNS + DMARC staging'