--- title: "Subdomain Spoofing: The DMARC Vulnerability That DMARCbis Was Built to Fix | DMARC Report" description: "The Attack That p=reject Cannot Stop You have done everything right. You published a DMARC record on your root domain." image: "https://dmarcreport.com/og/blog/subdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix.png" canonical: "https://dmarcreport.com/blog/subdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix/" --- Quick Answer 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. Related: [Free DMARC Checker](/tools/dmarc-checker/) Share [ ](https://www.linkedin.com/sharing/share-offsite/?url=undefined%2Fblog%2Fsubdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix%2F "Share on LinkedIn") [ ](https://twitter.com/intent/tweet?text=Subdomain%20Spoofing%3A%20The%20DMARC%20Vulnerability%20That%20DMARCbis%20Was%20Built%20to%20Fix&url=undefined%2Fblog%2Fsubdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix%2F "Share on X/Twitter") [ ](https://www.facebook.com/sharer/sharer.php?u=undefined%2Fblog%2Fsubdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix%2F "Share on Facebook") [ ](https://reddit.com/submit?url=undefined%2Fblog%2Fsubdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix%2F&title=Subdomain%20Spoofing%3A%20The%20DMARC%20Vulnerability%20That%20DMARCbis%20Was%20Built%20to%20Fix "Share on Reddit") [ ](mailto:?subject=Subdomain%20Spoofing%3A%20The%20DMARC%20Vulnerability%20That%20DMARCbis%20Was%20Built%20to%20Fix&body=Check out this article: undefined%2Fblog%2Fsubdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix%2F "Share via Email") ## Try Our Free DMARC Checker Validate your DMARC policy, check alignment settings, and verify reporting configuration. [ Check DMARC Record → ](/tools/dmarc-checker/) ## 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](https://mkorczynski.com/TMA2020Maroofi.pdf) (PDF) demonstrated this vulnerability in their peer-reviewed research: “If there is no wildcard [TXT record](/blog/how-to-create-a-txt-record-and-add-it-to-dns/) 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](/blog/dmarc-enforcement-timeline-none-to-reject-roadmap/) 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](https://www.usenix.org/system/files/sec21summer%5Fshen-kaiwen.pdf) (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. ![NXDOMAIN Vulnerability Flowchart](https://media.mailhop.org/dmarcreport/images/2026/05/dmarc-check-6301.jpg) ### Why Non-Existent Subdomains Are Especially Dangerous Non-existent subdomains present a unique challenge. The [Grenoble-Twente academic research](https://mkorczynski.com/TNSM2021.pdf) (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](/blog/what-is-a-dmarc-policy-and-how-does-it-affect-sending-my-emails/). 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](https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-41) 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](https://media.mailhop.org/dmarcreport/images/2026/05/dmarc-check-6302.jpg) ## 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](https://www.mondaq.com/unitedstates/cybersecurity/1780314/cyber-security-and-operational-resilience-for-family-offices-video). [Keepnet Labs reports](https://keepnetlabs.com/blog/ceo-fraud) 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](https://keepnetlabs.com/blog/ceo-fraud) shows $51 billion in exposed losses due to BEC fraud historically, with BEC attack volume surging 103% in 2024\. [Vectra AI’s analysis](https://www.vectra.ai/topics/whaling-attack) 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](mailto:ceo@accounting.yourdomain.com) is nearly as convincing as one from [ceo@yourdomain.com](mailto: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](https://www.vectra.ai/topics/whaling-attack) 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](https://www.adaptivesecurity.com/blog/ceo-fraud) lost $37 million in 2019 to BEC fraudsters impersonating executives. The [Italian Defense Minister deepfake voice cloning](https://www.vectra.ai/topics/whaling-attack) 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._ ![DNS Tree Walk Diagram](https://media.mailhop.org/dmarcreport/images/2026/05/dmarc-check-6303.jpg) ## DMARCbis: The Solution the IETF Built The IETF’s DMARC Working Group has developed [DMARCbis (draft-ietf-dmarc-dmarcbis-41)](https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-41), the updated DMARC specification that directly addresses the subdomain spoofing vulnerability. [DMARC.org’s official summary of changes](https://dmarc.org/2025/12/summary-of-changes-in-dmarcbis/) confirms the key updates. The documents were [submitted for publication in April 2025](https://dmarcwise.io/blog/upcoming-dmarc-bis), 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](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/): 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](https://www.captaindns.com/en/blog/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](https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-41) an 8-query maximum to ensure **bounded processing time**. [CaptainDNS notes](https://www.captaindns.com/en/blog/dmarcbis-guide) 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](https://easydmarc.com/blog/what-is-dmarcbis/) and [PowerDMARC’s guide](https://powerdmarc.com/dmarcbis-explained/) 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](https://www.captaindns.com/en/blog/dmarcbis-guide). 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](/dmarc-fundamentals/what-is-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._ ![DMARCbis Subdomain Security Infographic](https://media.mailhop.org/dmarcreport/images/2026/05/dmarc-info-0478.jpg) ## The Bottom Line: The Next Chapter of DMARC Is About Subdomains DMARC’s first decade was about getting organizations to authenticate their [root domains](https://zutrix.com/blog/what-is-a-root-domain/). 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](https://mkorczynski.com/TMA2020Maroofi.pdf) (PDF). The exploitation is active, with [89% of BEC attacks impersonating authority figures](https://keepnetlabs.com/blog/ceo-fraud) and CEO fraud targeting 400 companies per day. The financial impact is measured in billions: [$51 billion in exposed BEC losses historically](https://keepnetlabs.com/blog/ceo-fraud), 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](https://dmarcwise.io/blog/upcoming-dmarc-bis) 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.** ## References and Sources _All sources referenced, with full URLs:_ **1.** [IETF DMARCbis Draft (draft-ietf-dmarc-dmarcbis-41)](https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-41) **2.** [IETF DMARCbis Overview Page](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/) **3.** [DMARC.org: Summary of Changes in DMARCbis](https://dmarc.org/2025/12/summary-of-changes-in-dmarcbis/) **4.** [Maroofi et al.: Evaluation of Email Anti-Spoofing Schemes (TMA 2020, PDF)](https://mkorczynski.com/TMA2020Maroofi.pdf) **5.** [Maroofi et al.: Adoption of Email Anti-Spoofing (IEEE TNSM 2021, PDF)](https://mkorczynski.com/TNSM2021.pdf) **6.** [Shen et al.: Weak Links in Authentication Chains (USENIX Security 2021, PDF)](https://www.usenix.org/system/files/sec21summer%5Fshen-kaiwen.pdf) **7.** [Hu et al.: End-to-End Measurements of Email Spoofing (USENIX Security 2018, PDF)](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf) **8.** [FBI/NSA: North Korean DMARC Exploitation Advisory (PDF)](https://www.ic3.gov/CSA/2024/240502.pdf) **9.** [DMARCwise: DMARCbis Is Around the Corner](https://dmarcwise.io/blog/upcoming-dmarc-bis) **10.** [CaptainDNS: DMARCbis Complete Guide, Migration and DNS Tree Walk](https://www.captaindns.com/en/blog/dmarcbis-guide) **11.** [EasyDMARC: What Is DMARCbis?](https://easydmarc.com/blog/what-is-dmarcbis/) **12.** [PowerDMARC: DMARCbis Explained](https://powerdmarc.com/dmarcbis-explained/) **13.** [Security Boulevard: DMARCbis Key Changes](https://securityboulevard.com/2025/05/dmarcbis-explained-whats-changing-and-how-to-prepare/) **14.** [DMARC Advisor: Understanding DMARCbis](https://dmarcadvisor.com/understanding-dmarcbis/) **15.** [IRONSCALES: What Is DMARC 2.0 (DMARCbis)?](https://ironscales.com/glossary/what-is-dmarc-2.0-dmarcbis) **16.** [Keepnet Labs: CEO Fraud Prevention (89%, 400/day, $51B)](https://keepnetlabs.com/blog/ceo-fraud) **17.** [Vectra AI: Whaling Attacks ($25.6M Arup, Italy deepfake)](https://www.vectra.ai/topics/whaling-attack) **18.** [Adaptive Security: CEO Fraud (Toyota $37M)](https://www.adaptivesecurity.com/blog/ceo-fraud) **19.** [AutoSPF: Impersonation Leading Phishing Strategy 2024](https://autospf.com/blog/impersonation-is-the-leading-phishing-strategy-of-2024/) **20.** [Valimail: Essential Guide to BEC Attacks](https://www.valimail.com/blog/essential-guide-to-bec-attacks/) **21.** [DeepStrike: Deepfake Statistics 2025](https://deepstrike.io/blog/deepfake-statistics-2025) ## Topics [ dkim ](/tags/dkim/)[ DMARC ](/tags/dmarc/)[ dns record ](/tags/dns-record/)[ email security ](/tags/email-security/) ![Brad Slavin](https://media.mailhop.org/dmarcreport/images/team/brad-slavin.jpg) [ Brad Slavin ](/authors/brad-slavin/) General Manager Founder and General Manager of DuoCircle. Product strategy and commercial lead for DMARC Report's 2,000+ customer base. [LinkedIn Profile →](https://www.linkedin.com/in/bradslavin) ## Take control of your DMARC reports Turn raw XML into actionable dashboards. Start free - no credit card required. [Start Free Trial](https://app.dmarcreport.com/) [Check Your DMARC Record](/tools/dmarc-checker/) ## Related Articles [ Uncategorized 8m Best DMARC Tools for 2025 Oct 9, 2025 ](/blog/best-dmarc-tools-for-2025/)[ Uncategorized 11m Complete Guide to Setting Up a DMARC Policy for Gmail Domains Mar 16, 2026 ](/blog/complete-guide-to-setting-dmarc-policy-for-gmail-domains/)[ Uncategorized 12m Comprehensive Guide To DMARC Monitoring Services For Msps And Service Providers Aug 26, 2025 ](/blog/comprehensive-guide-to-dmarc-monitoring-for-msps-and-service-providers/)[ Uncategorized 6m Email authentication: Why it matters and how SPF, DKIM, and DMARC ensure security Nov 5, 2024 ](/blog/email-authentication-why-it-matters-and-how-spf-dkim-and-dmarc-ensure-security/) ```json {"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"470","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]} ``` ```json {"@context":"https://schema.org","@type":"WebSite","name":"DMARC Report","url":"https://dmarcreport.com","description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","publisher":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}} ``` ```json [{"@context":"https://schema.org","@type":"BlogPosting","headline":"Subdomain Spoofing: The DMARC Vulnerability That DMARCbis Was Built to Fix","description":"The Attack That p=reject Cannot Stop You have done everything right. You published a DMARC record on your root domain.","url":"https://dmarcreport.com/blog/subdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix/","datePublished":"2026-05-06T16:44:17.000Z","dateModified":"2026-05-06T16:44:20.000Z","dateCreated":"2026-05-06T16:44:17.000Z","author":{"@type":"Person","@id":"https://dmarcreport.com/authors/brad-slavin/#person","name":"Brad Slavin","url":"https://dmarcreport.com/authors/brad-slavin/","jobTitle":"General Manager","description":"Brad Slavin is the founder and General Manager of DuoCircle, the company behind DMARC Report, AutoSPF, Phish Protection, and Mailhop. He founded DuoCircle in 2014 and has led the company's growth to 2,000+ customers across its email security product family. Brad's focus is product strategy, customer relationships, and the commercial and compliance side of email authentication (DPAs, SLAs, enterprise procurement).","image":"https://media.mailhop.org/dmarcreport/images/team/brad-slavin.jpg","knowsAbout":["Email Security Strategy","SaaS Product Management","Enterprise Compliance","Customer Success","Email Deliverability Business"],"worksFor":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com"},"sameAs":["https://www.linkedin.com/in/bradslavin"]},"publisher":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"470","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]},"mainEntityOfPage":{"@type":"WebPage","@id":"https://dmarcreport.com/blog/subdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix/"},"articleSection":"uncategorized","keywords":"dkim, DMARC, dns record, email security","wordCount":2435,"speakable":{"@type":"SpeakableSpecification","cssSelector":[".answer-block","h1"]}}] ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://dmarcreport.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://dmarcreport.com/blog/"},{"@type":"ListItem","position":3,"name":"Uncategorized","item":"https://dmarcreport.com/uncategorized/"},{"@type":"ListItem","position":4,"name":"Subdomain Spoofing: The DMARC Vulnerability That DMARCbis Was Built to Fix","item":"https://dmarcreport.com/blog/subdomain-spoofing-dmarc-vulnerability-that-dmarcbis-was-built-to-fix/"}]} ```