What is DMARCbis and Why Does It Matter?

DMARCbis is the next-generation DMARC – a restructured and improved update to the DMARC protocol that was first introduced in 2015. Unlike the original DMARC (which was published as an Informational RFC), DMARCbis is on track to become a formal IETF Proposed Standard in 2025. This elevation in status signals broad industry consensus and incorporates lessons learned from a decade of DMARC implementations. In practice, DMARCbis is not a radical departure from DMARC, but it brings important enhancements in clarity, security, and flexibility to make the protocol more robust and future-proof.

Key Improvements in DMARCbis (vs. Original DMARC)

DMARCbis builds on years of real-world experience with DMARC. Some of the most notable updates and improvements include:

  • Refined Organizational Domain Discovery (DNS Tree Walk): The new specification replaces reliance on the Public Suffix List (PSL) with a “DNS Tree Walk” algorithm for determining a domain’s organizational domain. This means that instead of using a static list of public suffixes, mail receivers will perform DNS queries up the domain hierarchy to find the applicable DMARC policy. This Tree Walk method makes alignment checks more dependable across complex domain structures (e.g. multi-level subdomains or delegated domains) and lets domain owners’ control which domain is treated as the organizational root in DMARC. It eliminates inconsistencies caused by different PSL versions and improves interoperability by using DNS itself to discover policy boundaries.

  • New "np" Tag for Subdomain Policies: DMARCbis introduces an np tag that allows domain owners to specify a policy for non-existent subdomains separately from existing subdomains or the parent domain. The np policy applies when someone tries to use a subdomain that your organization has not set up (e.g. a spoof like does-not-exist.yourdomain.com). This provides flexibility to harden or relax enforcement on phony subdomains without affecting email flows for legitimate subdomains. For example, an organization could set np=reject to block all emails purporting to come from any unused subdomain, reducing abuse, while using a different sp (subdomain policy) for real delegated subdomains. This finer control helps avoid both over-enforcement and under-protection in handling subdomain traffic.

  • Depreciantion of the "pct" (Percentage) Tag: In the original DMARC, the pct tag allowed domain owners to enforce their policy only partially (for example, pct=50 to only apply enforcement to half of failing messages). DMARCbis deprecates the pct tag, reflecting an expectation that domain owners should fully enforce their DMARC policy rather than applying it gradually or partially. In other words, once you move to an enforcement policy (quarantine or reject), you should implement it 100%. This change encourages a more decisive stance on email authentication and simplifies the protocol (mail receivers no longer need to handle percentage-based sampling of enforcement). For organizations, it means that when you are confident in your DMARC deployment, you will typically go straight to full enforcement. (Notably, DMARCbis introduces a new testing flag as an alternative – see the next point – rather than using percentages for slow rollout.)

  • "t" Testing Flag: To facilitate safe rollout and testing, DMARCbis adds a testing flag (t) that effectively replaces the old pct mechanism for test deployments. When t=y (testing mode) is set in a DMARC record, it signals to receivers that the domain is testing and requests that policy enforcement be treated as one level lower than specified. For example, if your DMARC record says p=reject but t=y (test mode), receivers may interpret this as “treat it like quarantine” (one step below reject) rather than full rejection. If p=quarantine and t=y, treat it as monitoring (none). This gives domain owners a way to trial an enforcement policy safely – ensuring reports still come in – without immediately impacting deliverability. The t tag is advisory (receivers can choose whether to honour it), but it provides a clearer testing mechanism than pct did. By default (t=n), the policy is fully applied (equivalent to pct=100).

  • Public Suffix Domain (PSD) Tag: Another new tag, psd, is introduced to explicitly mark records published on public suffix domains (like TLDs or registry-controlled domains) versus normal organizational domains. A DMARC record with psd=y tells receivers “This domain is a public suffix; don’t treat it as an org domain but rather as a boundary.” Conversely, psd=n indicates “this domain is definitely an organizational domain for itself and its subdomains.” This tag works together with the DNS Tree Walk algorithm to handle edge cases where a registry (or an organization acting like a registry) publishes a DMARC policy. For example, a country-code TLD or an industry association might publish a DMARC record at the PSD level to cover all subordinate domains – something original DMARC had limited support for. The PSD tag allows multi-level domain environments and registries to use DMARC more effectively by controlling how the tree walk identifies the org domain.

  • Clearer Specification and Guidance: The DMARCbis document has been restructured for clarity, with improved terminology and more examples for implementers. Ambiguities in the original spec have been addressed to reduce confusion. For instance, DMARCbis spells out exactly how policy inheritance works for subdomains and when to stop the tree walk, so all receivers implement it consistently. Additionally, DMARCbis splits the core protocol from reporting: new drafts dedicated to aggregate reporting and failure reporting accompany the main spec, ensuring each aspect is well-defined. Strategically, DMARCbis moving to a full standard track with a cleaner spec means email providers and organizations will have an easier time deploying and auditing DMARC, increasing adoption and interoperability. Importantly, the DMARC version tag remains “v=DMARC1” for backward compatibility – so existing DMARC records will not break. But over time, we can expect mailbox providers to align with the new spec, and domain owners should eventually update any records or practices that the old spec allowed but DMARCbis discourages (such as using pct). Overall, DMARCbis offers more flexibility, accuracy, and guidance to make email authentication stronger and more effective.

DMARCbis vs. SPF and DKIM: How Do They Compare?

SPF, DKIM, and DMARC are complementary pieces of the email authentication puzzle, each serving a distinct purpose:

  • SPF (Sender Policy Framework): SPF allows a domain owner to publish a DNS record listing which mail servers are authorized to send email on behalf of their domain. When an inbound email server receives a message claiming to be from @yourdomain.com, it can check the SPF record for yourdomain.com to see if the sending server’s IP is on the approved list. SPF is effective at addressing the “who can send” question by verifying the sender’s IP against the domain’s policy. However, SPF has limitations: it checks the envelope sender (MAIL FROM) domain, which might be different from the header “From:” domain that users see, and it does not inherently tie that result to the visible sender. Additionally, if an email is forwarded through an intermediary, SPF can break (since the forwarder’s IP might not be in the original sender’s SPF list).

  • DKIM (DomainKeys Identified Mail): DKIM addresses the content integrity and domain authorization by having the sending mail server attach a digital signature to email headers. The signature is linked to a domain via a cryptographic key published in DNS. The receiving server retrieves the sender’s public key from DNS and verifies the signature, ensuring the message has not been tampered with and confirming it was indeed signed by the claimed domain. DKIM is powerful because the signature survives forwarding (the content and signature remain intact), but DKIM alone does not guarantee that the signing domain is the same as the From domain – a sender could sign with one domain’s keys while the email claims to be from another domain, which might confuse recipients.

  • DMARC: DMARC’s role is to tie SPF and DKIM results to the domain that matters to the recipient – the address in the “From:” header – and to specify a policy for handling failures. In simpler terms, DMARC sits on top of SPF and DKIM and asks: “Did the email actually come from the domain it says it’s from?” It does this by requiring identifier alignment – the domain in the From: address must match (or be a subdomain of) the domain that passed SPF or the domain that signed the DKIM signature. If neither SPF nor DKIM pass with alignment, DMARC considers the email unauthenticated. The domain owner can tell receivers what to do with such failed messages (monitor them, quarantine them as suspicious, or reject them outright) via the DMARC policy (p=none/quarantine/reject). This is something neither SPF nor DKIM provides on their own – they do not convey sender policy to the receiver. Moreover, DMARC provides feedback to domain owners: aggregate reports (summary of authentication results) and optional forensic reports. These allow organizations to monitor who is sending email purporting to be from their domain and to spot abuse or misconfigurations. In short, SPF checks the server, DKIM checks the content, and DMARC checks the domain identity and policy. Together, these three form a layered defence against spoofing and phishing.

  • DMARCbis and the Ecosystem: It is important to note that DMARCbis does not replace SPF or DKIM – it still relies on them as underlying authentication mechanisms. The core logic of “an email passes DMARC if it passes SPF or DKIM (or both) and the domain aligns” remains the same in DMARCbis. So, from a technical standpoint, DMARCbis is backward-compatible with how emails are authenticated; any email that passed DMARC under the old spec will also pass under DMARCbis (the criteria for SPF/DKIM alignment have not fundamentally changed). What DMARCbis improves is the reliability and consistency of determining which domain to check alignment against. For example, under the old DMARC, different receivers might have slightly different interpretations of organizational domains in exotic cases (due to PSL variations). DMARCbis standardizes this via the tree walk and psd tags, meaning SPF and DKIM results are evaluated against the correct organizational domain more consistently across the board. This consistency strengthens the effectiveness of SPF/DKIM by ensuring DMARC is checking the intended domain.

In practice, organizations should continue to implement SPF and DKIM for all their sending domains – these are prerequisites for DMARC (including DMARCbis) to function. DMARCbis will make it easier to manage and enforce policies on those domains, especially if you have complex domain structures or use third-party senders. Another point to consider is email forwarding: while DMARCbis improves many aspects of DMARC, it does not directly solve the problem of legitimate forwarders breaking SPF or DKIM. Solutions like ARC (Authenticated Received Chain) remain complementary for preserving authentication through forwarding. Nonetheless, DMARCbis ensures that as long as a message can authenticate via SPF or DKIM, it will be correctly aligned and handled according to the domain’s policy – giving domain owners and receivers a clear, unified way to enforce email authenticity that SPF or DKIM alone could not achieve.

Implications of DMARCbis for Businesses (Security, Compliance, and Enforcement)

From a business perspective, DMARCbis is more than just a technical update; it carries strategic implications for email security, compliance, interoperability, and policy enforcement. Organisations – from enterprises to small businesses – that rely on email for communication or marketing should understand these implications:

  • Stronger Security & Brand Protection: The enhancements in DMARCbis directly contribute to stronger defences against spoofing, phishing, and business email compromise. By refining domain alignment and closing loopholes (like attacks via look-alike subdomains), DMARCbis helps ensure that only authorized senders can use your domain. This protects your customers, partners, and employees from phishing emails that pretend to be from your company. A successful DMARC (or DMARCbis) implementation protects your brand’s reputation by preventing attackers from misusing your domain in frauds. The DMARCbis updates are explicitly designed to strengthen protection against spoofing and phishing, which in turn boosts customer trust in the emails they receive from you. Many industry initiatives also tie into DMARC enforcement – for example, to display verified logos with BIMI, you must have a fully enforced DMARC policy. Embracing DMARCbis means your organization stays at the forefront of email security best practices, reducing risk and demonstrating to clients and partners that you take email security seriously.

  • Compliance and Regulatory Alignment: Email authentication is increasingly part of regulatory and industry compliance frameworks. In some regions and sectors, having DMARC in place (often at an enforcement policy) is encouraged or even mandated for certain organizations (for instance, U.S. federal agencies have been required to implement DMARC at p=reject). With DMARCbis poised to become an official Internet Standard, we can anticipate even stronger industry push for adoption. Companies that handle sensitive data or operate in finance, healthcare, or government supply chains may find that implementing DMARCbis is not just optional but a compliance expectation to meet cybersecurity guidelines. The good news is that DMARCbis makes it easier to be compliant: the clearer specification means fewer misconfigurations, and the ability to publish policies for subdomains (including “non-existent” ones via np) means you can cover all corners of your email domain space in a policy. This helps ensure no gaps that attackers could exploit. Furthermore, being on DMARCbis early positions your organization as “more compliant” and initiative-taking in the eyes of mailbox providers. Mail providers like Google and Microsoft highly value domains that authenticate and enforce DMARC; such emails are more likely to be delivered to the inbox. As the Excedo blog noted, organisations that take initiative on DMARCbis will be better protected, more compliant, and more trusted by mailbox providers and recipients alike. In summary, adopting DMARCbis is likely to become synonymous with following the highest standards in email security governance.

  • Interoperability & Deliverability Improvements: One practical implication of DMARCbis is improved interoperability in the email ecosystem. Under the old DMARC, different mail receivers might implement organizational domain identification slightly differently (since no single PSL was mandated), potentially leading to inconsistent enforcement. DMARCbis’s move to DNS-based discovery means every receiver will use the same method, which should result in uniform enforcement of your domain policy everywhere. For senders, that consistency is beneficial – you will not have providers failing to find your DMARC record due to an outdated PSL or unusual domain suffix. In addition, DMARCbis clarifies how subdomain policies inherit or override, so if you delegate a subdomain to a third-party mailing service and publish a policy for it, all receivers should respect it in a consistent way. All of this improves deliverability for legitimate email: when your emails are properly authenticated and aligned, they are less likely to be flagged as spam. Conversely, unauthorized emails are more reliably blocked. Businesses that implement DMARCbis can expect fewer false negatives and false positives in email filtering – meaning real emails get through, and fake emails get stopped, as intended. Interoperability also extends to how reports are handled; since DMARCbis provides stricter reporting formats and documentation organizations using DMARC monitoring tools should see more standardized reports from receivers, making analysis easier across different ISPs. In short, DMARCbis smooths out the rough edges of the protocol, making it easier for your email to work seamlessly across the global email network.

  • Policy Enforcement & Flexibility: DMARCbis strikes a balance between strict enforcement and flexibility, which has direct consequences for how businesses manage email policy. On one hand, the deprecation of pct and the philosophy behind DMARCbis encourage moving toward full enforcement (100% quarantine or reject) as the end goal, rather than indefinitely staying in “monitor mode.” This means that organizations should plan to eventually enforce DMARC on all mails – which is where the anti-spoofing benefits come. On the other hand, DMARCbis adds tools to get there safely and to fine-tune policies.

    The introduction of the t (testing) flag allows you to temporarily request downgraded enforcement, effectively letting you test a reject policy without fear of outright losing messages, which can be a relief for stakeholders worried about blocking something important. Similarly, the np tag and improved handling of subdomains give larger organizations more granular control: you might enforce reject on subdomains you never send from, while using a softer policy on a subdomain that is still in transition or used by a third party. This flexibility reduces the risk of “over-enforcement” (accidentally impacting legitimate mail flows) while still enabling strong security where it counts.

    Practically, businesses should review their domain architecture and sending streams: identify all domains and subdomains that send email (or could be abused if they do not) and decide how each should be governed under DMARCbis. With the new spec, you can publish DMARC records at multiple points in your domain hierarchy if needed (the tree walk will find the most relevant one).

    This could be useful for companies with decentralized email administration – for example, a multinational with country-specific subdomains can delegate DMARC control to each country’s IT, by leveraging the tree walk to have DMARC records on those subdomains marked as organizational (psd=n). In summary, DMARCbis will require some adaptation – removing deprecated tags from DNS, adjusting policies – but it gives security teams more confidence and control in enforcing email policy across the organization.

Future Trends and How to Prepare for DMARCbis

As of 2025, DMARCbis is on the cusp of becoming the new standard for email authentication. Looking ahead, several trends are emerging:

  • Wider Adoption and Enforcement: We can expect major email providers and security gateways to swiftly adopt the DMARCbis standard once it is finalized. Some receivers may already be testing the DNS Tree Walk approach in parallel with the PSL method to ensure a smooth transition. As the ecosystem adjusts, domain owners who have implemented DMARC will want to ensure their records remain effective under the new algorithm – which, in most cases, they will if you have a DMARC record on your organizational domain.

    One trend to watch is increasing enforcement by receivers: as DMARCbis clarifies things like what to do with subdomain spoofing, mailbox providers might become stricter about applying domain policies. This means if your policy is “reject,” receivers are likely to honour that decisively (especially with pct gone and testing mode explicitly signalled). Companies that have stayed at “p=none” (monitoring) will face greater pressure to move to enforcement to fully benefit from the standard. Additionally, industry initiatives (like BIMI for brand logos, email certification programs, etc.) will continue to require DMARC at enforcement – so having DMARCbis with a quarantine/reject policy becomes not just a security measure but a business advantage for marketing and brand visibility.

  • Evolution of Email Security Standards: DMARCbis is part of a broader movement to shore up email’s decades-old protocols. Alongside DMARCbis, the IETF DMARC working group has also been updating the reporting formats (aggregate and forensic) and encouraging adoption of related standards like MTA-STS (for encrypted transport) and BIMI. In the future, we might see tighter integration between these standards – for example, senders with strong DMARC enforcement might get favourable treatment in spam filtering algorithms, or receivers might share more data back to senders for threat intelligence.

    Another likely trend is more automation and tools to manage email authentication. As the complexity grows (with new tags and considerations in DMARCbis), organizations will lean on dashboards and services to monitor DMARC compliance. Many vendors are already updating their platforms to support DMARCbis tags like psd and np and to simulate the tree walk for your domains. Over time, DMARCbis could also pave the way for future protocol enhancements – for instance, if the industry finds a better way to handle forwarded email or identity verification, it will build on the solid foundation that DMARCbis establishes (with clear domain alignment rules).

  • Increased Stakeholder Awareness: Ten years ago, few outside of email administrators knew about SPF/DKIM/DMARC. Today, with phishing and ransomware in headlines, even top executives and boards are aware of the need for email authentication. The rollout of DMARCbis is an opportunity for CISOs and IT leaders to educate stakeholders about email security. We anticipate more guidance from organizations like NIST, CIS, and other cybersecurity standards bodies to include updated recommendations for DMARCbis.

    Businesses should be ready to answer questions like “Are we protected from spoofed emails? Have we implemented the latest standard?” Being an early adopter of DMARCbis can be a selling point to customers and partners, showing that your organization stays ahead of threats. In some cases, it might even become a competitive differentiator or a requirement in B2B contracts (for example, a partner might mandate that you authenticate emails to them via DMARC). Thus, the trend is toward making email authentication a baseline expectation in doing business, much like HTTPS became a baseline for websites.

How should your organization prepare for DMARCbis? Here are some actionable steps to ensure a smooth transition:

  1. Audit Your Current DMARC Records: Review the DMARC DNS records for all domains and subdomains you own. Remove or avoid any soon-to-be-deprecated tags. For example, if your record includes pct= or the reporting tags ri= or rf=, plan to remove those values (they will be ignored under DMARCbis). Ensure that your organizational domain (e.g., yourdomain.com) has a DMARC record in place with an appropriate policy, as this is the primary record DMARCbis will look for in a tree walk. If you relied on subdomain wildcarding or implicit coverage, consider adding explicit records or sp/np policies as needed.

  2. Understand Your Domain Hierarchy: Map out which subdomains send email and which do not. With DMARCbis’s new algorithm, you could publish DMARC at multiple levels. Use this to your advantage. For complex setups, simulate the DNS Tree Walk logic (many DMARC analysers or tools can do this) to verify which DMARC policy would apply to emails from each of your subdomains. If you find the outcome is not what you want, you can adjust by adding a DMARC record at a higher-level subdomain or using the psd tag to mark organizational boundaries. For instance, if mail.department.company.com is managed by a separate team, you could publish a DMARC record at _dmarc.department.company.com with psd=n to let them control everything under that node independently. Such planning ensures DMARCbis works with your organisation’s structure rather than against it.

  3. Leverage the New Tags Thoughtfully: While you do not have to use the new tags, they can be extremely useful. Evaluate if the np tag makes sense for you – many organizations will set np=reject on their top-level domains DMARC record to definitively block abuse of non-existent subdomains (a common phishing tactic). Consider using the t=y testing flag when you first move from monitoring to an enforcement policy, so you can gauge impact. Keep in mind that not all receivers may honour t=y, but major ones will treat it as advisory. Using psd=y is rare (only if you operate a public suffix like a registry or umbrella org), but if you do control something like a country TLD or an ISP’s customer domain space, look into publishing a DMARC record with psd=y to help protect all under it. Document any changes you make for DMARCbis so that your team and successors know why those tags are there.

  4. Monitor Reports and Adjust: Continue (or start) collecting DMARC aggregate reports (rua) and review them regularly. With DMARCbis, aggregate reports will indicate if the new tree walk was used or if any policies were in “test mode.” This information can help you fine-tune your implementation. For example, if you set np=reject and then see in reports that legitimate sources were using a misconfigured subdomain (one you thought was non-existent), you can act to properly configure that subdomain or give it an exception. Similarly, watch for any anomalies once receivers start adopting DMARCbis – the reports might reveal that a DMARC record higher up in your domain tree is unintentionally overriding what you expected. Early monitoring will catch these issues. In failure/forensic reports (ruf), DMARCbis has its own draft standard; if you use these, ensure your addresses and systems are ready to handle slightly updated formats. Overall, reporting remains your radar to detect both abuse and any implementation bugs, so do not set and forget your DMARC – especially during the transition period.

  5. Educate and Communicate: Finally, prepare your people and processes. Make sure your email administrators, IT security staff, and incident responders know about DMARCbis and its changes. Update your email security policy documentation to reflect the new tags and behaviours. If you use third-party email senders (e.g., marketing platforms, SaaS services that send emails on your domain’s behalf), reach out to them to confirm they are aligned with DMARC (they should be signing with DKIM and routing through authorized servers). Let them know you plan to enforce DMARC (if not already) and ensure they can work under that regime. Internally, communicate to leadership that adopting DMARCbis is part of continual improvement of security – it is mostly behind-the-scenes work, but it significantly reduces risk. In the event that DMARC (or its absence) has ever caused an email deliverability issue in your org, use the DMARCbis rollout as a chance to address those (for instance, maybe a department’s emails were failing DMARC due to misalignment; fixable now with better guidance). By being initiative-taking and treating DMARCbis adoption as a project, you will avoid scrambling later if a partner or regulation suddenly requires it.

Conclusion: Embracing the DMARCbis Era

DMARCbis represents the future of email authentication – a future where domain owners have more control and attackers have fewer places to hide. This updated protocol takes a successful, battle-tested standard (DMARC) and refines it to address the challenges and ambiguities that have surfaced over years of fighting phishing. For organizations, the message is clear: now is the time to get your email authentication house in order. If your DMARC implementation has been on “training wheels” (pct<100 or no enforcement), start moving toward full deployment, using DMARCbis’s testing features as needed. If you have not deployed DMARC at all, the advent of DMARCbis is the perfect catalyst to do so – it is easier than ever to implement correctly with the improved documentation, and the imperative to protect your domain from abuse has never been greater.

The benefits of adopting DMARCbis go beyond just stopping spoofed emails. You will be improving your email deliverability, protecting customers, complying with emerging standards, and safeguarding your brand’s reputation. Given the ever-increasing sophistication of phishing attacks, no organization can afford to ignore email authentication. DMARCbis is a powerful tool in your arsenal, one that comes with the weight of industry consensus and technical rigor behind it.

In summary, DMARCbis is coming fast, and organizations that take initiative-taking steps now will be ahead of the curve – better protected, more compliant, and more trusted by mailbox providers and recipients alike. The transition is not onerous, but it does require attention and planning. By reviewing your policies, updating your DNS records, and educating your team, you can smoothly embrace DMARCbis and continue to secure your email channel against abuse. Email security is a journey, not a one-time fix – and DMARCbis is the next milestone on that journey. Do not wait start preparing for DMARCbis today so that when it becomes the industry default, your organization will already be reaping the rewards of a safer, more reliable email ecosystem.

Ready to strengthen your email defences? Take this opportunity to audit your email authentication now – the future of DMARC is here, and it is an upgrade you will not want to miss, book a free consultation with our DMARC experts.