A DMARC record on your main domain covers its subdomains unless they publish their own. The sp tag sets a different policy for existing subdomains, and the np tag, new in RFC 9989, sets one for subdomains that do not exist in DNS. Without them, the p value applies to all three cases.
The inheritance order
RFC 9989 defines how the tags fall back:
- p applies to the domain queried and to subdomains, unless the subdomain policy is described using sp or np.
- sp applies only to existing subdomains of the organizational domain, not to the domain itself.
- np applies only to non-existent subdomains, not to existing subdomains or the domain itself. If np is absent, sp applies to them when present, otherwise p.
A subdomain that publishes its own DMARC record uses that record instead. Note that sp is ignored in records published on subdomains, because of the way policy discovery works.
Microsoft's documentation says the same in practical terms: the DMARC record for a domain automatically covers all subdomains that do not have their own record, including non-existent ones.
Why non-existent subdomains matter
Attackers can send mail from any name under your domain, such as billing-update.example.com, that has no DNS records at all. If the main policy is quarantine or reject, that is covered by inheritance. But if you keep your main domain at p=none while migrating, you can still harden the names that do not exist:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; np=reject; rua=mailto:dmarc-reports@example.com"
Nobody legitimate sends from a name that does not exist, so np=reject is low risk. Because np comes from RFC 9989, receivers still on older rules may ignore it, so treat it as an extra layer.
Common patterns
Single record at the top. One DMARC record on the organizational domain covers everything. Simple, and adequate for small setups.
Separate subdomain for vendors. Send marketing from a subdomain such as news.example.com, with its own SPF and DKIM and its own DMARC record. A mistake at the vendor affects reputation of that subdomain, not your main one. Microsoft recommends a subdomain for email services not under your direct control.
Strict top, relaxed edge. Reject on the main domain and a looser policy on an experimental subdomain while you work out its senders. This is where sp or a subdomain record helps.
Mistakes to avoid
- Setting sp=reject before inventorying subdomains. Internal tools often send from them.
- Assuming a subdomain with no DMARC record is unprotected. It inherits the parent policy.
- Relying on sp inside a subdomain record. It has no effect there.
- Forgetting that SPF and DKIM do not inherit. Each sending subdomain needs its own SPF record and DKIM signing.
Checking your setup
List your subdomains from DNS, from certificate transparency logs and from your mail platform. For each one, decide: sends mail, receives only, or neither. Then check that the effective policy matches what you want.
Quick check
Does a subdomain inherit my SPF record?
No. SPF is looked up for each name. Only DMARC falls back to the parent domain. Each subdomain that sends mail needs its own SPF record.
Sources
Last reviewed: 19 October 2026.
