DMARC np= adds explicit policy control for nonexistent subdomains

At a glance

What this is: RFC 9989 extends DMARC with an np= policy tag for nonexistent subdomains, closing a spec gap that left invented sender names without explicit handling guidance.

Why it matters: Email security teams should care because attackers can still exploit brand trust through subdomain lookalikes, and clearer policy signalling improves how mailbox providers treat spoofed mail.

Context

DMARC policy is not just about whether a message passes authentication. It is also about how domain owners communicate intent to receivers when a message claims to originate from a domain or subdomain that should not exist.

RFC 9989 matters because email has long allowed visible From addresses that do not resolve in DNS, which creates a governance gap for spoofing and brand impersonation. DMARC, SPF and DKIM already shape authentication, but this update adds a policy layer for nonexistent subdomains.

Key questions

Q: How should security teams handle nonexistent subdomains in DMARC policy?

A: Treat nonexistent subdomains as part of your email identity surface, not as a harmless edge case. Publish an explicit np= policy, align it with p= and sp=, and make sure receivers are actually honouring the intent. The goal is to reduce ambiguity around invented sender names that attackers can use for brand impersonation.

Q: Why do invented subdomain sender names increase phishing risk?

A: Because the visible From address can look legitimate even when the subdomain does not exist in DNS. That lets attackers borrow brand trust without needing control of a real subdomain. If recipients or mailbox providers do not have a clear policy signal, the message may be treated as merely unusual instead of clearly fraudulent.

Q: What are the signs that DMARC policy is still ambiguous?

A: Ambiguity shows up when existing subdomains and nonexistent subdomains are handled the same way, when receiver behaviour varies widely, or when your organisation has no published rule for invented sender identities. If security and messaging teams cannot explain how each subdomain class should be treated, policy is underspecified.

Q: What is the difference between sp= and np= in DMARC?

A: sp= applies to real, existing subdomains that are part of your DNS namespace. np= applies to subdomains that do not exist at all. That separation matters because it lets domain owners state a policy for delegated subdomains and a different policy for invented ones that attackers may use in spoofed mail.

Technical breakdown

How np= changes DMARC policy evaluation

DMARC now has three distinct policy scopes. The p= tag governs the organizational domain, sp= governs existing subdomains, and np= governs subdomains that do not exist in DNS. That distinction matters because a receiver can evaluate authentication successfully and still lack a domain-owner signal for a fabricated subdomain. np= does not change the underlying SPF or DKIM checks. It tells participating receivers how the domain owner wants messages handled when the claimed subdomain has no DNS existence and the message fails DMARC alignment. See the DMARC, SPF and DKIM Guide.

Practical implication: Set explicit policy intent for nonexistent subdomains instead of assuming receivers will infer it.

Why nonexistent subdomains create a brand abuse path

An attacker does not need a real subdomain to abuse a familiar brand in the visible From header. They can invent addresses such as payroll.company.com or invoices.company.com and rely on the recipient’s trust in the brand shape rather than the DNS state of the subdomain. That is why np= is valuable: it converts an implicit assumption into an explicit policy signal. The mechanism is defensive signalling, not automatic prevention, and its effectiveness still depends on receiver support and full DMARC enforcement.

Practical implication: Treat invented subdomain names as a phishing and impersonation problem, not just a DNS hygiene issue.

What changes when mailbox providers honour np=reject

When receivers honour np=reject, they get a stronger instruction to reject mail that claims to come from a nonexistent subdomain and fails authentication. This does not stop all phishing, because some mailbox providers already apply their own anti-abuse heuristics and others may handle the same traffic differently. The practical change is consistency. Domain owners gain a standard way to express that invented subdomains are not legitimate sending identities, which reduces ambiguity across the mail ecosystem.

Practical implication: Use np=reject as a reinforcing control, not a substitute for SPF, DKIM and DMARC enforcement.

Threat narrative

Attacker objective: The attacker wants to exploit brand trust with invented subdomains so fraudulent email is delivered or acted on as if it were legitimate.

1. Entry occurs when an attacker sends mail using a visible From address built from a fabricated subdomain that looks legitimate to the recipient.
2. Credential or trust abuse follows when the brand name and familiar subdomain pattern lower suspicion and increase the chance of message handling.
3. Impact is mailbox delivery or user interaction with spoofed mail that could support phishing, payment redirection or other impersonation fraud.

NHI Mgmt Group analysis

np= closes a DMARC ambiguity, but it does not change the core trust model. The control value is not in inventing a new anti-phishing mechanism. It is in giving domain owners a formal way to describe how receivers should treat mail that claims to come from a subdomain that does not exist. That makes policy intent more precise, which is useful because security outcomes often fail at the boundary between authentication and receiver interpretation. Practitioners should see np= as policy clarification, not as a standalone protection layer.

Nonexistent subdomains are a governance problem as much as a technical one. Attackers exploit the fact that a familiar brand pattern can exist without a real DNS entry, and many organisations do not manage their subdomain namespace as an identity surface. That creates a gap between what domain owners intend and what receivers infer. Email Identity and BEC is the broader lens here: if the recipient cannot distinguish delegated, existing, and invented sending identities, spoofing opportunities remain.

DMARC enforcement remains only as strong as the weakest receiving interpretation. Some large mailbox providers already apply heuristics to suspicious mail, but implementation choice is not the same as protocol requirement. np= matters because it standardises intent across receivers that choose to honour it, which improves consistency for brand protection programmes. Practitioners should therefore assess receiver support, not just publish the tag and assume the problem is solved.

Brand impersonation controls work best when namespace control and authentication policy are treated together. The article’s central lesson is that email identity is not only about valid records, it is also about invalid-but-convincing sender names that should never be treated as legitimate. That makes DMARC policy design part of identity governance for the mail channel. The right response is disciplined namespace policy, strict authentication, and receiver signalling that matches both.

What this signals

Namespace governance is becoming part of email identity control. DMARC is no longer just a pass or fail mechanism for authenticated mail. With np=, domain owners can express how receivers should treat sender identities that should not exist in the first place, which makes namespace discipline a practical part of anti-impersonation strategy.

Receiver consistency is the real deployment question. The value of np= depends on whether mailbox providers interpret and enforce it in a similar way. Security teams should watch for uneven receiver handling, because inconsistent policy interpretation leaves the weakest delivery path as the attacker’s opportunity.

For practitioners

• Define explicit policy for nonexistent subdomains Review your subdomain namespace and decide whether invented sender names under your brand should be rejected, quarantined or ignored by receiver policy.
• Align p=, sp= and np= settings Make sure your organisational domain policy, existing subdomain policy and nonexistent subdomain policy tell a consistent story to mailbox providers.
• Test receiver behaviour before assuming enforcement Validate how your major mailbox partners handle np= and whether their filtering or rejection behaviour matches your published intent.
• Inventory delegated and undocumented subdomains Identify which subdomains are real, which are delegated and which should never be accepted as valid sending identities.

Key takeaways

• DMARC’s new np= tag addresses a real policy gap around nonexistent subdomains, which attackers can exploit for brand impersonation.
• The change matters less as a technical detection mechanism than as a clearer signal to mailbox providers about how invented sender identities should be handled.
• Teams should pair np= with strict SPF, DKIM and DMARC enforcement, then verify that major receivers apply the policy as intended.

Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide · Email Identity and BEC Guide · Email Security Guide

Key terms

• Non-existent Subdomain: A non-existent subdomain is a hostname beneath an organizational domain that looks legitimate but has no DNS record. Attackers use these names to mimic trusted namespaces and exploit policy ambiguity, making explicit handling a useful anti-spoofing control.
• Subdomain Namespace: The set of real and potential subdomains beneath an organisational domain. In email security, the namespace matters because attackers can exploit unused or nonexistent names to create believable sender addresses that look legitimate to recipients even when no DNS record exists.
• DMARC None Policy: DMARC None Policy is a monitoring-only DMARC setting that asks receivers to report authentication results without changing delivery. It helps domain owners discover legitimate and abusive sources before enforcement. Attackers can still deliver spoofed mail if no stronger policy is applied, so organisations should use the reports to fix alignment and prepare for quarantine or reject.
• Email Brand Impersonation: The use of lookalike sender identities, including fabricated domains or subdomains, to make a message appear as if it came from a trusted organisation. It is a common social engineering pattern that relies on receiver trust more than technical compromise.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity policy design to the broader access and trust controls their programmes depend on.