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

The landscape of email authentication has reached a new milestone with the formal publication by the Internet Engineering Task Force (IETF) of three updated RFCs (Requests for Comments) that collectively supersede the original DMARC (Domain-based Message Authentication, Reporting, and Conformance) specification. As of May 2026, the protocol previously sometimes referred to as "DMARCbis" has now been officially codified simply as DMARC, signifying a refinement and modernization of foundational email security rather than a radical overhaul. This development, which became publicly effective on June 1, 2026, underscores the growing imperative for robust email authentication in an era of escalating cyber threats and the increasing expectations from major mailbox providers for authenticated and aligned mail streams.

The Modernization of DMARC: A Refinement, Not a Reinvention

The core takeaway from these new RFCs is one of clarification, refactoring, and modernization of DMARC documentation. Fundamentally, DMARC’s foundational evaluation model, which requires at least one of either SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) to be authenticated and aligned with the visible "From" address, remains unchanged. This continuity is crucial for the stability of email ecosystems, ensuring that the millions of domains already employing DMARC for email security do not face disruptive operational shifts. The IETF’s work ensures that the protocol, vital for combating email spoofing and phishing, is updated to reflect current best practices and address ambiguities that may have arisen since its initial publication.

Specifically, the IETF published RFC 9989, which details the core DMARC protocol; RFC 9990, focusing on aggregate reports; and RFC 9991, outlining failure reports. These documents collectively replace RFC 7489, the original DMARC specification from 2015. While the nomenclature "DMARCbis" was often used during the drafting and revision process to denote the "second iteration" or "bis" (Latin for "twice") version of the protocol, its official adoption by the IETF means the protocol now simply reverts to its original, unadorned name: DMARC. This formal standardization through the IETF process elevates DMARC’s status within the pantheon of internet protocols, cementing its role as a critical component of email infrastructure.

Understanding DMARC: A Foundation for Trust

To fully appreciate the significance of this update, it is essential to revisit the core purpose and mechanics of DMARC. DMARC acts as a policy layer built upon two older email authentication protocols: SPF and DKIM. Its primary function is to verify that the domain visible in the "From" header of an email (the address recipients see) aligns with the domains used in either the SPF or DKIM authentication checks. This alignment is critical because threat actors often forge the "From" address to impersonate legitimate organizations, tricking recipients into revealing sensitive information or executing fraudulent transactions.

• Sender Policy Framework (SPF): SPF allows domain owners to publish a DNS record listing the IP addresses authorized to send email on behalf of their domain. When an email server receives a message, it checks the SPF record for the domain in the "Return-Path" (also known as the "MAIL FROM" or "Envelope From") address. If the sending IP is not listed, the SPF check fails.
• DomainKeys Identified Mail (DKIM): DKIM uses cryptographic signatures to verify the authenticity of an email. Senders sign outgoing emails with a private key, and recipients can use a public key published in the sender’s DNS records to verify the signature. This ensures that the email content and certain headers have not been tampered with in transit and that the email truly originated from the claimed domain.
• DMARC Alignment: DMARC introduces the concept of "alignment." For an email to pass DMARC, the domain in the visible "From" header must align with the domain that passes either the SPF or DKIM authentication. This alignment can be "strict" (exact match) or "relaxed" (organizational domain match). DMARC then instructs receiving mail servers on how to handle emails that fail this alignment: p=none (monitor only), p=quarantine (move to spam), or p=reject (block entirely). It also provides reporting mechanisms (aggregate and forensic reports) to give senders visibility into their email streams.

Without DMARC, even if SPF and DKIM are implemented, an attacker could spoof the visible "From" address while using a different, legitimate "Return-Path" or DKIM signing domain, effectively bypassing the security measures. DMARC closes this crucial gap, making it a powerful deterrent against phishing, business email compromise (BEC) attacks, and other forms of email-based fraud.

The Journey to Standardization: DMARC’s Evolution

The journey to DMARC’s formal IETF standardization began with its initial development by a consortium of companies including Google, Microsoft, Yahoo!, and PayPal in 2012. It was subsequently published as an informational RFC (RFC 7489) in 2015. While widely adopted, the "informational" status meant it wasn’t a full internet standard. The process to move DMARC to a "standards track" RFC began shortly thereafter, driven by the protocol’s increasing importance and adoption.

The IETF, a global community of network designers, operators, vendors, and researchers, is responsible for developing and promoting internet standards. Its rigorous process ensures that protocols are robust, interoperable, and well-documented. The "DMARCbis" effort was precisely this process: a working group dedicated to reviewing, clarifying, and formalizing the DMARC specification to meet IETF standards. This involved addressing edge cases, improving clarity in reporting mechanisms, and ensuring compatibility with other evolving internet protocols.

The need for this modernization stemmed from several factors:

1. Escalating Email Threats: The volume and sophistication of phishing, spoofing, and ransomware attacks delivered via email have dramatically increased over the past decade. DMARC has proven to be one of the most effective technical controls against these threats.
2. Increased Adoption and Complexity: As DMARC adoption grew globally, more complex email sending scenarios emerged, highlighting areas where the original specification could benefit from clearer language and more robust definitions.
3. Mailbox Provider Requirements: Major mailbox providers like Google and Yahoo have progressively tightened their email authentication requirements, making DMARC (along with SPF and DKIM) a non-negotiable baseline for optimal deliverability and reputation. This industry push created an urgent need for a universally accepted, updated standard. For instance, Google and Yahoo’s new sender requirements, which began rolling out in early 2024, explicitly mandate DMARC policies for bulk senders, further underscoring the protocol’s criticality.

Diving Deeper into the New RFCs

The three new RFCs provide a comprehensive and updated framework for DMARC:

• RFC 9989 (DMARC: Domain-based Message Authentication, Reporting, and Conformance): This is the core protocol specification. It refactors the original RFC 7489, clarifying definitions, improving protocol message flows, and ensuring consistency. It provides a definitive guide for implementing DMARC policies, covering aspects like policy enforcement (none, quarantine, reject) and the various tags used in the DMARC DNS record. While the underlying logic of "aligned SPF or aligned DKIM" remains, the documentation is now more precise and comprehensive.
• RFC 9990 (DMARC Aggregate Report Format): This RFC standardizes the format for aggregate DMARC reports. These XML-based reports provide senders with high-level statistics on emails sent using their domain, indicating how many passed or failed DMARC checks, and where failures occurred. The new RFC refines the schema and content of these reports, making them more consistent and easier for DMARC analytics tools to parse and present actionable insights. These reports are invaluable for senders to monitor their email ecosystem, identify unauthorized sending, and troubleshoot authentication issues.
• RFC 9991 (DMARC Failure Reports): Also known as forensic or "failure" reports, these provide more detailed, anonymized information about individual email failures. While often more challenging to process due to privacy concerns and potential for information leakage, they can offer deep insights into specific authentication failures. RFC 9991 clarifies the format and conditions for generating and sending these reports, balancing the need for diagnostic information with privacy considerations.

These updates collectively ensure that DMARC is not only a robust technical standard but also one that is clearly documented, making it easier for new implementers to adopt and for existing users to refine their strategies.

Why This Update Matters: Industry Implications

The formalization of DMARC under IETF standards track RFCs carries significant implications across the email ecosystem:

• Enhanced Trust and Security: By solidifying DMARC as an internet standard, the IETF reinforces the global commitment to a more secure email environment. This reduces the attack surface for phishing and spoofing, protecting both organizations and individual recipients. The FBI’s Internet Crime Report consistently highlights email compromise as a leading cause of financial losses, with billions lost annually. Robust DMARC implementation is a direct countermeasure.
• Clearer Guidelines for Implementers: The refactored documentation provides clearer, less ambiguous guidelines for email service providers, DMARC solution vendors, and domain owners. This reduces implementation errors and fosters greater consistency across the internet.
• Improved Deliverability and Reputation: For legitimate senders, adherence to DMARC (and the underlying SPF/DKIM) is no longer just a best practice; it’s a prerequisite for maintaining a strong sender reputation and ensuring high deliverability rates. Mailbox providers increasingly filter or reject unauthenticated mail, making DMARC compliance essential for reaching the inbox.
• Facilitation of Broader Adoption: A formalized standard often accelerates adoption, as organizations can rely on a stable, widely accepted specification. This is particularly important for smaller businesses or those with limited technical resources, who can now more confidently invest in DMARC implementation tools and services.
• Foundation for Future Innovations: A clear, modern DMARC standard provides a stable base for integrating with other emerging email security protocols, such as BIMI (Brand Indicators for Message Identification), which leverages DMARC to display sender logos in inboxes, further enhancing brand trust and recognition.

Mailjet’s Operational Alignment with Evolving Standards

For email service providers like Mailjet, this DMARC update reinforces their existing commitment to best practices in email authentication. Mailjet has long advocated for and supported DMARC implementation among its users. The updated RFCs, rather than necessitating a change in Mailjet’s fundamental approach, serve to validate and clarify their established methods.

Mailjet’s operational defaults are designed to facilitate DMARC compliance for its customers. A key aspect of this is Mailjet’s "DKIM-first" default authentication strategy. When a sender domain is validated within Mailjet, the platform automatically provisions and manages DKIM records. This means that outgoing emails sent through Mailjet are cryptographically signed with a DKIM signature associated with the customer’s authenticated domain.

This "DKIM-first" approach simplifies DMARC alignment significantly. If a Mailjet customer sends an email using a visible "From" address that matches the domain (or an aligned subdomain) they have authenticated with Mailjet, the DKIM signature will align, and the email will pass the DMARC check. Since DMARC only requires one aligned authenticated identifier (either SPF or DKIM) to pass, Mailjet’s default setup typically ensures DMARC compliance through DKIM alignment. This is a crucial distinction and a streamlined path to DMARC success for many users.

Navigating SPF Alignment with Mailjet: The Return-Path Story

While DKIM alignment is Mailjet’s default path to DMARC pass, understanding SPF alignment is also important, especially for customers seeking comprehensive authentication or those with specific policy requirements (e.g., strict SPF alignment). By default, Mailjet uses a provider-owned bounce domain for the "Return-Path" address (e.g., bnc3.mailjet.com). This domain is where non-delivery reports (bounces) are sent. Mailjet manages the SPF record for this bounce domain, ensuring that Mailjet’s sending IPs are authorized.

However, because the default bnc3.mailjet.com differs from the customer’s visible "From" domain, SPF alignment for DMARC typically fails in Mailjet’s default configuration. As established, this is not an issue for DMARC if DKIM alignment is successful. Yet, some organizations may desire SPF alignment as well, for redundancy or stricter internal policies.

For these customers, Mailjet offers the option to configure a custom "Return-Path" on paid plans. This feature allows customers to use a subdomain of their organizational domain for the Return-Path (e.g., bounces.yourdomain.com). When a custom Return-Path is configured, Mailjet manages the necessary DNS records (typically a CNAME record) to point this subdomain to Mailjet’s bounce processing infrastructure. Crucially, Mailjet also publishes an SPF record for this custom Return-Path subdomain, authorizing its sending IPs.

With a custom Return-Path, SPF can now support DMARC alignment under "relaxed" alignment (aspf=r). This means that if the organizational domain of the custom Return-Path matches the organizational domain of the visible "From" address, SPF alignment will pass. This provides an additional layer of DMARC success, satisfying those who prefer both SPF and DKIM alignment. It is important to note that strict SPF alignment (aspf=s) would require the MAIL FROM domain to exactly match the visible From domain, which is typically not the case with Mailjet’s custom Return-Path setup, as Mailjet still uses a subdomain for bounce processing. Therefore, customers considering strict SPF alignment should carefully review their setup and consult Mailjet’s support documentation.

Regardless of whether customers use shared or dedicated Mailjet IPs, the DMARC alignment rules remain consistent. DMARC evaluates the alignment between the visible "From" domain and the authenticated SPF or DKIM identifiers. Dedicated IPs primarily impact reputation management and deliverability troubleshooting, not the fundamental DMARC alignment mechanics.

Key Recommendations for Mailjet Senders

In light of the formalized DMARC standard, Mailjet customers should take proactive steps to ensure their email programs are fully compliant and optimized:

1. Validate All Sending Domains: Ensure that every domain used in your visible "From" addresses is properly authenticated within your Mailjet account. This includes setting up the necessary DNS records for DKIM as guided by Mailjet.
2. Monitor Your DMARC Reports: Actively collect and analyze your DMARC aggregate reports (and forensic reports if feasible). These reports provide crucial insights into your email traffic, highlighting legitimate messages that may be failing authentication and identifying potential unauthorized use of your domain. Tools exist to simplify the parsing and visualization of these XML reports.
3. Ensure Domain Alignment: Verify that your visible "From" addresses consistently align with your authenticated domains in Mailjet, particularly for DKIM. This is the simplest path to DMARC success for most Mailjet users.
4. Consider a Custom Return-Path for SPF Alignment: If your organization requires SPF alignment for DMARC, explore Mailjet’s custom Return-Path feature (available on paid plans). Consult Mailjet’s documentation and support for setup details, understanding the implications for relaxed versus strict SPF alignment.
5. Review DMARC Policy: Regularly review and adjust your DMARC policy (p=none, p=quarantine, p=reject) based on your reporting data. The ultimate goal is to move towards p=reject to maximize protection against spoofing, but this should only be done after thoroughly monitoring and addressing all legitimate sending sources.

Beyond the Protocol: The Future of Email Authentication

The IETF’s modernization of DMARC is not an endpoint but a significant stride in the ongoing evolution of email security. DMARC forms a critical pillar in a broader ecosystem of protocols designed to make email more trustworthy. Other technologies, such as MTA-STS (Mail Transfer Agent Strict Transport Security), which ensures encrypted and authenticated connections between mail servers, and BIMI, which allows verified brands to display their logos in the inbox, build upon the foundation laid by DMARC. These interconnected standards work synergistically to create a more secure and reliable digital communication channel.

As cyber threats continue to evolve, the email industry will undoubtedly continue to innovate. The formalization of DMARC ensures a stable and robust standard for current authentication needs, providing a solid platform for future advancements. For most Mailjet customers already diligently using authenticated domains and correctly aligned identifiers, these new RFCs represent a validation and clarification of existing best practices rather than a major operational upheaval. DMARCbis is officially dead; long live DMARC, stronger and clearer than ever, ready to serve as a cornerstone of digital trust for years to come.