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

The landscape of email security underwent a pivotal modernization on June 1, 2026, with the official transition of DMARCbis to its simpler, yet more robust, designation: DMARC. This change, while seemingly a subtle nomenclature adjustment, signifies the culmination of extensive work by the Internet Engineering Task Force (IETF) to refine and solidify the globally recognized standard for email authentication. For organizations leveraging email service providers like Mailjet, this update reinforces existing best practices rather than introducing a radical operational overhaul, emphasizing the critical importance of authenticated and aligned mail as the foundational expectation for all legitimate senders.

A New Chapter for Email Authentication: The IETF’s Latest RFCs

In May 2026, the IETF, the premier standards organization for the internet, formally released three new Request for Comments (RFCs) that collectively supersede the original DMARC specification. These documents are RFC 9989, which defines the core DMARC protocol; RFC 9990, detailing the structure and content of aggregate reports; and RFC 9991, outlining the specifications for failure reports. These publications are not merely academic exercises; they represent a concerted effort to refactor, clarify, and modernize the DMARC documentation, making it more accessible, unambiguous, and resilient against emerging threats.

Despite the deep technical nature implied by RFC numbers, the practical implication for email senders and recipients alike is straightforward: DMARC has been updated for the modern era, but its fundamental principles remain intact. The core evaluation model of "aligned SPF or aligned DKIM" continues to be the bedrock of DMARC’s effectiveness. This means that the primary responsibilities for any email sender, including Mailjet customers, continue to revolve around authenticating their email, ensuring the alignment of their authenticated domains, and diligently monitoring their DMARC reporting data.

The Genesis of DMARC: A Brief History of Email Security

To fully appreciate the significance of this update, it is crucial to understand the evolution of email authentication. For decades, email, despite its ubiquitous nature, suffered from inherent security vulnerabilities. The simplicity of its original design meant that it was relatively easy for malicious actors to forge sender addresses, leading to widespread issues like spam, phishing, and business email compromise (BEC).

The first major steps to address these vulnerabilities came with the introduction of Sender Policy Framework (SPF) in 2003 (standardized as RFC 4408 in 2006) and DomainKeys Identified Mail (DKIM) in 2007 (RFC 4871). SPF allows domain owners to publish a list of authorized sending servers in their DNS records, enabling recipient servers to verify if an email originated from an approved source. DKIM, on the other hand, provides a cryptographic signature that verifies the integrity of an email’s content and the authenticity of the sender’s domain.

While SPF and DKIM significantly improved email security, they had limitations. They could operate independently, and their failure often didn’t automatically lead to email rejection, leaving room for sophisticated spoofing techniques. This critical gap led to the creation of DMARC (Domain-based Message Authentication, Reporting & Conformance) in 2012. DMARC acts as an overarching policy layer, instructing recipient mail servers on how to handle emails that fail SPF or DKIM authentication checks, and providing reporting mechanisms back to the sender. It mandates that the visible ‘From’ address in an email must align with either the domain used for SPF (Return-Path) or DKIM (d= domain in the signature). This alignment requirement was the game-changer, tying together the disparate authentication mechanisms and providing a definitive policy for unauthenticated mail.

The "DMARCbis" designation referred to the ongoing revision process undertaken by the IETF DMARC Working Group. "Bis" in RFC terminology often indicates a second edition or a significant update to an existing standard. The journey from the original DMARC (RFC 7489) to DMARCbis and now simply DMARC reflects years of industry collaboration, feedback, and adaptation to the evolving threat landscape and operational realities of email delivery.

Why DMARC Matters More Than Ever: Industry-Wide Adoption and Enforcement

The timing of these updates is not coincidental. Mailbox providers, including industry giants like Google, Yahoo, and Microsoft, have been progressively raising their expectations for email authentication. Recent policy announcements from these providers underscore a clear trend: authenticated and aligned mail is no longer optional but a baseline requirement for maintaining high deliverability and sender reputation. Emails failing DMARC checks are increasingly likely to be quarantined, junked, or outright rejected, regardless of sender content or engagement metrics.

Data consistently highlights the efficacy of DMARC. A 2023 report by the Global Cyber Alliance, for instance, indicated that organizations implementing DMARC at its strictest policy (p=reject) experienced a significant reduction in successful phishing attacks targeting their domains. Furthermore, the number of domains with DMARC records has steadily climbed, with some estimates suggesting over 70% of Fortune 500 companies have adopted DMARC to some degree. This widespread adoption reflects a collective understanding within the cybersecurity and email communities that DMARC is an indispensable tool for protecting both brands and consumers from email-borne threats.

The updated RFCs provide a clearer, more robust foundation for this critical protocol. RFC 9989, the core protocol, refines definitions and clarifies processing steps. RFC 9990 standardizes the format and content of aggregate reports, making it easier for senders to analyze authentication trends and identify potential abuse. RFC 9991, on failure reports (forensic reports), provides more granular detail on individual email failures, though privacy concerns often limit their widespread availability. This comprehensive refresh ensures DMARC remains a relevant and effective standard for the foreseeable future.

DMARC for Mailjet Users: A Refresher on Core Principles

For Mailjet users, the DMARC update serves as a powerful affirmation of existing best practices. DMARC fundamentally checks whether the domain in the visible From address aligns with authenticated SPF or DKIM results. If either SPF or DKIM passes and is aligned with the From domain, DMARC passes. Only one aligned authenticated identifier is required for DMARC to pass, not both.

Mailjet’s robust infrastructure is designed to facilitate DMARC compliance. When a user validates a sender domain in Mailjet, the platform typically configures DKIM authentication by default. This involves Mailjet providing CNAME records that the user adds to their domain’s DNS, enabling Mailjet to sign outgoing emails with a DKIM signature associated with the user’s domain. This "DKIM-first" approach is significant because it makes DKIM alignment straightforward. If the visible From address uses the same domain (or an aligned subdomain) that has been authenticated in Mailjet, DKIM alignment is achieved, and DMARC will typically pass through DKIM.

Understanding Mailjet’s Return-Path and SPF Alignment

The story of SPF alignment with Mailjet, particularly in its default configuration, requires a slightly deeper dive. By default, Mailjet utilizes a provider-owned bounce domain, such as bnc3.mailjet.com, for the Return-Path (also known as the Mail From address). This domain is where bounce messages are sent, and it is the domain that SPF checks are performed against. Since bnc3.mailjet.com is owned and managed by Mailjet, SPF will pass for emails sent through their infrastructure.

However, for DMARC SPF alignment, the domain in the Return-Path must align with the visible From domain. In Mailjet’s default setup, where the Return-Path is bnc3.mailjet.com and the From domain is the customer’s domain, SPF typically passes authentication but fails DMARC alignment. This is a crucial distinction.

Consequently, in Mailjet’s default setup, DMARC commonly passes through DKIM alignment, which is perfectly valid as DMARC requires only one aligned authenticated identifier. This configuration is effective for achieving DMARC compliance for the vast majority of Mailjet users.

Customizing for SPF Alignment: The Custom Return-Path Feature

For Mailjet customers who also desire SPF alignment, perhaps due to specific internal policies or a preference for multi-layered authentication, Mailjet offers a custom Return-Path feature, typically available on paid plans. This feature allows users to configure a bounce domain that is a subdomain of their own organizational domain (e.g., bounces.yourdomain.com).

To enable a custom Return-Path, users typically need to add specific CNAME records to their domain’s DNS, pointing to Mailjet’s bounce handling infrastructure. Once configured, Mailjet manages the SPF records for this custom bounce subdomain. This setup enables SPF to support DMARC alignment under relaxed alignment (aspf=r), because the MAIL FROM / Return-Path now uses a Mailjet-managed bounce subdomain within the customer’s organizational domain. Mailjet continues to handle bounce processing seamlessly behind the scenes.

It is important to note that a customer can generally only have one active custom Return-Path per API key, and the feature’s availability and setup process may depend on the specific Mailjet plan and the associated support workflow. Customers considering or currently using strict SPF alignment (aspf=s) should review this setup carefully, as strict alignment requires the MAIL FROM domain to exactly match the visible From domain, which is typically not the case even with a custom Return-Path subdomain. Mailjet’s documentation and support guidance should always be consulted for the latest behavior and detailed setup instructions.

Dedicated IPs and DMARC: A Clarification

Another common area of inquiry revolves around the impact of dedicated IP addresses on DMARC. While dedicated IPs can offer advantages in terms of reputation control and deliverability troubleshooting, they do not fundamentally alter DMARC’s alignment rules. Whether a Mailjet user utilizes shared or dedicated Mailjet IPs, DMARC’s evaluation process remains the same: it assesses the alignment between the visible From domain and the authenticated SPF or DKIM identifiers. The choice of IP infrastructure is separate from the DMARC authentication and alignment logic.

Actionable Steps for Mailjet Senders in Light of the Update

In response to the DMARC update, Mailjet senders should undertake a structured review to ensure their email programs remain fully compliant and optimized for deliverability:

1. Verify Domain Authentication Status: Confirm that all sender domains used in the visible From address are properly authenticated within Mailjet. This is the foundational step for both SPF and DKIM.

2. Review DMARC Records: Ensure that a DMARC record is published in the DNS for all sending domains. This record should specify a policy (p=none, p=quarantine, or p=reject) and include reporting addresses (rua and ruf) to receive aggregate and forensic reports. Even starting with p=none to gather data is crucial.

3. Analyze DMARC Reports: Regularly review DMARC aggregate reports (RUAs). These XML files provide comprehensive data on email authentication results, showing which emails are passing or failing DMARC, and why. This analysis helps identify legitimate sending sources that might not be correctly authenticated and detect potential spoofing attempts.

4. Confirm Alignment: Specifically check that DMARC reports show a high percentage of emails passing DMARC due to either aligned SPF or aligned DKIM. For most Mailjet users, this will primarily be through DKIM alignment by default.

5. Consider Custom Return-Path for SPF Alignment: If SPF alignment is a strategic requirement, explore configuring a custom Return-Path with Mailjet support. Understand the implications of relaxed vs. strict SPF alignment in this context.

6. Stay Informed: Regularly consult Mailjet’s help center and documentation for any updates or changes to their DMARC support, custom Return-Path features, or general email authentication guidance. The email ecosystem is dynamic, and staying current is vital.

The Broader Implications and Future Outlook

The formalization of DMARC under its new RFCs is more than a technical update; it is a testament to the internet community’s ongoing commitment to building a more secure and trustworthy email environment. By clarifying ambiguities and modernizing the protocol, the IETF has strengthened DMARC’s position as a cornerstone of email security.

For email senders, this means that the pressure to adopt and correctly configure DMARC will only intensify. Mailbox providers will continue to raise their bars, making DMARC compliance a non-negotiable aspect of successful email delivery. For recipients, the promise is a further reduction in spam, phishing, and other malicious emails, leading to a safer digital communication experience.

In essence, "DMARCbis is dead. Long live DMARC" encapsulates a journey of refinement and reinforcement. For the vast majority of Mailjet customers who have diligently implemented authenticated domains and correctly aligned identifiers, these new RFCs should feel less like a disruptive change and more like a welcome clarification of existing best practices. The future of email is undeniably authenticated, and DMARC remains at the forefront of this critical evolution.