DMARC continues to evolve. RFC 9989, the updated DMARC specification, introduces a new policy tag called np= for nonexistent subdomains. At first glance, it might seem unnecessary. If a subdomain doesn’t exist, shouldn’t mail claiming to be blocked automatically, given how email already works today?
Not necessarily.
Email doesn’t (technically) require the From domain to exist
One of the quirks of Internet email is that the domain shown in the visible From address doesn’t have to resolve in DNS. An attacker can send a message claiming to be from ceo@payroll.company.com even if payroll.company.com has never existed. Likewise, they could invent something completely random, like billing@secure-login.company.com or support@customer-updates.company.com. Those subdomains don’t need DNS records for an attacker to try to use them in the visible From header.
DMARC determines whether those messages authenticate, but prior to RFC 9989 there was no dedicated mechanism for a domain owner to publish a policy specifically for these nonexistent subdomains.
Enter the np= tag
RFC 9989 adds a new optional DMARC policy tag, with policy choices available that exactly match the DMARC policy choices for a domain (in the p= tag) or for subdomains (in the sp=tag), meaning that you can set an np= tag with a policy of none, quarantine or reject.
Together, these three tags allow you to set DMARC policy at different levels:
- p= defines the policy for the organizational domain.
- sp= defines the policy for existing subdomains.
- np= defines the policy for subdomains that do not exist in DNS.
This granularity gives domain owners another way to communicate their intentions to receiving mailbox providers.
Why publish np=reject?
Many organizations never create every possible subdomain beneath their domain. That means attackers have an effectively unlimited namespace to invent convincing-looking sender addresses:
- hr.company.com
- payroll.company.com
- invoices.company.com
- executive.company.com
Recipients don’t know whether those subdomains are legitimate. They simply see a familiar brand.
Publishing np=reject tells participating receivers that if mail claims to come from a nonexistent subdomain and fails DMARC authentication, the preferred handling is rejection.
The result is another obstacle for spoofers attempting to abuse your brand.
Isn’t this already covered by sp=?
Previously, the answer depended on how the receiver interpreted the DMARC specification.
RFC 9989 removes that ambiguity by giving nonexistent subdomains their own explicit policy. Existing delegated subdomains continue to use sp=, while nonexistent subdomains can now be governed separately with np=.
For example, an organization might publish policies of p=reject, sp=none, and np=reject. In this case, the domain owner’s request to mailbox providers is as follows:
- Reject spoofed mail claiming to come from the organizational domain.
- Allow existing delegated subdomains to define their own policies.
- Reject spoofed mail claiming to come from subdomains that don’t exist at all.
That distinction simply wasn’t possible before.
The “belt and suspenders” approach
Does this actually matter in practice? After all, several large mailbox providers already treat messages claiming to come from nonexistent domains or subdomains with suspicion. In many cases, those messages are more likely to be filtered or rejected based on the receiver’s own anti-abuse policies.
That’s true, but those decisions are implementation choices, not protocol requirements. To date, the internet RFCs governing email do not require that sender email address hostnames and domains resolve in DNS. Neither SMTP nor earlier versions of DMARC were structured to instruct receivers to handle nonexistent subdomains in a particular way.
The new np= tag gives domain owners a standardized way to communicate their intent. Rather than relying solely on receiver heuristics, organizations can explicitly publish a policy saying, “If someone claims to be sending from a subdomain that doesn’t exist under my domain, here’s how I’d like you to handle it.”
Think of it as a belt-and-suspenders approach. Good mailbox providers may already catch many of these messages, but np= provides another signal that helps receivers make the right decision consistently.
Another improvement for DMARC
While not revolutionary, the introduction of np= is a useful refinement to the DMARC specification. It provides domain owners a clearer way to express their intent, removes ambiguity from the specification, and helps close another avenue attackers can use when impersonating trusted brands.
Like many improvements in email authentication, it won’t stop phishing by itself. But when combined with SPF, DKIM, and DMARC enforcement, np= gives mailbox providers one more signal they can use to identify and reject fraudulent mail before it reaches the inbox.
Protect all your domains and subdomains with Valimail
Hopefully, you now have a better idea of how DMARC record lookups work. Defining DMARC records on subdomains is definitely an advanced topic and, in most cases, is probably not necessary.
Navigating the complexities of DMARC and its implications for your domains and subdomains can be daunting. The intricacies of how DMARC policies are applied to email communications (especially when subdomains come into play) underscore the need for a robust, intelligent solution.
And that’s where Valimail can help.
The challenges associated with managing DMARC records, particularly for organizations with multiple subdomains, can lead to vulnerabilities (if not addressed properly). Valimail’s platform is designed to eliminate these vulnerabilities by offering:
Automated DMARC Record Management: Valimail automates the configuration and management of DMARC records for both your main domain and any subdomains, ensuring consistent protection across your entire email ecosystem.
Simplified Policy Enforcement: With Valimail, moving from a policy of none to quarantine or reject is streamlined, making the transition to full DMARC enforcement a smooth process for your organization.
Comprehensive Visibility: Gain clear insights into your email authentication status across all domains and subdomains, with detailed reporting that helps identify and rectify potential issues before they become problematic.
Ready to secure your domains and subdomains? Learn how Valimail can better protect your brand.
Facts Only
* RFC 9989 updates the DMARC specification.
* RFC 9989 introduces a new optional DMARC policy tag called np= for nonexistent subdomains.
* Email does not technically require the From domain to exist in DNS.
* Attackers can use non-existent subdomains in email headers without corresponding DNS records.
* DMARC determines message authentication, but there was no prior mechanism for publishing policies specifically for nonexistent subdomains.
* RFC 9989 adds three tags: p= defines the policy for the organizational domain, sp= defines the policy for existing subdomains, and np= defines the policy for non-existent subdomains.
* The np= tag allows setting policies of none, quarantine, or reject for nonexistent subdomains.
* Domain owners can publish policies such as p=reject, sp=none, and np=reject to communicate intent regarding different domain levels.
* Previous interpretations of DMARC regarding nonexistent domains were ambiguous before RFC 9989.
* Mailbox providers may already treat messages from nonexistent domains with suspicion based on their own anti-abuse policies.
Executive Summary
The DMARC specification is evolving with RFC 9989, introducing a new policy tag np= for nonexistent subdomains. This allows domain owners to specify policies (none, quarantine, or reject) for mail claiming to originate from subdomains that do not exist in DNS. The framework introduces three distinct policy tags: p= for the organizational domain, sp= for existing subdomains, and np= for non-existent subdomains. This granularity allows domain owners to communicate specific intentions regarding spoofed messages across different levels of their domain structure.
The introduction of np= addresses a gap where domain owners needed a mechanism to manage policies for nonexistent parts of their domain that attackers frequently attempt to abuse by inventing fictional subdomains. By explicitly defining how non-existent domains should be handled, this refinement aims to provide a standardized signal to receiving mailbox providers regarding the handling of fraudulent mail claiming to originate from these fabricated addresses.
While some receivers may already treat messages from nonexistent domains with suspicion based on their own policies, the np= tag provides an explicit protocol mechanism for communicating intent, moving beyond reliance solely on receiver heuristics. This refinement adds another layer of defense by offering domain owners a standardized way to manage authentication policy across all levels of their domain hierarchy.
Full Take
The shift introduced by np= represents a move from implicit, heuristic-based enforcement to explicit, standardized signaling within the DMARC protocol. The core pattern here is addressing information asymmetry: domain owners possess knowledge about what subdomains they use (or don't use), while receiving providers must act on incomplete information regarding external entities. By creating an explicit channel for nonexistent domains, the specification attempts to close this gap, moving responsibility for defining handling from generalized receiver policy toward explicit domain ownership intent.
The implication is a refinement of systemic control. The prior reliance on receiver heuristics meant that protection was dependent on the implementation choices of various mailbox providers, introducing fragility. Introducing np= standardizes the communication layer, suggesting that entities capable of enforcing DMARC should have a mechanism to enforce specific rules for non-existent entities, rather than relying on generalized suspicion. This forces an evolution where security measures are less about reacting to perceived threats and more about explicitly defining organizational boundaries in the protocol itself.
The complexity arises from balancing protocol rigor with practical implementation realities. While the technical update provides clearer structure—allowing a triple policy setting for the domain level (p), existing subdomains (sp), and non-existent ones (np)—the actual effect on real-world phishing resistance depends on universal adoption and consistent enforcement across all receiving services. The transition tests whether protocol evolution alone is sufficient, or if it necessitates the structural support—like the platform solutions mentioned—to ensure that this increased signaling translates into uniform protective action against impersonation.
What evidence exists to suggest that explicit signaling universally improves trust outcomes over existing mechanisms, or does it simply add another layer of complexity?
What systemic pressure is there for mailbox providers to adopt these explicit rules, versus letting them rely on current filtering strategies?
If domain ownership boundaries become more granularly defined by policy tags, what are the potential governance challenges for managing highly complex, multi-layered organizational email infrastructure?
Sentinel — Human
This analysis is grounded in accurate technical details and exhibits a structured argument typical of expert-driven journalism, concluding with a product recommendation.