DMARC sp vs np in RFC 9989: existing subdomains and nonexistent subdomains are different

The two tags answer different questions

The sp tag expresses the assessment policy for existing subdomains of the organizational domain when a more specific DMARC record does not take precedence. The np tag, now defined in the current DMARC base specification, addresses nonexistent subdomains. That difference is operationally useful because a business may legitimately send from known subdomains while wanting a different handling preference for invented names that should never send. Treating sp and np as synonyms loses the reason both tags exist.

Existing means DNS existence, not whether you send mail there

A subdomain can exist in DNS for a website, verification record, or another service even if no mailbox ever sends from it. In DMARC policy discovery, that existence matters to whether sp or np is applicable. Do not classify subdomains merely from your outbound platform’s mailbox list. Build a DNS inventory of important names and identify which ones can legitimately appear in RFC5322 From. If a real subdomain needs different mail policy, publishing a specific DMARC record there can be clearer than relying on parent inheritance.

Fallback behavior matters when tags are omitted

Under RFC 9989, p applies to the queried policy domain and can also become the fallback for subdomains when a more specific sp or np value is not present. If np is absent, the policy for a nonexistent subdomain falls back through sp when applicable and otherwise p. This means omitting a tag is still a policy decision. Before tightening the root record, understand which subdomains currently inherit it. A root-level change can affect more mail identities than the operator who edits the TXT record expects.

A dedicated sending subdomain can publish its own record

Suppose outbound.example.com is an intentional sending identity that is still being audited while the root domain is ready for stronger enforcement. A specific DMARC record at _dmarc.outbound.example.com can describe that subdomain directly. The more specific policy discovery result takes precedence for that author domain. This can be cleaner than weakening the root’s sp policy for every subdomain just because one mail stream is not ready. The design should follow actual mail architecture, not create dozens of policy records without ownership.

Use np to reason about invented author domains

Nonexistent subdomains are attractive in spoofing because they can look plausible to a recipient while having no legitimate sending system behind them. np gives the domain owner a current-standard way to express a policy preference for those names. For a small operator, the main task is not memorizing the tag syntax; it is validating that legitimate services do not unexpectedly use dynamic or previously undocumented subdomains. Aggregate reports and real-message headers can reveal surprises before you rely on stronger treatment.

Worked record design

Consider a root domain that sends normal mail, has one known outbound subdomain, and never expects mail from arbitrary names. The operator may keep the root at a tested policy, publish a specific record for the outbound subdomain while it is being validated, and use sp/np at the organizational domain to state preferences for other existing or nonexistent subdomains. The exact values should follow the business’s verified mail inventory. The important part is that each tag maps to a defined class of author domain rather than being copied from a generic “best DMARC record” template.

Do not use subdomain policy as a substitute for alignment

Whether the effective policy is taken from p, sp, or np, a message still needs aligned SPF or aligned DKIM to pass DMARC. A relaxed subdomain policy does not make an unaligned third-party sender authenticated. Fix the sender’s Return-Path or DKIM signing domain so at least one mechanism aligns with the visible From domain. Policy determines the domain owner’s requested treatment for failure; it does not repair the underlying authentication identity.

Document the domain tree alongside the DMARC record

Keep a simple table with each sending domain, whether it exists, its visible From use, its SPF envelope domain, its DKIM d= domain, and the DMARC record that applies. When a new tool is added, update the table before editing DNS. This makes sp and np much easier to reason about than reading one long TXT string in isolation. It also gives future content and support work a precise source of truth about why the record is structured the way it is.

Model the DNS tree before choosing subdomain policy tags

The most reliable way to understand `sp` and `np` is to draw several concrete author domains under the organizational domain and label whether each name exists in DNS. RFC 9989 applies `sp` to existing subdomains when the organizational-domain policy is used, while `np` addresses non-existent subdomains. If `np` is absent, the applicable fallback comes from `sp` when present, otherwise from `p`. That means an invented host such as `random123.example.com` and a real delegated host such as `mail.example.com` can be governed by different requested policies even though both sit beneath the same parent.

Do not treat existence as “does this subdomain send email.” A hostname can exist for a web app, verification token, or unrelated DNS purpose and still count as existing for this distinction. When documenting the policy, include the names your infrastructure creates automatically, wildcard records, delegated zones, and the dedicated outbound subdomain. Then test policy discovery with several representative From domains. This domain-tree map is especially useful during cleanup: deleting a DNS name can move it from the `sp` case into the `np` case without anyone changing the DMARC TXT record. A short policy string can therefore have different effects after an unrelated DNS change, which is why the surrounding domain inventory belongs in the deliverability runbook.

Field checklist

• Inventory existing subdomains before changing root DMARC policy.
• Use sp to reason about existing subdomains and np for nonexistent ones.
• Publish a specific DMARC record for a subdomain when it needs its own policy.
• Verify aligned SPF or DKIM independently of policy tags.
• Use aggregate evidence to find undocumented sending subdomains.
• Maintain a domain-tree table with the policy that applies to each sender.