Back to Learning Center Email Authentication

Do subdomains inherit DMARC policy?

Q: Does sp override p for every subdomain?

No. The sp tag applies to existing subdomains that inherit the applicable parent policy. A valid DMARC record at the exact Author Domain can supply that domain's policy instead.

Q: What happens if the parent record has no sp tag?

The applicable parent p value is used for an existing subdomain that inherits the parent policy. The receiver still makes the final local handling decision.

Q: Can np protect unused subdomains?

Yes. The np tag can request handling for DMARC failures from non-existent subdomains under the applicable policy domain. It does not authenticate messages or prove that a receiver will take a particular action.

By Samuel ChenardAugust 11, 20269 min read

Ask AI to explain

In brief

Do subdomains inherit DMARC policy? Yes, when no valid record exists at the subdomain, DMARC can apply parent p, sp, or np tags for DMARC failures.

Yes. A subdomain can inherit an applicable DMARC policy when it does not publish a valid DMARC record of its own. DMARC first checks the visible From domain, called the Author Domain. If discovery finds an applicable parent policy domain instead, the sp tag can control existing subdomains, np can control non-existent subdomains, and p is the fallback when those tags are absent.

This page answers the policy-discovery question: which p, sp, or np value applies after the RFC 9989 DNS Tree Walk. For the separate question of how relaxed and strict SPF or DKIM alignment work together, use the aspf and adkim comparison. For an operational strict-DKIM change, use the adkim validation and rollback guide.

At a glance

Quick takeaways

A subdomain does not need its own DMARC record when the parent policy provides the intended handling.
A valid DMARC record at the exact visible From domain takes precedence over a parent policy.
The sp tag requests handling for existing subdomains when policy discovery selects the Organizational Domain or PSD record.
The np tag requests handling for non-existent subdomains under the applicable policy domain.
If sp or np is absent where applicable, DMARC falls back to the parent record's p value.
RFC 9989 ignores sp on a DMARC Policy Record published on a subdomain of an Organizational Domain or PSD.
Inherited policy does not make a sender pass DMARC. The message still needs aligned SPF or DKIM.

`p`, `sp`, and `np` precedence at a glance

Policy discovery result	Author Domain status	Requested policy used after DMARC failure
Valid record found at the exact Author Domain	Existing or non-existent	That record's `p`
Applicable record found at the Organizational Domain or PSD	Existing subdomain	`sp`, or `p` when `sp` is absent
Applicable record found at the Organizational Domain or PSD	Non-existent subdomain	`np`, or `sp`, then `p`, when the more specific tag is absent

The table describes RFC 9989 Section 4.10.1 policy discovery. It does not guarantee a delivery outcome: the published value is a Domain Owner Assessment Policy that a Mail Receiver can consider alongside its local handling rules.

How DMARC policy inheritance works

DMARC policy discovery in RFC 9989 starts with the domain in the message's visible From header. For a message from billing.example.com, the receiver first queries _dmarc.billing.example.com. If it does not find a valid record there, it follows the standard's bounded DNS Tree Walk to find the Author Domain's Organizational Domain or PSD. RFC 9989 caps the walk at eight DNS queries for deeply nested names.

The resulting policy record determines the requested treatment only after the message fails DMARC. A message passes DMARC when SPF or DKIM passes and the authenticated domain aligns with the visible From domain. For the broader protocol context, see what a domain's DMARC policy means.

When a parent record supplies the policy, RFC 9989 section 4.7 defines the relevant tags:

p is the requested handling for DMARC failures at the policy domain and the fallback policy where no more specific applicable tag changes the result.
sp is the requested handling for failures using existing subdomains when the applicable record belongs to the prevailing Organizational Domain or PSD.
np is the requested handling for failures using non-existent subdomains of the policy domain.

These tags express a domain owner's requested handling. A receiving system still applies its own local policies and makes the final delivery decision. An inherited p=reject request does not prove that every receiver will reject every future failing message.

Decision flow showing whether a DMARC policy comes from an exact subdomain record or parent p, sp, and np tags — Source: Palisade.

When the answer changes

The answer changes based on whether the subdomain exists and whether it publishes its own usable record.

A valid record exists at the visible From domain

A record published for marketing.example.com can govern mail that uses marketing.example.com in the visible From field. In that case, the parent record does not supply the policy for that Author Domain.

Publishing a separate record is useful when that subdomain needs a different reporting destination, alignment setting, policy stage, or operational owner. It is not required merely because the subdomain sends mail.

The exact Author Domain record uses its p value. Its sp value does not create another policy layer below that subdomain: RFC 9989 says sp is ignored on DMARC Policy Records published on subdomains of Organizational Domains and PSDs.

The subdomain exists but has no valid DMARC record

For an existing subdomain that inherits a parent policy record, sp applies if the parent record includes it. If sp is absent, the parent record's p value applies.

For example, p=reject; sp=quarantine asks receivers to use quarantine for DMARC failures from existing subdomains that inherit this record, while failures from the policy domain itself receive the reject request.

The subdomain does not exist

For a non-existent subdomain, np applies when the applicable policy record includes it. If np is absent, the protocol uses the fallback defined by the applicable policy, which can be sp and then p.

This distinction matters when a domain owner wants stronger protection against spoofing from unused names without imposing the same requested handling on legitimate active subdomains. The meaning of the DMARC sp tag is useful when reviewing the existing-subdomain case.

A usable decision rule is:

Publish an explicit subdomain record only when that Author Domain needs a different policy or reporting arrangement.
Use sp when existing subdomains should receive a different inherited policy from the parent domain.
Use np when non-existent subdomains need a different inherited policy.
Keep p as the parent policy baseline.

Do not raise a parent p, sp, or np policy based on DNS alone. A policy can affect mail from many Author Domains, including low-volume production paths that a public lookup cannot reveal.

Worked example: a parent policy with subdomain rules

The following is illustrative only. Do not copy the reporting address into production. Use the address authorized for your own DMARC report processor.

Technical exampletext

v=DMARC1; p=quarantine; sp=reject; np=reject; rua=mailto:dmarc-reports@yourdomain.com

For this parent policy at _dmarc.yourdomain.com:

Mail using yourdomain.com in the visible From field receives the quarantine request after DMARC failure.
Mail from an existing subdomain such as billing.yourdomain.com, with no valid record at _dmarc.billing.yourdomain.com, receives the reject request after DMARC failure.
Mail from a non-existent subdomain such as madeup.yourdomain.com receives the reject request after DMARC failure.
A valid DMARC record at _dmarc.billing.yourdomain.com can supply the policy for billing.yourdomain.com instead.

The record does not identify legitimate senders or show whether their messages align. For each active source, inspect a real delivered message's authentication results and confirm that SPF or DKIM passes with alignment to the visible From domain. RFC 8601 defines the Authentication-Results header field, which records the receiver's authentication assessment.

Validate the policy that production mail uses

Start with the evidence you have, then move through independent checks.

If you have only a domain name

Use the Palisade DMARC checker to inspect the public record for the parent domain and each active visible From subdomain. Record the exact TXT values, lookup time, and DNS TTL. A public lookup can show what DNS publishes, but it cannot prove that an application sends through the expected path or that a receiver applied the requested policy.

Query authoritative DNS and at least one public resolver after any change. Resolver caching can delay the result seen by different receivers.

If you manage a sending application

Check the sending provider's current authentication status for the exact production domain. Then send a real message through that application to a mailbox where you can inspect the full headers. Confirm the visible From domain, the SPF and DKIM results, and alignment in Authentication-Results.

A green provider status is useful vendor evidence. It is not proof that the delivered production message used the configured return path or DKIM signing domain.

If you receive DMARC aggregate reports

Review reports after sufficient production traffic accumulates. Group the data by header_from domain so parent-domain traffic and subdomain traffic do not blend together. Look for legitimate sources that fail SPF or DKIM alignment before moving an inherited policy toward quarantine or reject.

Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when a domain appears ready, while a human reviews the evidence and applies the DNS change.

Check the public policy before changing subdomain handling

Inspect the parent domain and the exact visible From subdomain before deciding whether inheritance is the issue. Compare the published tags with delivered-message headers and aggregate reports, especially when a subdomain is sent by a separate application.

Check the DMARC policy

A public DMARC check does not prove which production sources still fail alignment, whether a receiver applied a local exception, or whether every future message will authenticate. When reports show an ongoing cross-domain inventory and remediation problem, Start with Palisade to analyze aggregate-report evidence and prioritize the remaining work. Palisade proposes policy steps, but your team reviews the evidence and applies any DNS change.

Evidence

Sources and further reading

Questions readers ask

Frequently asked questions

Does every sending subdomain need its own DMARC record?

No. A sending subdomain can inherit an applicable parent DMARC policy when it has no valid record of its own. It still needs aligned SPF or DKIM for its messages to pass DMARC.

Does sp override p for every subdomain?

No. The sp tag applies to existing subdomains that inherit the applicable parent policy. A valid DMARC record at the exact Author Domain can supply that domain's policy instead.

What happens if the parent record has no sp tag?

The applicable parent p value is used for an existing subdomain that inherits the parent policy. The receiver still makes the final local handling decision.

Can np protect unused subdomains?

Yes. The np tag can request handling for DMARC failures from non-existent subdomains under the applicable policy domain. It does not authenticate messages or prove that a receiver will take a particular action.

Does an inherited p=reject guarantee rejection?

No. DMARC policy tags are requests from the domain owner. A receiver can consider the request alongside its own local policy and other message signals.