DMARC Protocol Modernized with New RFCs, Solidifying Email Authentication Standards for Senders and Mailbox Providers

The email security landscape reached a significant milestone in May 2026 with the formal publication of three new Request for Comments (RFCs) by the Internet Engineering Task Force (IETF). These documents — RFC 9989 (core protocol), RFC 9990 (aggregate reports), and RFC 9991 (failure reports) — officially supersede the original DMARC (Domain-based Message Authentication, Reporting, and Conformance) specification, RFC 7489. This pivotal update means that what was colloquially known as "DMARCbis" throughout its development phase is now simply DMARC, representing a modernization and clarification of the protocol rather than a radical overhaul. The implications for email senders, particularly those utilizing platforms like Mailjet, underscore the critical and ongoing expectation from mailbox providers for authenticated and aligned email as a fundamental aspect of sender behavior.

The IETF’s decision to update DMARC reflects an evolving understanding of email security threats and the practicalities of large-scale email operations. While the core principles of DMARC remain intact, the new RFCs formalize and clarify practices that many email service providers (ESPs) and senders have already adopted. For Mailjet customers, this translates into a continued, unwavering focus on three key pillars: authenticating email, ensuring alignment of authenticated domains, and diligently monitoring DMARC reports. This structured approach is essential for maintaining sender reputation and optimizing email deliverability in an increasingly stringent digital environment.

Understanding DMARC: A Foundation for Email Security

To fully appreciate the significance of these updates, it’s crucial to understand DMARC’s foundational role in email security. DMARC emerged from a critical need to combat email spoofing and phishing, which exploit the deceptive nature of the "From" address in emails. Prior to DMARC, protocols like Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) offered partial solutions. SPF allows domain owners to specify which mail servers are authorized to send email on their behalf, preventing unauthorized servers from sending emails impersonating their domain. DKIM, on the other hand, provides a cryptographic signature that verifies the sender of an email and ensures that the email content has not been tampered with in transit.

However, SPF and DKIM alone have limitations. A common attack vector involves sending an email where the visible "From" address (the one users see) differs from the underlying technical domains used for SPF or DKIM checks. This allows malicious actors to pass SPF or DKIM checks while still spoofing a reputable brand. DMARC was designed to bridge this gap by introducing the concept of "alignment." It checks whether the domain in the visible "From" address aligns with the domains authenticated by SPF or DKIM. If alignment fails, DMARC instructs receiving mail servers on how to handle the message – to do nothing (monitor mode), quarantine it (move to spam), or reject it entirely. Crucially, DMARC also provides reporting mechanisms, allowing domain owners to receive valuable feedback on who is sending email purporting to be from their domain, enabling them to detect and mitigate unauthorized use.

A Brief Chronology of DMARC’s Journey

The journey to the modernized DMARC protocol spans over a decade, marked by increasing collaboration and evolving industry standards:

• Early 2000s: The proliferation of spam and phishing attacks highlights the urgent need for email authentication. SPF (originally RFC 4408, later updated to RFC 7208) and DKIM (RFC 6376) emerge as independent solutions.
• 2010-2012: A consortium of major email providers and technology companies, including Google, Microsoft, Yahoo, AOL, and PayPal, begins collaborating to develop a unified standard that leverages SPF and DKIM more effectively. This initiative, driven by the DMARC.org working group, aims to provide domain owners with control over unauthenticated messages.
• January 2012: The initial DMARC specification is published, quickly gaining traction among major mailbox providers.
• March 2015: DMARC is formally standardized by the IETF as RFC 7489, cementing its place as a critical component of email security infrastructure. This marked a significant achievement, bringing an industry-led initiative into the official internet standards track.
• Post-2015: As DMARC adoption grows, implementers and developers identify areas for clarification, refinement, and expansion. Discussions begin within the IETF’s DMARCbis working group to address these points, aiming to create a more robust and unambiguous standard. This "bis" (Latin for "twice") phase indicated an update to an existing RFC.
• May 2026: The IETF formally publishes RFC 9989, 9990, and 9991, concluding the DMARCbis efforts and ushering in the new era of DMARC.

This timeline illustrates a consistent industry-wide effort to enhance email security, moving from disparate solutions to a comprehensive, standardized framework. The transition from RFC 7489 to the new RFCs is a natural progression, reflecting the protocol’s maturity and the collective experience gained over years of implementation.

Key Updates and Formalizations in the New RFCs

The newly published RFCs provide crucial clarifications and formalizations without introducing radical shifts to DMARC’s fundamental operation.

• RFC 9989: DMARC Core Protocol: This document redefines the core DMARC protocol, offering clearer guidance on policy application, handling of subdomains, and the intricate details of DMARC record syntax. It addresses ambiguities that sometimes led to inconsistent interpretations among implementers, providing a more definitive framework for how DMARC policies should be evaluated and applied by receiving mail servers. For instance, the specification around the sp (subdomain policy) tag and its interaction with the main p (policy) tag has been refined, offering more predictable behavior.
• RFC 9990: DMARC Aggregate Reports: Aggregate reports (RUAs) are the cornerstone of DMARC monitoring, providing domain owners with XML-formatted summaries of email streams purporting to be from their domains. RFC 9990 formalizes the structure and content of these reports, ensuring greater consistency across different reporting entities. This standardization makes it easier for DMARC analysis tools to parse and interpret data, offering senders a clearer, more reliable overview of their email authentication status. The detailed breakdown of pass/fail rates for SPF and DKIM, alongside DMARC alignment status, is crucial for identifying legitimate sending sources and detecting unauthorized activity.
• RFC 9991: DMARC Failure Reports: Also known as forensic or failure reports (RUFs), these provide anonymized details about individual emails that failed DMARC authentication. While less commonly implemented due to privacy concerns and potential for report volume, RFC 9991 clarifies their format and usage. For organizations with advanced security needs, these reports can be invaluable for pinpointing specific authentication failures and aiding in incident response, offering granular data that aggregate reports cannot.

The overarching theme of these updates is one of refinement and precision. The IETF’s DMARCbis working group meticulously reviewed existing implementations, common challenges, and evolving best practices to produce specifications that are more robust, interoperable, and easier to implement correctly.

The Imperative of Authenticated and Aligned Mail

The modernization of DMARC reinforces an undeniable truth in the email industry: authenticated and aligned mail is no longer optional but a baseline expectation. Major mailbox providers such as Google, Microsoft, and Yahoo have consistently escalated their requirements for sender authentication, culminating in significant policy shifts announced in late 2023 and early 2024. These policies, which took effect in early 2024, mandate DMARC implementation, proper SPF and DKIM setup, and low spam complaint rates for bulk senders. Failure to comply can result in emails being rejected or directed to spam folders, severely impacting deliverability and sender reputation.

Studies and industry reports consistently highlight the effectiveness of DMARC. According to a report by Agari (now Fortra), organizations with DMARC enforced at p=reject or p=quarantine are significantly less likely to be impersonated in phishing attacks. Similarly, data from the Anti-Phishing Working Group (APWG) shows a clear correlation between DMARC adoption and a reduction in brand abuse. These statistics underscore DMARC’s role not just as a technical configuration, but as a critical business defense mechanism. For businesses, robust DMARC implementation translates directly into enhanced brand trust, reduced risk of cyber fraud, and improved customer engagement through reliable email delivery.

Mailjet’s Approach and Guidance for Senders in the New DMARC Era

For Mailjet users, the DMARC update reinforces existing best practices and Mailjet’s inherent system design. A quick DMARC refresher for Mailjet users highlights that the protocol checks whether the domain in the visible From address aligns with authenticated SPF or DKIM results. Critically, DMARC requires only one aligned authenticated identifier (either SPF or DKIM) to pass, not both.

Mailjet’s DKIM-First Default
Mailjet’s default configurations play a significant role in how DMARC is typically handled for its customers. When a user validates a sender domain within the Mailjet platform, the system automatically configures DKIM for that domain. This means that Mailjet signs outgoing emails with a DKIM signature using the customer’s domain. Consequently, DKIM alignment is straightforward when the visible From address uses the same domain (or an aligned subdomain) that has been authenticated in Mailjet. This "DKIM-first" approach is common among ESPs as DKIM signatures are resilient to forwarding and other common email routing scenarios, making them a robust choice for authentication.

The Return-Path / SPF Story
By default, Mailjet uses a provider-owned bounce domain for the Return-Path address, such as bnc3.mailjet.com. The Return-Path domain is the one checked by SPF. Since this is a Mailjet-owned domain, SPF authentication will pass against Mailjet’s SPF records, but it will not align with the customer’s visible From domain. In Mailjet’s default setup, therefore, DMARC commonly passes through DKIM alignment. As DMARC only requires one aligned identifier, this is a perfectly valid and secure configuration.

However, customers who also desire SPF alignment for their DMARC policy can configure a custom Return-Path. This option is typically available on Mailjet’s paid plans and involves a specific setup and support process.

Custom Return-Path with Mailjet for SPF Alignment
For those Mailjet customers seeking SPF alignment in addition to DKIM alignment, a custom Return-Path feature is available. When configured, Mailjet manages a bounce subdomain within the customer’s organizational domain (e.g., bounces.customerdomain.com). This allows SPF to support DMARC alignment under relaxed alignment (aspf=r). Under relaxed alignment, the Return-Path domain (e.g., bounces.customerdomain.com) only needs to share the organizational domain with the visible From address (e.g., customerdomain.com). Mailjet continues to handle bounce processing seamlessly behind the scenes, ensuring deliverability insights are maintained.

It is important to note that a customer can typically only have one active custom Return-Path per API key, and the availability and setup details are dependent on the specific Mailjet plan and the current support workflow. Senders considering or already using strict SPF alignment (aspf=s) must carefully review this setup. Strict alignment requires the MAIL FROM domain (Return-Path) to exactly match the visible From domain, which is generally not achievable with a Mailjet-managed bounce subdomain.

Dedicated IPs and DMARC Alignment
It is also crucial to understand that dedicated IPs, while important for reputation control and deliverability troubleshooting, do not alter DMARC’s fundamental alignment rules. Whether a Mailjet customer utilizes shared or dedicated IPs, DMARC continues to evaluate alignment between the visible From domain and the authenticated SPF or DKIM identifiers. The logic of alignment remains consistent regardless of the underlying IP infrastructure.

Broader Industry Implications and Expert Commentary

The formalization of DMARC through these new RFCs is a significant step towards a more secure and trustworthy email ecosystem. Industry experts have largely lauded the IETF’s efforts, emphasizing that the clearer guidelines will undoubtedly strengthen email defenses across the board. "The updated DMARC specifications provide a much-needed refresh, eliminating ambiguities that could lead to misconfigurations or inconsistent enforcement," states a leading email security analyst. "This formalization will encourage broader, more effective adoption, especially among organizations that might have hesitated due to perceived complexities."

Major mailbox providers are expected to fully embrace these updated specifications. The clearer definitions and formalized reporting structures simplify their validation processes, allowing for more consistent and rigorous application of DMARC policies. This ultimately benefits end-users by reducing the influx of malicious and unsolicited emails into their inboxes.

Furthermore, DMARC’s strengthened foundation lays crucial groundwork for future email security advancements. Protocols like Brand Indicators for Message Identification (BIMI), which allows companies to display their brand logo next to their emails in supported inboxes, rely heavily on robust DMARC enforcement at p=quarantine or p=reject. By solidifying DMARC, the IETF is indirectly fostering the adoption of these next-generation email experiences that enhance both security and brand presence.

Mailjet’s Checklist for the New DMARC Era

For Mailjet customers, responding to the DMARC update involves a clear, actionable checklist:

1. Implement DMARC (If Not Already): For organizations without DMARC, the time to implement is now. Start with a p=none policy, ensuring rua (aggregate report) tags are configured to receive monitoring data. This allows you to gather insights without impacting deliverability.
2. Review and Update Existing DMARC Policies: Existing DMARC policies should be reviewed in light of the new RFCs. While radical changes are unlikely for well-configured domains, it’s an opportune moment to audit for any potential ambiguities or areas for optimization, especially concerning subdomain policies or reporting configurations.
3. Ensure Robust SPF and DKIM Authentication: Verify that all sending domains have correctly configured SPF records that authorize Mailjet (and any other legitimate sending sources). Similarly, confirm that DKIM is properly set up and that Mailjet is signing all outgoing mail. These are the fundamental building blocks DMARC relies upon.
4. Diligently Monitor DMARC Reports: Regularly analyze DMARC aggregate reports (received via the rua tag) to understand email traffic patterns, identify legitimate sending sources, and detect any unauthorized attempts to spoof your domain. Leverage DMARC analysis tools to simplify the interpretation of these XML reports.
5. Strategically Enforce DMARC: Once confident that all legitimate email is passing DMARC authentication and alignment, gradually transition your policy from p=none to p=quarantine (sending non-compliant emails to spam) and eventually to p=reject (blocking non-compliant emails entirely). This phased approach minimizes the risk of inadvertently blocking legitimate mail.
6. Utilize Mailjet’s Features and Support: Leverage Mailjet’s domain authentication features for seamless DKIM setup. If SPF alignment is desired, explore the custom Return-Path option, consulting Mailjet’s documentation and support for the latest setup guidance and availability details based on your plan.

The adage "DMARCbis is dead. Long live DMARC" encapsulates this transition perfectly. For Mailjet senders, this means a reinforced commitment to robust email authentication. Your subscribers may never see your DMARC policy string, but mailbox providers certainly do. The more intentional and precise you are about how Mailjet authenticates and aligns your domains, the more confidently those providers can trust that the mail using your brand genuinely originates from you. This unwavering trust is the bedrock of successful email marketing and communications in the modern digital age.