What the new DMARC np= tag means for email security
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.
How it works
Once you click Generate, Ollama reads this article and crafts 5 comprehension questions. Your answers are graded against the article content — general knowledge won't be enough. Score 70+ to count toward your certificate.
Questions are cached — you'll always get the same 5 for this article.