How to use the DMARC np tag to protect nonexistent subdomains from spoofing

Most DMARC subdomain advice starts with sp. That tag is useful, but it treats every subdomain without its own DMARC record as one group. A domain that exists in DNS and a name that does not exist at all are not always the same security decision.

The np tag, introduced by RFC 9989, gives domain owners a separate policy for nonexistent subdomains. It lets you keep a deliberate policy for real subdomains while rejecting mail that invents a new, unregistered name under your domain.

Why nonexistent subdomains need their own policy

Imagine example.com has a marketing subdomain called news.example.com. The organization may want that subdomain to use a cautious policy until its sender inventory is complete. At the same time, a message claiming to be from security-alerts.example.com is using a name that does not exist in DNS at all.

Those two cases have different operational meanings:

• An existing subdomain may be an incomplete but legitimate mail stream.
• A nonexistent subdomain is often an invented identity, with no DNS owner or mail configuration behind it.

Before RFC 9989, the usual sp policy handled both cases. np lets the domain owner say, in effect, “be patient with known subdomains, but do not give nonexistent ones the same room.”

This is still ordinary DMARC enforcement. The message must fail DMARC, and a receiver must choose to honor the published policy. The tag does not authenticate a message by itself and does not make a receiver reject every message using a nonexistent name.

What np means

np is the policy for mail that uses a nonexistent subdomain of the organizational domain and fails DMARC validation. Its value is one of the normal DMARC dispositions:

• np=none: take no requested enforcement action
• np=quarantine: treat the message as suspicious
• np=reject: reject the message when the receiver honors the policy

For this purpose, “nonexistent” has a precise DNS meaning. If the DNS response for the name is NXDOMAIN, the name does not exist. A name that exists but has no useful mail records is a different case.

The policy applies only to nonexistent subdomains. It does not apply to:

• the organizational domain itself, which uses p
• an existing subdomain, which uses its own DMARC record or sp
• a subdomain that publishes its own DMARC policy

The distinction is important because np is not a stronger version of sp. It is a separate branch in policy selection.

A practical record

Suppose the organization is still monitoring existing subdomains but wants invented subdomains rejected:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc@example.com"

This expresses three different decisions:

• p=reject protects mail claiming to be from example.com itself.
• sp=none avoids enforcement for existing subdomains that do not publish their own DMARC record.
• np=reject requests rejection for nonexistent subdomains that fail DMARC.

The address in the example is reserved for documentation. Replace it with a report destination that is actually configured for your domain.

How a receiver applies the policies

Consider the following names under the same policy record:

Only the last row uses np. If security-alerts.example.com publishes a DNS record later, it is no longer nonexistent. Its handling then follows the normal policy-discovery rules, not np simply because the name appeared in a previous message.

The receiver still evaluates SPF and DKIM alignment for the message. A message that passes DMARC is not subject to a failure disposition. The np value matters when the message using the nonexistent Author Domain fails DMARC.

np versus sp

The easiest mistake is to read np=reject as “reject all subdomains.” It does not do that.

sp remains the policy for existing subdomains without their own DMARC record. np is used only for nonexistent subdomains. If np is omitted, RFC 9989 says that a receiver uses sp when present, or p when sp is also absent.

That fallback means an older-style record continues to have a predictable meaning:

v=DMARC1; p=reject; sp=quarantine

Without np, both an existing subdomain with no own record and a nonexistent subdomain can inherit the subdomain policy. Adding np=reject changes only the nonexistent-subdomain case:

v=DMARC1; p=reject; sp=quarantine; np=reject

For a fuller explanation of inheritance, see DMARC subdomain policy best practices. The DMARC record tag cookbook is also useful when checking the rest of a record.

Check DNS behavior before publishing np

The word “nonexistent” depends on the DNS answer, so test the names rather than inferring their state from a spreadsheet.

For a name that should not exist, query its address records and pay attention to whether the response is NXDOMAIN:

dig nonexistent.example.com A
dig nonexistent.example.com AAAA

Some DNS configurations use wildcards. A wildcard can make a name appear to exist even though nobody created a record specifically for it. In that situation the receiver may not classify the name as nonexistent, so np is not a replacement for reviewing wildcard behavior.

Also check delegated zones. If sub.example.com is delegated, the DNS behavior below that delegation is managed separately. A name can be nonexistent in that delegated zone without behaving like an unconfigured name in the parent zone.

Roll it out without surprising senders

np is most useful when it reflects how the DNS namespace is managed. A small rollout sequence keeps the change explainable:

1. Inventory every domain found in the visible From: field of legitimate mail, including rarely used subdomains.
2. Identify which names exist in DNS and which names are expected to remain nonexistent.
3. Verify SPF or DKIM alignment for legitimate subdomain mail. np cannot make an incorrectly authenticated sender pass DMARC.
4. Start with np=none if the organization needs to observe receiver behavior and reports before enforcement.
5. Move to np=quarantine or np=reject after confirming that no planned sender relies on a name that is currently returning NXDOMAIN.
6. Keep monitoring aggregate reports for unauthorized sources and for legitimate mail that was addressed from an unexpected subdomain.

Do not use np to hide an unmanaged sender. If a real service sends from alerts.example.com, create an intentional DNS and DMARC configuration for that subdomain. Use sp or an explicit subdomain record for its rollout, and reserve np for names that truly should not exist.

A narrower, stronger default

For domains where only a few subdomains are approved senders, a sensible target can be:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com

That record requests enforcement for the organizational domain, existing subdomains without their own record, and nonexistent subdomains. It is appropriate only after legitimate mail streams are authenticated and aligned. If existing subdomains are still being discovered, keep sp less strict while using np to close the clearly unwanted namespace.

The useful distinction

sp answers, “What should happen to an existing subdomain that has not published its own DMARC record?” np answers, “What should happen when the claimed subdomain does not exist in DNS at all?”

Once those questions are kept separate, the record becomes easier to reason about. Protect real sending identities with an explicit plan, and use np to prevent an invented subdomain from receiving the same policy as a namespace that the organization actually operates.