DMARC Evolves: IETF Publishes New RFCs, Solidifying Email Authentication Standards

On June 1, 2026, the global landscape of email authentication took a significant step forward with the formalization of new Domain-based Message Authentication, Reporting, and Conformance (DMARC) specifications by the Internet Engineering Task Force (IETF). This pivotal development sees the former "DMARCbis" initiative culminate in three new RFCs (Request for Comments) — RFC 9989 (core protocol), RFC 9990 (aggregate reports), and RFC 9991 (failure reports) — which collectively supersede the original DMARC specification. While the nomenclature "DMARCbis" is now retired, the core principles of DMARC remain steadfast: ensuring the authenticity and alignment of email senders to combat widespread digital threats. For businesses, particularly those leveraging Email Service Providers (ESPs) like Mailjet, the practical takeaway is one of modernization and clarification rather than a fundamental upheaval, underscoring the enduring importance of authenticated email practices.

Understanding DMARC: A Foundation for Trust in Digital Communication

To fully appreciate the significance of these updates, it is essential to revisit the foundational role DMARC plays in the email ecosystem. DMARC was originally conceived to provide a robust framework for email senders to protect their domains from unauthorized use, such as phishing and spoofing. It builds upon two existing email authentication protocols: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

SPF allows domain owners to publish a list of authorized sending IP addresses in their DNS records. When an email server receives a message, it can check the sender’s domain against this SPF record to verify if the sending IP is legitimate. If the IP is not listed, the email may be flagged as suspicious. However, SPF alone has limitations, particularly with forwarding or when the visible "From" address differs from the technical "MAIL FROM" address.

DKIM, on the other hand, provides a cryptographic signature for emails. A sending server signs outgoing messages with a private key, and the receiving server can use a public key (published in the sender’s DNS records) to verify the signature. This ensures that the email has not been tampered with in transit and that it genuinely originates from the domain specified in the signature. DKIM helps maintain message integrity and sender authenticity.

DMARC acts as an overarching policy layer that ties SPF and DKIM together. It instructs receiving mail servers on how to handle emails that fail SPF or DKIM checks, based on the domain specified in the visible "From" header. Crucially, DMARC introduces the concept of "alignment," meaning that the domain used for SPF or DKIM authentication must match, or be closely related to, the domain shown in the "From" header. If an email passes either an aligned SPF check or an aligned DKIM check, DMARC passes. If both fail, DMARC provides policies (none, quarantine, reject) to guide the receiving server’s action, alongside comprehensive reporting mechanisms. This combination has proven instrumental in significantly reducing phishing and spoofing attempts, safeguarding brand reputation, and improving email deliverability rates.

The Journey to Modernization: DMARCbis Becomes DMARC

The original DMARC specification, RFC 7489, was published in March 2015, born out of a collaborative effort involving major email providers and technology companies aiming to standardize email authentication. Its rapid adoption highlighted its effectiveness, but as with any evolving internet standard, certain areas required refinement, clarification, and modernization to address ambiguities and align with current internet practices. This led to the IETF’s DMARCbis working group, which embarked on the meticulous process of reviewing and updating the protocol.

The "bis" designation, a Latin suffix meaning "twice" or "second time," signaled that this was a revision, an enhanced iteration, rather than a completely new protocol. The IETF, as the primary body for developing and promoting voluntary Internet standards, undertakes such revisions to ensure the robustness, interoperability, and security of internet protocols. The DMARCbis effort focused on refactoring the documentation, enhancing clarity in implementation guidelines, and incorporating lessons learned from nearly a decade of DMARC deployment in real-world scenarios. This process involved extensive discussions, numerous drafts, and rigorous peer review within the IETF community.

The publication of the new RFCs in May 2026 marks the culmination of this multi-year effort. This chronology underscores a commitment to continuous improvement within the internet standards community. The primary motivation was not to introduce radical new features but to solidify DMARC’s foundation, making it more resilient and easier to implement and understand for a broader audience of senders, receivers, and ESPs. Industry experts have consistently emphasized the importance of such standardization, noting that clear, unambiguous protocols are vital for the smooth functioning of global email infrastructure.

The Technical Evolution: RFC 9989, 9990, and 9991

The transition from a single DMARC RFC to three distinct documents reflects a deliberate effort to modularize and clarify the protocol’s components.

• RFC 9989 (Core Protocol): This is the heart of the updated DMARC specification. It defines the fundamental mechanisms for how DMARC works, including the evaluation model (aligned SPF or aligned DKIM), the policy enforcement (none, quarantine, reject), and the interaction with SPF and DKIM results. This RFC largely refactors and clarifies the language from the original specification, addressing potential ambiguities that may have arisen during its widespread adoption. It reinforces the core principle that a single aligned identifier (either SPF or DKIM) is sufficient for a DMARC pass.
• RFC 9990 (Aggregate Reports): This RFC specifically details the format and content of DMARC aggregate reports. These XML-formatted reports provide domain owners with invaluable data about their email sending patterns, showing how many messages were sent, which sources authenticated correctly, and which failed, along with the DMARC policy applied by receiving servers. The updates in RFC 9990 aim to improve the consistency and utility of these reports, making it easier for domain owners and DMARC monitoring services to parse and act upon the information. These reports are crucial for identifying legitimate sending sources and detecting potential abuse.
• RFC 9991 (Failure Reports): Also known as forensic reports, these documents (often sent as email attachments) provide more granular, anonymized details about individual email failures. While often sensitive due to potential data privacy concerns, they can be highly useful for debugging authentication issues or investigating specific instances of spoofing. RFC 9991 clarifies the structure and handling of these reports, balancing the need for detailed diagnostic information with privacy considerations.

This modular approach allows for clearer documentation and potentially more independent evolution of specific components in the future, without requiring a complete overhaul of the entire DMARC standard.

Implications for Email Senders: A Call for Continued Vigilance

The transition to the new DMARC RFCs is not a call for panic but a reinforcement of existing best practices. For organizations already diligently employing DMARC, the operational impact is minimal. The core evaluation model remains unchanged, meaning that if your email program was DMARC-compliant yesterday, it remains DMARC-compliant today. However, the update serves as a powerful reminder of the increasing expectations from major mailbox providers (MBPs) such as Google, Yahoo, and Microsoft. These providers are progressively making robust email authentication, including DMARC, a baseline requirement for optimal deliverability and reputation management. Without proper authentication, emails risk being filtered into spam folders or outright rejected, severely impacting communication and business operations.

For senders who have yet to implement DMARC, or those who are only partially compliant, these updates should serve as an urgent impetus to act. The modernized specifications offer clearer guidance, making the implementation process potentially more straightforward. The benefits of DMARC extend far beyond mere compliance; they include enhanced brand protection against phishing and spoofing attacks, improved deliverability rates by fostering trust with MBPs, and invaluable insights into email sending practices through DMARC reports. According to recent industry analyses, organizations with DMARC in place experience significantly lower rates of email-based brand abuse and higher inbox placement rates compared to those without. The new RFCs simply solidify the technical foundation upon which these benefits are built.

Mailjet’s Role in the Evolving Landscape: Facilitating Compliance

As a leading Email Service Provider, Mailjet plays a crucial role in helping its customers navigate the complexities of email authentication and remain compliant with evolving standards like DMARC. The company’s established practices are well-aligned with the updated RFCs, emphasizing that DMARC’s core "aligned SPF or aligned DKIM" model is central to its operational framework.

• Mailjet’s DKIM-First Approach: When a customer validates a sender domain in Mailjet, the platform automatically configures DKIM authentication. This means Mailjet handles the digital signing of outgoing emails using a DKIM key associated with the customer’s domain (or a subdomain within their control). Since Mailjet facilitates the DKIM signature with the customer’s domain, and the visible "From" address typically uses the same domain (or an aligned subdomain), DKIM alignment for DMARC is inherently straightforward. This "DKIM-first" default ensures that Mailjet customers are immediately set up for DMARC success via DKIM.

• The Return-Path and SPF Alignment: By default, Mailjet utilizes a provider-owned bounce domain, such as bnc3.mailjet.com, for the MAIL FROM address (also known as the Return-Path). While this setup effectively handles bounce processing, it means that by default, SPF alignment for DMARC typically does not occur, because the MAIL FROM domain (bnc3.mailjet.com) does not align with the customer’s visible "From" domain. However, this is not a detriment to DMARC passing, as DMARC only requires one aligned authenticated identifier (either SPF or DKIM). Given Mailjet’s strong DKIM alignment, most customers under the default configuration will successfully pass DMARC through DKIM.

• Configuring a Custom Return-Path for Enhanced SPF Alignment: For Mailjet customers on paid plans who desire SPF alignment in addition to DKIM alignment, the platform offers the option to configure a custom Return-Path. This feature allows the MAIL FROM address to use a subdomain within the customer’s organizational domain (e.g., bounces.yourdomain.com). When this is configured, Mailjet manages the DNS records for this subdomain, including the necessary SPF record. Under a "relaxed" SPF alignment policy (aspf=r), DMARC can then pass through SPF, as the MAIL FROM domain (e.g., bounces.yourdomain.com) shares the organizational domain with the visible "From" address (yourdomain.com). This provides a dual layer of DMARC passing, although it’s important to note that only one is strictly required. Customers considering "strict" SPF alignment (aspf=s), which requires an exact match between the MAIL FROM and "From" domains, should carefully review this setup as it is less commonly achieved with ESPs handling the Return-Path. It is also important to note that only one active custom Return-Path can typically be configured per API key, and specific availability and setup details may evolve, necessitating a check of Mailjet’s latest documentation and support guidance.

• Dedicated IPs and DMARC: Mailjet clarifies that the use of dedicated IP addresses, while offering benefits for reputation control and deliverability troubleshooting, does not alter DMARC’s fundamental alignment rules. Whether customers utilize shared or dedicated Mailjet IPs, DMARC consistently evaluates the alignment between the visible "From" domain and the authenticated SPF or DKIM identifiers. The core logic of DMARC remains independent of the specific IP infrastructure.

Practical Steps for Mailjet Customers

In light of the DMARC updates, Mailjet senders should undertake a proactive review of their email authentication practices:

1. Verify Domain Authentication: Ensure all sender domains used in Mailjet are properly authenticated. This involves confirming the correct DNS records for DKIM (and SPF if using a custom Return-Path) are published and validated within the Mailjet platform.
2. Confirm DMARC Implementation: If not already in place, implement DMARC for all sending domains. Start with a "none" policy to gather reports and gain visibility, then progressively move to "quarantine" or "reject" as confidence in authentication grows.
3. Monitor DMARC Reports: Regularly review DMARC aggregate reports (RFC 9990). These reports are indispensable for understanding email sending patterns, identifying unauthorized sending sources, and troubleshooting authentication failures.
4. Ensure Domain Alignment: Double-check that the domains used in the visible "From" addresses align with either the DKIM signature domain or the SPF MAIL FROM domain, consistent with DMARC requirements. For Mailjet users, this typically means ensuring the "From" domain matches the domain authenticated for DKIM.
5. Utilize Mailjet Resources: Leverage Mailjet’s help center articles and support channels for guidance on DMARC, DKIM, SPF, and custom Return-Path configurations. Stay informed about any updates to Mailjet’s authentication features or best practices.

The Broader Outlook: Strengthening the Email Ecosystem

The modernization of DMARC through the new IETF RFCs signifies a collective commitment from the internet community to enhance the security and trustworthiness of email. Email remains a cornerstone of both personal and professional communication, and its susceptibility to abuse poses significant risks. By providing clearer, more robust standards for authentication and reporting, DMARC continues to empower senders to protect their brands and recipients to trust the messages they receive.

This evolution is part of a larger trend where email security is becoming increasingly non-negotiable. Major mailbox providers are continually tightening their requirements, making strong authentication a prerequisite for reliable inbox delivery. The ongoing efforts by organizations like the IETF to refine and update these protocols ensure that the email ecosystem can adapt to new threats and maintain its integrity. For most Mailjet customers who have already embraced authenticated domains and correctly aligned identifiers, these new RFCs are not a disruption but a welcome clarification, solidifying existing best practices and reinforcing the long-term stability of DMARC. DMARCbis is indeed dead, but the robust, modernized DMARC standard will continue to live long, serving as a critical pillar of email security.