Mailjet: DMARCbis is dead. Long live DMARC.  – Sinch Mailjet

The Evolution of Email Authentication: From RFC 7489 to the New Era

The journey to the latest DMARC specification has been a measured progression reflecting the internet community’s commitment to robust email security. DMARC, or Domain-based Message Authentication, Reporting, and Conformance, was originally introduced as RFC 7489 in March 2015. Its genesis stemmed from a critical need to address the pervasive issues of email spoofing, phishing, and business email compromise (BEC), which leverage deceptive email practices to defraud individuals and organizations. Prior to DMARC, technologies like Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) provided foundational authentication layers, but lacked a unified mechanism to instruct recipient mail servers on how to handle messages that failed these checks, nor did they offer a feedback loop to senders.

SPF, first standardized as RFC 4408 in 2006 (and later RFC 7208 in 2014), allows a domain owner to specify which mail servers are authorized to send email on behalf of their domain. It works by checking the MAIL FROM (also known as the Return-Path) domain against a list of permitted IP addresses published in the sender’s DNS records. If an email originates from an unauthorized server, it fails SPF. DKIM, standardized as RFC 6376 in 2011, provides a cryptographic signature for email messages. A sending server signs outgoing emails with a private key, and the recipient server uses a public key (published in the sender’s DNS) to verify the signature. This ensures message integrity and verifies the sender’s identity.

However, a critical gap remained: what if a legitimate email passed SPF and DKIM, but the visible "From" address (the one users see) was spoofed? Or what if an email failed authentication? DMARC emerged to bridge this gap, acting as an overarching policy layer that connects the visible "From" domain with the authentication results of SPF and DKIM. It introduced the concept of "alignment," requiring that the domain used in SPF (MAIL FROM) or DKIM (d= domain in the signature) must match or be a subdomain of the visible "From" domain. Crucially, DMARC also provided a mechanism for senders to publish policies (none, quarantine, or reject) indicating how recipient mail servers should handle unaligned or unauthenticated messages, and introduced reporting features (aggregate and forensic reports) to give senders visibility into their email streams.

Over the years, as DMARC adoption grew and implementation complexities emerged, the need for clarification and modernization became apparent. This led to the development of "DMARCbis" – an informal moniker for the ongoing work to revise and update the original DMARC specification. This collaborative effort, primarily within the IETF’s DMARC Working Group, aimed to refine the protocol, address ambiguities, incorporate best practices learned from years of real-world deployment, and ensure its continued relevance in an evolving email ecosystem. The culmination of this work is the publication of three new RFCs in May 2026: RFC 9989 (the core DMARC protocol), RFC 9990 (aggregate reports), and RFC 9991 (failure reports). These new documents officially supersede RFC 7489, standardizing the enhancements and clarifications developed under the DMARCbis initiative.

The Technical Nuances of the Update: Clarification, Not Reinvention

The transition from RFC 7489 to the new suite of DMARC RFCs represents a significant maturation of the standard. While the designation "DMARCbis is now DMARC" simplifies the message, it underscores a deeper process of refinement rather than a fundamental overhaul. The IETF’s primary objective was to refactor, clarify, and modernize the documentation, making the protocol more robust, easier to implement, and less prone to misinterpretation.

RFC 9989, the core DMARC protocol, defines how a recipient mail server should evaluate a DMARC policy. It maintains the foundational principle that DMARC passes if at least one of the authentication mechanisms (SPF or DKIM) aligns with the visible "From" domain. The core concept of "alignment" remains unchanged: SPF alignment requires the MAIL FROM domain to align with the "From" header domain, and DKIM alignment requires the "d=" tag in the DKIM signature to align with the "From" header domain. Both mechanisms support either "relaxed" (organizational domain match) or "strict" (exact domain match) alignment modes. The policies (p=none, p=quarantine, p=reject) also persist, allowing senders to gradually enforce DMARC protection without immediately disrupting legitimate mail flows.

RFC 9990 details the structure and content of DMARC aggregate reports (RUAs). These XML-formatted reports provide senders with high-level statistics on email volume, authentication results (SPF, DKIM, DMARC pass/fail), and policies applied by recipient mail servers. The updates in RFC 9990 focus on improving the clarity and utility of these reports, potentially addressing nuances in how reporting domains are specified or how data elements are interpreted, ensuring that senders receive consistent and actionable insights into their email authentication posture.

RFC 9991, concerning DMARC failure reports (RUFs), addresses the more granular, event-specific reports generated when an email fails DMARC. These forensic reports contain anonymized message details, including headers and sometimes snippets of the message body, which can be invaluable for diagnosing authentication failures and identifying sources of abuse. The revisions in RFC 9991 likely aim to standardize the format and content of these reports, enhancing their interoperability and ensuring privacy considerations are adequately addressed, given the sensitive nature of their content.

Crucially, these updates do not introduce new authentication mechanisms or fundamentally alter the DMARC evaluation logic. Instead, they enhance the standard’s clarity, address ambiguities that have emerged over a decade of deployment, and incorporate best practices for improved interoperability and effectiveness. This means that organizations with well-configured DMARC implementations should not anticipate major operational shifts but rather a reinforcement of existing best practices. For those yet to fully embrace DMARC, the modernized documentation provides a clearer path to implementation.

Why DMARC Matters: Combatting the Scourge of Email Fraud

The ongoing refinement and standardization of DMARC are testament to its critical role in the fight against email-borne threats. Email remains the primary vector for cyberattacks, with phishing, spoofing, and business email compromise (BEC) accounting for billions of dollars in losses annually. According to various cybersecurity reports, phishing attacks increased significantly year-over-year, with over 80% of reported security incidents linked to phishing. BEC scams alone have resulted in over $43 billion in exposed losses from 2016 to 2021, according to the FBI’s Internet Crime Complaint Center (IC3).

DMARC directly addresses these threats by making it significantly harder for malicious actors to impersonate legitimate organizations. By enforcing DMARC policies at a "reject" level, organizations can prevent spoofed emails purporting to be from their domain from ever reaching recipient inboxes. This protects their customers, partners, and employees from sophisticated phishing attempts that could lead to data breaches, financial fraud, or malware infections.

For email senders, DMARC offers several tangible benefits beyond fraud prevention. Firstly, it significantly improves email deliverability. Mailbox providers, increasingly reliant on strong authentication to filter out spam and malicious mail, favor domains with robust DMARC policies. A domain at p=reject sends a clear signal of trustworthiness, leading to better inbox placement rates. Conversely, domains without DMARC, or those only at p=none, are often viewed with suspicion, increasing the likelihood of their legitimate emails being quarantined or blocked.

Secondly, DMARC protects brand reputation. In an era where trust is paramount, an organization’s brand can suffer irreparable damage if its domain is used for widespread fraudulent activity. DMARC acts as a shield, preventing bad actors from exploiting brand recognition to deceive recipients. It ensures that only authorized communications bearing the brand’s identity reach the intended audience.

For mailbox providers, DMARC provides a standardized and scalable mechanism to filter incoming mail. By leveraging senders’ DMARC policies, they can automatically block or quarantine a vast volume of spoofed and fraudulent emails, reducing the burden on their filtering systems and improving the security posture for their users. The new RFCs offer clearer guidelines, enhancing interoperability and consistent enforcement across different providers.

Implications for Email Senders and Mailbox Providers

The IETF’s DMARC update reinforces the global trend towards a more secure email ecosystem. For email senders, the message is clear: robust email authentication is no longer optional but a fundamental requirement for maintaining deliverability and protecting brand integrity. Organizations that have not yet implemented DMARC or are only at a p=none policy are now operating at a significant disadvantage, facing higher risks of email fraud and poorer deliverability outcomes.

Mailbox providers, such as Google, Microsoft, and Yahoo, have progressively tightened their email authentication requirements, with DMARC playing a central role. Their algorithms increasingly prioritize emails from DMARC-protected domains, especially those with an enforced policy (p=quarantine or p=reject). The clarified DMARC specification provides a more stable foundation for these providers to continue evolving their filtering strategies, potentially leading to even stricter enforcement in the future.

This update encourages all email senders to:

1. Implement DMARC: If not already done, begin the process of deploying DMARC. This involves configuring SPF and DKIM correctly for all sending domains and then publishing a DMARC record.
2. Monitor DMARC Reports: Actively analyze aggregate reports (RUAs) to understand their email sending ecosystem, identify legitimate senders that may be failing authentication, and detect potential spoofing attempts.
3. Progress to Enforcement: Gradually move their DMARC policy from p=none to p=quarantine and ultimately to p=reject. This process requires careful monitoring and adjustment to avoid blocking legitimate email.
4. Review Existing Configurations: Even for those with DMARC already in place, the updated RFCs serve as a prompt to review current SPF, DKIM, and DMARC configurations to ensure they align with the latest best practices and benefit from the clarifications provided.

Mailjet’s Stance and Operational Guidance for Customers

For Mailjet customers, the DMARC update, while significant for the broader industry, primarily reinforces existing best practices rather than demanding immediate, drastic changes to their established sending processes. Mailjet has long championed strong email authentication, and its platform defaults are designed to facilitate DMARC compliance.

Mailjet’s default configuration emphasizes DKIM-first alignment. When a sender domain is validated within Mailjet, the platform automatically provides a DKIM record (CNAME entry) for the customer to publish in their DNS. This ensures that all emails sent via Mailjet using that validated domain are cryptographically signed with DKIM. Crucially, Mailjet ensures that the DKIM "d=" domain aligns with the customer’s visible "From" domain (or an aligned subdomain), making DKIM alignment for DMARC straightforward for most users. This means that in Mailjet’s default setup, DMARC commonly passes through DKIM alignment, which is perfectly valid, as DMARC requires only one aligned authenticated identifier (either SPF or DKIM), not both.

Regarding SPF, Mailjet’s default behavior involves using a provider-owned bounce domain (e.g., bnc3.mailjet.com) for the MAIL FROM address (also known as the Return-Path). This MAIL FROM domain is correctly SPF-authenticated by Mailjet’s infrastructure. However, because this domain is Mailjet’s and not the customer’s visible "From" domain, SPF will not align with the customer’s "From" domain in the default setup. While this doesn’t prevent DMARC from passing (thanks to DKIM alignment), customers who desire SPF alignment for DMARC can configure a custom Return-Path on Mailjet’s paid plans.

A custom Return-Path allows customers to use a subdomain of their own organizational domain for the MAIL FROM address (e.g., bnc.yourdomain.com). Mailjet then manages the DNS records for this subdomain, ensuring SPF passes and, under relaxed SPF alignment (aspf=r), achieves DMARC alignment with the customer’s visible "From" domain. It’s important to note that this feature typically allows for only one active custom Return-Path per API key and may depend on specific plan types and support processes. Customers considering or using strict SPF alignment (aspf=s) must exercise caution, as strict alignment requires an exact match between the MAIL FROM domain and the visible "From" domain, which may not be compatible with Mailjet’s managed bounce subdomain approach.

Mailjet also clarifies that dedicated IPs do not alter DMARC’s alignment rules. Whether using shared or dedicated IPs, DMARC continues to evaluate alignment between the visible "From" domain and the authenticated SPF or DKIM identifiers. Dedicated IPs primarily affect reputation control and deliverability troubleshooting but are distinct from DMARC’s core function.

For Mailjet senders, the DMARC update serves as a timely reminder to review and optimize their email authentication strategy. Specific actions include:

1. Validate All Sending Domains: Ensure all domains used in the visible "From" address are authenticated within Mailjet, specifically with DKIM records published in their DNS.
2. Monitor DMARC Reports: Utilize DMARC reporting tools to regularly review aggregate reports for their domains, identify any authentication failures, and understand traffic patterns.
3. Consider Custom Return-Path for SPF Alignment: If SPF alignment is desired in addition to DKIM, explore the custom Return-Path option available on Mailjet’s paid plans and consult Mailjet’s documentation or support for setup guidance.
4. Enforce DMARC Policies Gradually: Progress from p=none to p=quarantine and then p=reject only after thoroughly analyzing DMARC reports and ensuring all legitimate email sources are correctly authenticated and aligned.
5. Stay Informed: Regularly check Mailjet’s documentation and support resources for the latest guidance on DMARC and other email authentication best practices, as standards and platform features may evolve.

The Future of Email Authentication

The standardization of DMARC through these new RFCs solidifies its position as a cornerstone of email security. However, the landscape of email authentication continues to evolve. Emerging standards like Brand Indicators for Message Identification (BIMI) leverage DMARC at an enforced policy (p=quarantine or p=reject) to display brand logos next to authenticated emails in supported inboxes, further enhancing trust and brand visibility. This demonstrates how DMARC forms a foundational layer upon which future email security and branding innovations can be built.

The IETF’s work on DMARCbis and its subsequent formalization as new RFCs underscores a collective commitment from the internet community to create a more secure, trustworthy, and interoperable email environment. For most Mailjet customers already leveraging authenticated domains and correctly aligned identifiers, the new RFCs serve more as a clarification of existing best practices than a call for a major operational overhaul. DMARCbis is dead; long live DMARC, stronger and clearer than ever before. The path forward for email senders is clear: embrace robust authentication, monitor diligently, and adapt to the evolving standards to ensure optimal deliverability and protect digital communications from the ever-present threat of fraud.