Use p for the domain itself, sp for existing subdomains that do not publish their own DMARC record, and np for non-existent subdomains. If you omit sp or np, receivers fall back to p where applicable.
DMARC policy looks simple when a company has one domain and one mail stream. Real domains are messier. There is the organizational domain, active subdomains, delegated vendor subdomains, old campaign names, and names attackers invent because nobody ever created them.
RFC 9989 makes that boundary more explicit. The familiar p tag is still the main policy, but sp and np let a domain owner say what should happen to existing subdomains and non-existent subdomains separately.
The compact record
A domain that wants enforcement on the organizational domain, a slightly softer ramp for existing subdomains, and hard blocking for invented names can publish one explicit policy.
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:reports@example.net"That record says three different things. Mail from example.com uses p=reject. Existing subdomains without their own DMARC record use sp=quarantine. Non-existent subdomains use np=reject.
p is the domain policy
The p tag is the domain owner assessment policy for the domain where the DMARC record applies. If the author domain is example.com and the receiver finds _dmarc.example.com, then p is the policy for that author domain.
If no applicable sp or np tag exists for a subdomain case, RFC 9989 falls back to the p policy for subdomains. That fallback is useful, but implicit inheritance is easy to misunderstand during rollout.
sp is for existing subdomains
The sp tag applies to existing subdomains of the organizational domain when those subdomains do not publish their own DMARC record. If mail.example.com exists and has no _dmarc.mail.example.com record, the receiver can apply the parent domain's sp value.
This is useful when the root domain is ready for enforcement but subdomain ownership is still decentralized. It lets the root move to p=reject while subdomains run at sp=quarantine or sp=none during cleanup.
- Subdomains exist and some are managed by different teams or vendors.
- The root domain is ready for enforcement before every subdomain is ready.
- You want inherited subdomain policy to be explicit instead of accidental.
- You need aggregate reports to show which subdomains still need their own DMARC record.
np is for names that do not exist
The np tag is the newer piece that closes a practical spoofing gap. It applies when the author domain is a non-existent subdomain under the policy domain. Think invoice.eu-west-4.example.com when no such DNS name exists.
These names are valuable to attackers because they look plausible and usually have no legitimate mail stream to protect. For many domains, np=reject is the safest default once the organization understands its real subdomain inventory.
- Random-looking subdomains show up in aggregate reports.
- Marketing, support, and billing subdomains are known and inventoried.
- Unused names should fail closed instead of inheriting a softer rollout policy.
- The domain is used in phishing lures that invent plausible business-unit names.
Own-record beats inherited policy
A subdomain can publish its own DMARC policy. If the receiver finds a valid policy record on the author domain itself, the policy comes from that record's p tag. That is how delegated mail streams get clear ownership.
_dmarc.news.example.com. TXT "v=DMARC1; p=reject; rua=mailto:reports@example.net"In practice, important sending subdomains should not rely forever on parent-domain inheritance. Give them explicit records, monitor their aggregate reports, and make the policy owner visible.
DNS Tree Walk changed the mental model
RFC 9989 replaced Public Suffix List dependence with the DNS Tree Walk for policy discovery and organizational-domain determination. Receivers can walk up the DNS tree looking for the applicable DMARC record, with limits to avoid pathological lookup chains.
The operational result is that DNS now carries more of the domain-boundary signal. For complex companies, that is a reason to keep DMARC records explicit at every domain boundary where ownership changes.
The safe rollout pattern
Start by inventorying real subdomains from aggregate reports and DNS. Move the root domain toward enforcement. Set sp based on how ready existing subdomains are. Use np=reject once invented names should be blocked decisively.
- List subdomains that send mail and give important ones explicit DMARC records.
- Do not leave sp weaker than p forever; use it as a transition tool.
- Set np deliberately instead of letting non-existent names inherit by accident.
- Watch aggregate reports after each policy change for legitimate subdomain breakage.
- Keep ownership clear when a subdomain is delegated to a vendor or business unit.
Where DMARCify fits
DMARCify can make this visible by separating root-domain traffic, existing subdomain traffic, and non-existent subdomain attempts. Those are different operating questions, and they deserve different dashboards.
The rule of thumb: use p for the domain, sp for real subdomains, and np for names that should not exist.
Disclosure: AI tools were used in the process of creating this blog post.