Subdomain Spoofing: The DMARC Vulnerability That DMARCbis Was Built to Fix

The Attack That p=reject Cannot Stop

You have done everything right. You published a DMARC record on your root domain. You moved through p=none, past p=quarantine, and reached the gold standard: p=reject. SPF and DKIM are properly configured and aligned. Your DMARC analyzer shows 99%+ pass rates across all legitimate senders. Your domain is protected.

Or so you think.

An attacker sends a phishing email from ceo.yourdomain.com. Or accounting.yourdomain.com. Or secure-login.yourdomain.com. These subdomains do not exist in your DNS. You never created them. You have no SPF or DKIM records for them. And that is exactly the problem, because under the current DMARC specification (RFC 7489), a receiving server that encounters an email from a non-existent subdomain may not find a DMARC policy to apply to it.

Academic researchers from the University of Grenoble and the University of Twente (PDF) demonstrated this vulnerability in their peer-reviewed research: “If there is no wildcard TXT record that covers non-existing subdomains and there is no DMARC policy specified for subdomains and the domain itself, then it is possible to send spoofed emails from non-existent subdomains.” Even domains with strong root-level DMARC enforcement can be vulnerable if they have not explicitly addressed subdomains.

This is the subdomain spoofing gap. It is a real vulnerability exploited in real attacks. And the IETF has designed a specific technical solution for it: the np= tag in DMARCbis (DMARC 2.0), the updated DMARC specification expected to be published as an official Proposed Standard in 2026.

How Subdomain Spoofing Works: The Technical Gap

To understand why subdomain spoofing is possible, you need to understand how DMARC policy discovery works for subdomains under the current specification.

The Current DMARC Policy Discovery Process

When a receiving mail server gets an email claiming to be from hr.marketing.example.com, it performs a DNS lookup for _dmarc.hr.marketing.example.com. If no DMARC record is found there, it falls back to the organizational domain by looking up _dmarc.example.com. If that record has a p=reject policy, the policy applies. If it also has an sp= (subdomain policy) tag set to reject, that explicitly covers subdomains. But if the sp= tag is absent, the p= policy is used as the default for subdomains.

The problem arises in the details of implementation. As the USENIX Security 2021 research (PDF) on email sender spoofing demonstrates, there are inconsistencies among email service providers in how they handle subdomain policy fallback. Some providers correctly apply the parent domain’s p= or sp= policy to subdomain mail. Others do not, particularly when the subdomain does not exist in DNS and returns an NXDOMAIN response. These inconsistencies create a gap that attackers exploit.

Why Non-Existent Subdomains Are Especially Dangerous

Non-existent subdomains present a unique challenge. The Grenoble-Twente academic research (PDF) found that when a subdomain returns NXDOMAIN (it does not exist in DNS), certain receiving servers may not walk up the DNS tree to find the parent domain’s DMARC policy. Instead, they treat the absence of a record as no policy, effectively allowing the spoofed email through.

This is particularly dangerous because attackers can invent any subdomain they want. They are not limited to real subdomains your organization uses. They can create ceo.yourdomain.com, payroll.yourdomain.com, or security-alert.yourdomain.com, none of which exist, and send phishing emails that appear to come from authoritative-sounding addresses within your domain hierarchy.

The sp= Tag: A Partial Fix

The current DMARC specification includes the sp= (subdomain policy) tag, which allows domain owners to set a specific policy for subdomains. Setting sp=reject theoretically addresses the problem by telling receivers to reject all unauthenticated subdomain mail. However, as the IETF DMARCbis draft acknowledges, the sp= tag does not distinguish between existing and non-existent subdomains, it applies the same policy to both. This creates a blunt instrument when organizations need different handling for real subdomains (which might have their own legitimate sending infrastructure) versus fabricated subdomains (which should always be rejected).

The core vulnerability: Under the current DMARC standard, an attacker can fabricate any subdomain of your domain and send spoofed email from it. If your DMARC record lacks an sp= tag, or if the receiving server does not properly handle NXDOMAIN subdomain lookups, the spoofed email may reach the inbox despite your root domain being at p=reject.

Financial Impact of Impersonation Attacks Chart

Subdomain Spoofing in the Wild: The CEO Fraud Epidemic

Subdomain spoofing is not a theoretical vulnerability. It is the operational mechanism behind a significant portion of CEO fraud and Business Email Compromise attacks, the most costly category of cybercrime.

Keepnet Labs reports that 89% of BEC attacks impersonate authority figures like CEOs, and that CEO fraud targeting has reached at least 400 companies per day. The FBI’s IC3 data shows $51 billion in exposed losses due to BEC fraud historically, with BEC attack volume surging 103% in 2024. Vectra AI’s analysis confirms that organizations with 50,000 or more employees face near-100% weekly BEC risk.

The connection to subdomains is direct. When attackers cannot spoof the root domain (because it is at p=reject), they shift to subdomains. An email from ceo@accounting.yourdomain.com is nearly as convincing as one from ceo@yourdomain.com, especially to a finance team member under pressure to process an urgent wire transfer. The subdomain adds a veneer of internal departmental legitimacy that makes the social engineering more effective.

Real-World Cases

The $25.6 million Arup deepfake case in February 2024 demonstrated the convergence of domain impersonation and AI. While the attack involved deepfake video, the initial contact vector was email, and the sophisticated multi-channel approach relied on domain credibility. The Toyota Boshoku subsidiary lost $37 million in 2019 to BEC fraudsters impersonating executives. The Italian Defense Minister deepfake voice cloning in February 2025 extracted approximately €1 million from prominent business leaders including Giorgio Armani.

In each case, the attacker’s credibility depended on appearing to come from a trusted domain. Subdomain spoofing provides that credibility even when the root domain is protected.

Why this matters now: As more organizations reach p=reject on their root domains, attackers are adapting. Subdomain spoofing is the evolutionary response to DMARC enforcement. The attack surface shifts from the main domain to fabricated subdomains that the organization never created and may not even know can be exploited.

DMARCbis: The Solution the IETF Built

The IETF’s DMARC Working Group has developed DMARCbis (draft-ietf-dmarc-dmarcbis-41), the updated DMARC specification that directly addresses the subdomain spoofing vulnerability. DMARC.org’s official summary of changes confirms the key updates. The documents were submitted for publication in April 2025, and RFC publication is expected in 2026.

The np= Tag: Purpose-Built for Subdomain Spoofing

The most important change for subdomain spoofing defense is the new np= (non-existent subdomain policy) tag. As the IETF draft specifies: the np tag “indicates the message handling preference of the Domain Owner for mail using a non-existent subdomain of the prevailing Organizational Domain.”

This is the surgical fix the ecosystem needed. With np=reject, domain owners can specifically state: any email claiming to come from a subdomain that does not exist in our DNS should be rejected, regardless of any other policy considerations. The np tag gives separate control over non-existent subdomains (np=) versus existing subdomains (sp=) versus the root domain (p=), allowing granular policy management that the current specification lacks.

CaptainDNS’s comprehensive DMARCbis guide explains the policy fallback logic: when a DMARCbis-aware receiver gets an email from a subdomain, it first checks whether that subdomain exists in DNS. If it returns NXDOMAIN (does not exist), the np policy applies. If np is not defined, the receiver falls back to sp. If sp is not defined either, p applies. For existing subdomains, the fallback remains sp then p.

The DNS Tree Walk: Replacing the Public Suffix List

The second major change addresses another systemic weakness. Under the current DMARC specification, determining the “organizational domain” (the domain responsible for policy) requires consulting the Public Suffix List (PSL), an externally maintained, manually updated list managed by Mozilla. This dependency creates update delays, accuracy issues, and a single point of failure.

DMARCbis replaces the PSL with a DNS Tree Walk algorithm. When a receiving server needs to find the DMARC policy for a subdomain, it walks up the DNS hierarchy one label at a time, querying for _dmarc records at each level until it finds one. The IETF draft specifies an 8-query maximum to ensure bounded processing time. CaptainDNS notes that in practice, this adds only 1-2 additional DNS queries for a typical 3-label domain, with DNS caching mitigating the performance impact.

Other Key Changes

EasyDMARC’s analysis and PowerDMARC’s guide summarize the additional changes: the pct= tag (percentage-based enforcement) is replaced by a simpler t= (testing) binary flag, eliminating the confusion around partial enforcement that left many organizations in an ambiguous state. The ri= (reporting interval) and rf= (reporting format) tags are deprecated and moved to separate reporting documents. The specification is elevated from Informational status to Proposed Standard, signaling formal IETF endorsement. And critically, existing v=DMARC1 records remain valid, there is no forced migration or version number change.

Change	Current DMARC	DMARCbis
Non-existent subdomain policy	No specific tag; relies on sp= or p= fallback (inconsistent handling)	np= tag: explicit policy for fabricated subdomains
Organizational domain discovery	Public Suffix List (externally maintained)	DNS Tree Walk algorithm (self-contained, max 8 queries)
Testing/enforcement	pct= tag (confusing percentage-based partial enforcement)	t= tag (simple binary: testing or enforcing)
IETF status	Informational (RFC 7489)	Proposed Standard (formal endorsement)
Deprecated tags	pct=, rf=, ri= in main record	Removed from main record; reporting tags moved to separate documents
Record version	v=DMARC1	v=DMARC1 (unchanged; backward compatible)
New tags added	None	np=, psd=, t=

What to Do Now: Preparing for DMARCbis

DMARCbis is expected to be published in 2026, but only United Internet AG (GMX, mail.com, WEB.DE) currently emits reports in DMARCbis format. Major providers like Google and Microsoft have not yet announced implementation timelines. That said, preparing your DMARC posture now positions you ahead of the curve.

Step 1: Audit Your Current Subdomain Coverage

Check your existing DMARC record for the sp= tag. If it is absent, your subdomain policy defaults to whatever your p= tag says. Explicitly set sp=reject if you want all subdomain email to be rejected unless authenticated. This provides the best protection available under the current specification.

Step 2: Inventory All Legitimate Subdomains

Use your DMARC report analyzer to identify every subdomain that legitimately sends email. These might include subdomains for marketing (em.yourdomain.com), transactional email (mail.yourdomain.com), or regional operations (eu.yourdomain.com). Each legitimate sending subdomain needs its own SPF and DKIM configuration, and ideally its own DMARC record.

Step 3: Publish DMARC Records for Key Subdomains

For your most important sending subdomains, publish explicit DMARC records at the subdomain level. This ensures that receiving servers find a policy without needing to walk up to the parent domain, providing the most reliable protection regardless of how individual receivers handle subdomain policy lookup.

Step 4: When DMARCbis Is Published, Add the np= Tag

Once DMARCbis is officially published and receivers begin supporting it, add np=reject to your root domain’s DMARC record. This explicitly instructs all supporting receivers to reject email from any subdomain that does not exist in your DNS, closing the fabricated subdomain gap permanently. Since existing records remain valid, this is a simple addition, not a migration.

Step 5: Remove Deprecated Tags

As part of your DMARCbis preparation, remove deprecated tags (pct=, ri=, rf=) from your DMARC record. Replace pct= with the new t= tag if you need testing mode. This cleanup ensures your record is clean and forward-compatible.

The readiness advantage: Organizations that prepare their subdomain posture now will be ready to adopt the np= tag the moment DMARCbis is published. A DMARC report analyzer provides the subdomain visibility and sender inventory needed to confidently set sp=reject today and np=reject tomorrow, without risking legitimate subdomain email.

The Bottom Line: The Next Chapter of DMARC Is About Subdomains

DMARC’s first decade was about getting organizations to authenticate their root domains. The next chapter is about closing the subdomain gap that attackers have already learned to exploit.

The vulnerability is real and documented in peer-reviewed academic research (PDF). The exploitation is active, with 89% of BEC attacks impersonating authority figures and CEO fraud targeting 400 companies per day. The financial impact is measured in billions: $51 billion in exposed BEC losses historically, with attack volume surging 103% in 2024 alone.

The solution is coming. DMARCbis introduces the np= tag, purpose-built for non-existent subdomain policy, along with the DNS Tree Walk that eliminates the Public Suffix List dependency. The specification was submitted for publication in April 2025 and is expected to become an official IETF Proposed Standard in 2026.

Organizations that prepare now, by auditing subdomain coverage, setting sp=reject, and inventorying all legitimate subdomain senders through a DMARC report analyzer, will be ready to adopt np=reject the moment DMARCbis goes live. Those that wait will continue to leave a gap that attackers are already exploiting.

Your root domain may be at p=reject. But if your subdomains are unprotected, your DMARC enforcement has a hole in it. DMARCbis is how the industry closes that hole. A DMARC report analyzer is how your organization prepares for it today.