What is DMARC 2.0 (DMARCbis)?

DMARC 2.0, officially known as DMARCbis (pronounced "dee-mark-biss"), is the next generation of the Domain-based Message Authentication, Reporting, and Conformance protocol.

This enhanced email authentication standard builds upon the foundation of DMARC 1.0 while addressing critical limitations discovered through a decade of real-world deployment. DMARCbis keeps v=DMARC1, replaces Public Suffix List lookups with a DNS Tree Walk algorithm, and updates tags (adds psd, np, t; retires pct, rf, ri).

The Internet Engineering Task Force (IETF) developed DMARC 2.0 to solve persistent challenges organizations face with domain spoofing, phishing attacks, and complex email authentication scenarios. While maintaining full backward compatibility with existing DMARC implementations, DMARCbis provides more granular control over email authentication policies and eliminates dependencies on external resources like the Public Suffix List. The specification is approved by the IESG and awaiting publication pending the failure-reporting companion draft.

The Evolution from DMARC 1.0 to DMARC 2.0

DMARC 1.0, published as RFC 7489 in 2015, revolutionized email authentication by combining SPF and DKIM with policy enforcement and reporting mechanisms. However, after years of deployment across millions of domains, several limitations became apparent:

• Public Suffix List Dependency: DMARC 1.0 relied on an external, manually maintained list to determine organizational boundaries, creating update delays and accuracy issues
• Subdomain Spoofing Vulnerabilities: Limited control over non-existent subdomain policies allowed attackers to exploit fake subdomains like ceo.example.com
• Confusing Testing Mechanisms: The percentage-based pct tag created ambiguity about which messages received policy enforcement
• Inconsistent Implementation: Varied interpretations of specifications led to unpredictable behavior across email providers

DMARC 2.0 addresses these challenges through architectural improvements and clarified specifications, elevating the protocol from Informational to Proposed Standard status within the IETF framework. When published, it will obsolete RFC 7489 and RFC 9091.

How DMARC 2.0 Works

DMARCbis operates through the same fundamental authentication process as DMARC 1.0 but with enhanced mechanisms for policy discovery and enforcement:

1. DNS Tree Walk Discovery

When an email arrives, the receiving server performs a hierarchical DNS query starting from the exact sending domain and walking up the tree:

• Queries begin at the full domain (e.g., marketing.newsletters.example.com)
• Progressively moves up one label at a time
• Stops when finding a DMARC record with boundary markers
• Maximum of 8 queries prevents DNS amplification attacks

2. Enhanced Policy Evaluation

DMARCbis evaluates messages using improved policy tags:

• Standard policies: p (domain) and sp (subdomain) remain unchanged
• New np tag: Defines specific policies for non-existent subdomains
• New t tag: Binary testing signal
• New psd tag: Marks domain boundaries for the Tree Walk algorithm

3. Alignment and Authentication

The protocol maintains SPF and DKIM alignment requirements while adding:

• Explicit conformance requirements for domain owners
• Clearer guidance on alignment modes (strict vs. relaxed)
• Interoperability with ARC (RFC 8617) for forwarding scenarios

4. Reporting Improvements

DMARCbis streamlines reporting with:

• Aggregate reporting specified in a separate draft
• Removal of ri and rf from policy records
• Most providers send daily aggregate reports in practice
• Clearer forensic reporting specifications (pending final resolution)

Key Improvements in DMARCbis

Revolutionary DNS Tree Walk Algorithm

The DNS Tree Walk represents DMARCbis's most transformative improvement, replacing the Public Suffix List with a dynamic, DNS-based discovery mechanism. This algorithm:

• Replaces PSL reliance and obsoletes RFC 9091
• Provides real-time organizational boundary detection
• Reduces maintenance overhead for domain administrators
• May have interoperability differences vs. legacy PSL implementations during migration

Enhanced Subdomain Protection

The new np (non-existent subdomain) tag specifically addresses CEO fraud and subdomain spoofing attacks. It applies only to non-existent subdomains:

• np=reject: Blocks all emails from non-existent subdomains
• np=quarantine: Sends suspicious subdomain emails to spam
• np=none: Monitors but doesn't block (useful during initial deployment)

This feature prevents attackers from exploiting fake subdomains that return NXDOMAIN responses, a common vector for targeted spear-phishing campaigns.

Simplified Testing and Deployment

The new t tag provides a binary testing signal, while pct is marked historic:

• Clear testing mode: Binary signal for testing vs. production
• No percentage ambiguity: Removes confusion about partial enforcement
• Easier troubleshooting: Administrators know exactly which mode is active

Explicit Domain Boundaries

The psd tag lets Public Suffix Operators and domain owners mark boundaries:

• psd=y: Marks Public Suffix Domains (like .com or .co.uk)
• psd=n: Indicates organizational boundaries
• If absent, Tree Walk proceeds normally

DNS Tree Walk Algorithm Explained

The DNS Tree Walk algorithm fundamentally changes how DMARC records are discovered, providing a more flexible and accurate method for determining organizational boundaries:

How It Works

1. Initial Query: Starts at the exact domain from the email's From: header
2. Progressive Traversal: Moves up one domain label at a time
3. Boundary Detection: Looks for DMARC records with psd tags
4. Query Limits: Maximum 8 queries prevents abuse
5. Fallback Mechanism: Returns to parent domain if no record found

1. _dmarc.alert.security.mail.example.com (not found)
2. _dmarc.security.mail.example.com (not found)
3. _dmarc.mail.example.com (not found)
4. _dmarc.example.com (DMARC record found with psd=n)

Implementation Timeline and Current Status

Development Timeline

Current Status (September 2025)

DMARCbis and the aggregate-reporting draft were approved by the IESG in 2025. Final RFC publication awaits resolution of the failure-reporting document. The specifications ready for publication are:

• Approved: draft-ietf-dmarc-dmarcbis-41 (main specification)
• Approved: draft-ietf-dmarc-aggregate-reporting-32 (reporting specification)
• Pending: draft-ietf-dmarc-failure-reporting-13 (blocking publication)

The reconvened DMARC Working Group must either complete the failure reporting specification or remove references to it by November 2025.

Industry Context

This extended timeline is typical for IETF standards:

• SPF (RFC 7208): 7 years from inception to standard (2000-2007)
• DKIM (RFC 6376): 6 years of development (2005-2011)
• DMARC 1.0 (RFC 7489): 4 years to publication (2011-2015)
• BIMI (RFC 8910): 5 years in development (2015-2020)

Backward Compatibility and Migration

Complete Backward Compatibility

DMARCbis ensures zero disruption to existing email authentication:

• v=DMARC1 records remain valid: No version number change required
• Existing policies continue working: All current tags function identically
• No forced migration: Organizations choose their adoption timeline
• Gradual feature adoption: Implement new capabilities when ready

Migration Strategies

Organizations can approach DMARC 2.0 adoption through several paths:

Challenges and Considerations

Implementation Challenges

Technical Complexity

While DMARCbis simplifies some aspects, organizations must understand:

• DNS Tree Walk mechanics for proper configuration
• Interaction between new policy tags
• Impact on existing email flows
• Subdomain inheritance changes
• Possible interoperability differences during PSL to Tree Walk transition

Transition Period Uncertainty

The dual-standard environment creates considerations:

• Variable receiver support during early adoption
• Potential differences in policy interpretation
• Need for comprehensive testing
• Monitoring requirements during transition

Resource Requirements

Successful implementation demands:

• DNS management expertise
• Email authentication knowledge
• Monitoring and reporting tools
• Vendor coordination capabilities

Operational Considerations

Multi-domain Organizations

Companies with complex domain structures face unique challenges:

• Coordinating policies across business units
• Managing third-party sender authentication
• Maintaining consistent security posture
• Scaling policy management

Third-party Senders

Marketing and transactional email services require:

• Updated authentication configurations
• Vendor capability assessments
• Migration timeline coordination
• Contingency planning for non-compliant services

Forwarding and Mailing Lists

For forwarding/mailing lists, see ARC (RFC 8617), which preserves authentication assessments across intermediaries and complements DMARC/DMARCbis.

Frequently Asked Questions

General DMARC 2.0 Questions

Q: What is DMARC 2.0 and how is it different from DMARCbis?

A: DMARC 2.0 and DMARCbis are the same thing. DMARCbis (pronounced "dee-mark-biss") is the official IETF designation, where "bis" is Latin for "twice" or "encore," indicating a second version. The industry often uses "DMARC 2.0" for clarity, though the protocol retains v=DMARC1 in DNS records for backward compatibility.

Q: When will DMARC 2.0 be officially released?

A: DMARCbis and the aggregate-reporting draft were approved by the IESG in 2025. Final RFC publication awaits resolution of the failure-reporting document, which is actively being revised.

Q: Will DMARC 2.0 replace DMARC 1.0?

A: DMARC 2.0 is expected to supersede DMARC 1.0 as the standard once published, but existing DMARC 1.0 implementations will continue functioning indefinitely. There's no forced migration or sunset date for DMARC 1.0 records. Organizations can adopt DMARC 2.0 features at their own pace.

Technical Implementation Questions

Q: How does the DNS Tree Walk algorithm work?

A: The DNS Tree Walk queries DNS hierarchically, starting at the sending domain and moving up one label at a time. For example, with mail.example.com, it checks _dmarc.mail.example.com first, then _dmarc.example.com. It stops when finding a DMARC record or after 8 queries, preventing DNS amplification attacks.

Q: What happens to my existing v=DMARC1 records?

A: Nothing—they continue working exactly as before. DMARCbis maintains the v=DMARC1 identifier for backward compatibility. You don't need to change existing records unless you want to adopt new features like the np tag for subdomain protection or the t testing tag.

Q: What are the main new tags in DMARC 2.0?

A: Three primary new tags enhance policy control:

• np: Sets policy for non-existent subdomains (syntax matches p)
• psd: Lets Public Suffix Operators and domain owners mark boundaries (psd=y or psd=n)
• t: Binary testing signal; complements removal of pct

Q: Which tags are deprecated in DMARCbis?

A: Three tags are removed/marked historic based on operational experience:

• pct: Percentage-based gradual rollout (marked historic)
• rf: Report format (removed)
• ri: Report interval (removed)

Migration and Compatibility Questions

Q: Do I need to migrate to DMARC 2.0 immediately?

A: No, there's no immediate migration requirement. Your existing DMARC policies will continue working indefinitely. Migration is voluntary and should be based on your organization's specific security needs and readiness to adopt enhanced features.

Q: How do I prepare for DMARC 2.0?

A: Start with these preparatory steps:

1. Audit existing records for deprecated tags
2. Ensure SPF and DKIM are properly configured
3. Understand your subdomain structure
4. Evaluate vendor DMARCbis support
5. Plan testing before implementing new features

Q: Will email providers support both DMARC versions?

A: Yes, providers typically adopt new standards gradually while maintaining backward compatibility. The transition period is expected to last several years.

Q: What if my email service provider doesn't support DMARC 2.0?

A: Your emails will continue to authenticate using standard DMARC 1.0 policies. As DMARCbis maintains backward compatibility, there's no risk of authentication failure. However, you won't benefit from new security features until your provider adds support.

Security and Business Impact Questions

Q: How does DMARC 2.0 improve security?

A: Key security improvements include:

• Better protection against subdomain spoofing via the np tag
• More accurate organizational boundary detection
• Replacement of Public Suffix List dependencies
• Clearer policy inheritance for complex domain structures
• Simplified testing reducing configuration errors

Q: Will DMARC 2.0 affect my email deliverability?

A: If you maintain existing v=DMARC1 records, there's no impact on deliverability. When implementing new features, use the t=y testing tag to verify proper configuration before enforcement. Gradual adoption ensures no disruption to legitimate email flows.

Q: How does DMARC 2.0 prevent CEO fraud?

A: The np (non-existent subdomain) tag specifically addresses CEO fraud by blocking emails from fake subdomains. For example, if ceo.example.com doesn't exist, np=reject prevents attackers from spoofing emails from this subdomain, a common tactic in targeted attacks.

Q: What's the business case for adopting DMARC 2.0?

A: DMARC 2.0 provides:

• Enhanced protection against sophisticated phishing
• Reduced administrative overhead (no Public Suffix List management)
• Better control over complex domain structures
• Improved testing and deployment options
• Future-proofing your email authentication infrastructure

DMARC Management Questions

Q: How does IRONSCALES support DMARC 2.0?

A: IRONSCALES provides comprehensive DMARC 2.0 support with automated migration tools, expert guidance, and multi-domain management capabilities. Our platform is built on industry-leading technology that's specifically prepared for the DMARCbis transition.

Q: Can IRONSCALES automatically migrate my records to DMARC 2.0?

A: Yes, IRONSCALES offers migration assistance tools that can:

• Identify and remove deprecated tags
• Suggest optimal new tag configurations
• Test changes before deployment
• Monitor authentication during transition
• Provide expert guidance throughout the process

Q: What if I'm using IRONSCALES but haven't implemented DMARC yet?

A: IRONSCALES makes it easy to implement DMARC correctly from the start. You can begin with current best practices and naturally adopt DMARC 2.0 features as they become widely supported, all through a single platform.

Q: How does DMARC 2.0 work with IRONSCALES' email security?

A: DMARC 2.0 provides the foundation for domain authentication, preventing unauthorized use of your domain. IRONSCALES' DMARC management tools ensure proper implementation and monitoring while making the transition to enhanced DMARC 2.0 features seamless when you're ready.

Industry and Compliance Questions

Q: Are there compliance implications for DMARC 2.0?

A: While DMARC 2.0 isn't explicitly required by regulations, enhanced email authentication supports compliance with:

• GDPR (data protection through reduced phishing risk)
• HIPAA (protecting healthcare communications)
• PCI DSS (securing payment card data)
• SOC 2 (demonstrating security controls)

Q: Which industries should prioritize DMARC 2.0 adoption?

A: High-value targets should consider early adoption:

• Financial services (frequent impersonation targets)
• Healthcare (sensitive data protection)
• Government (national security implications)
• E-commerce (brand protection and customer trust)
• Technology companies (supply chain attack prevention)

Q: What are other email authentication standards doing?

A: The email authentication ecosystem continues evolving:

• BIMI: Brand Indicators for Message Identification (visual verification)
• ARC: Authenticated Received Chain (forwarding preservation) - RFC 8617
• MTA-STS: Mail Transfer Agent Strict Transport Security (encryption)

All these standards complement DMARC 2.0 for comprehensive protection.

Explore More Articles

Ready to implement or upgrade your DMARC authentication? Learn more about DMARC fundamentals or explore how SPF and DKIM work together with DMARC to create a comprehensive email authentication strategy. For hands-on guidance with DMARC 2.0 preparation, contact our team to discuss your organization's specific requirements.