A receiver looks in two places for a policy, and stops at the first answer. Knowing which two tells you exactly which record governs any message, and why a record on an intermediate subdomain is often ignored entirely.
The algorithm
From: user@mail.eu.example.com 1. Query _dmarc.mail.eu.example.com found? -> use it. Done. 2. Otherwise, derive the organisational domain: example.com Query _dmarc.example.com found? -> use its sp (or p, if sp is absent). Done. 3. Otherwise: no DMARC policy.
Two queries. Never three. _dmarc.eu.example.com is not consulted at any point, even though it sits between the two names that are — and a policy published there governs only mail whose From domain is exactly eu.example.com.
What follows
| Situation | Record applied |
|---|---|
From example.com, record at example.com | Its p |
From mail.example.com, no record there | The apex sp, or p if sp is absent |
From mail.example.com, record published there | That record’s p — the apex is not consulted at all |
From a.b.example.com, record at b.example.com | The apex sp. The intermediate record is never queried. |
| From a subdomain that does not exist | The apex np, falling back to sp then p |
Publishing on a subdomain
A record on a sending subdomain overrides sp completely for that name, which is how you exempt one stream from an estate-wide policy — or accidentally weaken it. A forgotten p=none on mail.example.com survives the apex moving to reject, and nothing about the apex record reveals it.
Audit downward, not just at the apex
Checking _dmarc.example.com tells you the policy for the apex and the default for subdomains. It tells you nothing about subdomains that publish their own. Enumerate the sending subdomains you know of and query each — an override is invisible from above.
RFC 7489 §6.6.3 defines the two-step lookup. The derivation of the organisational domain in step 2 is the part that is not DNS at all, and it is the subject of the next lesson.