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

The Evolving Imperative of Email Security: A DMARC Foundation

Email remains the primary vector for cyberattacks, with phishing, spoofing, and brand impersonation posing persistent and evolving threats to individuals and organizations worldwide. According to recent cybersecurity reports, email-borne attacks account for over 90% of all cyberattacks, leading to billions of dollars in losses annually due to fraud, data breaches, and reputational damage. In this hostile landscape, email authentication standards have emerged as indispensable tools for establishing sender legitimacy and protecting recipients.

The journey towards robust email authentication began with 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, enabling receiving mail servers to verify if an email originates from an approved server. DKIM, on the other hand, uses cryptographic signatures to verify that an email’s content has not been tampered with in transit and that it genuinely originates from the domain it claims to be from. While powerful individually, SPF and DKIM lacked a crucial policy layer and a feedback mechanism for domain owners to understand how their emails were being treated.

This gap was addressed with the introduction of Domain-based Message Authentication, Reporting, and Conformance (DMARC) in 2012. DMARC builds upon SPF and DKIM by providing a framework that allows domain owners to specify how receiving mail servers should handle emails that fail authentication checks. Crucially, it also provides a reporting mechanism, sending aggregate and forensic reports back to the domain owner, offering invaluable insights into email traffic originating from their domain, including legitimate mail, misconfigured mail, and malicious spoofing attempts. The core principle of DMARC is "alignment," meaning that the domain visible in the From: header of an email must align with either the domain used for SPF authentication (the Return-Path or MAIL FROM domain) or the domain signed by DKIM. If at least one of these checks passes with alignment, DMARC passes.

Over the past decade, DMARC has become a cornerstone of email security, with major mailbox providers like Google, Microsoft, and Yahoo increasingly mandating its adoption for improved deliverability and protection against abuse. Data from leading cybersecurity firms indicates a steady increase in DMARC adoption, with approximately 70% of Fortune 500 companies having implemented DMARC policies by early 2026, though global adoption rates for all domains still hover around 35-40%, leaving a significant portion of the internet vulnerable. This growing expectation from mailbox providers has transformed DMARC from a recommended best practice into an essential requirement for maintaining sender reputation and ensuring message delivery.

A New Era for DMARC: From ‘bis’ to Baseline Standard

The initial DMARC specification, published as RFC 7489, served its purpose admirably for many years. However, as email ecosystems evolved and DMARC adoption grew, certain ambiguities, corner cases, and opportunities for clearer language became apparent. This led to the formation of the DMARCbis working group within the IETF, tasked with revising and updating the standard. The "bis" (Latin for "twice") in DMARCbis signified this ongoing effort to produce a second, refined version of the DMARC specification.

In a landmark development in May 2026, the IETF concluded this extensive revision process by publishing three new RFCs that collectively supersede the original DMARC specification. These are:

• RFC 9989: DMARC: Domain-based Message Authentication, Reporting, and Conformance (the core protocol)
• RFC 9990: DMARC Aggregate Report Format (details the structure and content of aggregate reports)
• RFC 9991: DMARC Failure Report Format (describes the format for forensic or failure reports)

This trifecta of RFCs effectively retires the term DMARCbis, formalizing the updated standard simply as DMARC. The key takeaway from these publications is their emphasis on clarification, refactoring, and modernization. The fundamental "aligned SPF or aligned DKIM" evaluation model remains intact. This means that domain owners who have correctly implemented DMARC according to existing best practices will find their configurations largely compliant with the new standard. The updates primarily address areas such as clearer definitions of terms, improved error handling guidelines, and better alignment with other internet standards, ensuring DMARC’s continued relevance and robustness in the ever-evolving digital landscape.

Technical Refinements: What’s Under the Hood?

While the core functionality of DMARC remains unchanged, the new RFCs introduce several important refinements that enhance its clarity and operational consistency. For instance, there are clearer specifications regarding the processing of DMARC records, particularly concerning the interaction between different tags and their precedence. The documentation for aggregate and forensic reports has been significantly enhanced, providing more precise guidance on their structure, content, and interpretation. This will aid both implementers and tool developers in creating more consistent and interoperable DMARC solutions.

Furthermore, the updated specifications address some of the ambiguities that arose from the original RFC, providing definitive answers to questions that have long been debated within the email community. For example, clarifications might include precise definitions of what constitutes a "valid" DMARC record, how to handle malformed records, and standardized approaches to policy application when multiple DMARC records might theoretically be present (though this is typically prevented by DNS configurations). The aim was to eliminate potential areas of misinterpretation that could lead to inconsistent DMARC enforcement across different mail systems. These are evolutionary steps, designed to make DMARC more robust and predictable, rather than revolutionary shifts that would necessitate a complete overhaul of existing implementations. The focus was on solidifying DMARC’s foundation, making it more resilient and easier to understand for a broader audience of email administrators and security professionals.

Implications for Email Senders: A Renewed Call to Action

For email senders, the updated DMARC specification serves as a powerful reaffirmation of existing best practices: authenticate your email, align your authenticated domains, and monitor your reporting. The message from mailbox providers has been clear for some time: unauthenticated email is increasingly likely to be rejected or quarantined. The new DMARC RFCs simply solidify this expectation at a foundational level.

Organizations that have yet to implement DMARC are now under even greater pressure to do so. Failure to adopt DMARC with an enforcement policy (quarantine or reject) can lead to significant deliverability issues, particularly with major providers. Beyond deliverability, DMARC offers unparalleled brand protection. By preventing unauthorized parties from sending emails pretending to be from your domain, DMARC helps maintain customer trust and safeguards your brand’s reputation against phishing and spoofing attacks.

The data supports this imperative. Studies indicate that domains with DMARC p=reject policies experience a dramatic reduction in successful phishing attempts impersonating their brand – in some cases, by over 90%. This translates directly into reduced fraud, fewer customer service complaints related to phishing, and enhanced security posture. For businesses, DMARC isn’t just a technical requirement; it’s a strategic imperative for cybersecurity and brand integrity.

Mailjet’s Role in DMARC Compliance: Simplifying Authentication for Senders

Email Service Providers (ESPs) like Mailjet play a crucial role in helping their customers navigate the complexities of email authentication and DMARC compliance. Mailjet’s infrastructure and default configurations are designed to facilitate DMARC success, primarily through a "DKIM-first" approach.

When a Mailjet customer validates a sender domain within their account, Mailjet automatically provides the necessary DomainKeys Identified Mail (DKIM) records. These records, typically CNAMEs, point to Mailjet’s signing infrastructure, enabling Mailjet to cryptographically sign outgoing emails on behalf of the customer’s domain. This setup makes DKIM alignment straightforward: if the visible From: address in an email uses the same domain (or an aligned subdomain) that has been authenticated in Mailjet, DKIM alignment is achieved, and DMARC will pass based on DKIM.

The situation with SPF alignment is slightly different due to how ESPs typically handle bounce processing. By default, Mailjet uses a provider-owned bounce domain, such as bnc3.mailjet.com, as the Return-Path or MAIL FROM address. This domain is used to handle bounces and other delivery notifications. While Mailjet ensures that its own SPF records are correctly published for these bounce domains, this default configuration means that the Return-Path domain (bnc3.mailjet.com) will not align with the customer’s visible From: domain. Consequently, in Mailjet’s default setup, DMARC commonly passes through DKIM alignment, as the DKIM signature does align with the From: domain.

It is critical to understand that this is a perfectly valid DMARC passing scenario. DMARC requires only one aligned authenticated identifier (either SPF or DKIM) to pass, not both. Therefore, Mailjet’s default DKIM alignment is sufficient for DMARC compliance.

Custom Return-Path for Enhanced SPF Alignment

While DKIM alignment is sufficient for DMARC, some Mailjet customers may desire SPF alignment as well, perhaps due to internal security policies, a preference for redundant authentication, or specific compliance requirements. For these customers, Mailjet offers the option to configure a custom Return-Path on paid plans.

Implementing a custom Return-Path involves setting up a CNAME record in the customer’s DNS, pointing a subdomain (e.g., bounces.yourdomain.com) to a Mailjet-managed bounce subdomain (e.g., bnc3.mailjet.com). Once configured, Mailjet will use this customer-owned bounce subdomain as the MAIL FROM address for outgoing emails.

With a custom Return-Path, SPF can now support DMARC alignment under relaxed alignment (aspf=r). This is because the MAIL FROM / Return-Path now uses a Mailjet-managed bounce subdomain that falls within the customer’s organizational domain (e.g., bounces.yourdomain.com is part of yourdomain.com). Mailjet continues to handle bounce processing seamlessly behind the scenes, leveraging its infrastructure while presenting a customer-aligned Return-Path.

Customers considering or already using strict SPF alignment (aspf=s) should review this setup carefully. Strict alignment requires the MAIL FROM domain to exactly match the visible From: domain. Since a custom Return-Path typically uses a subdomain (e.g., bounces.yourdomain.com for From: yourdomain.com), it would fail strict SPF alignment. Therefore, for most practical purposes, relaxed SPF alignment is the functional goal when configuring a custom Return-Path with Mailjet. It’s also important to note that Mailjet typically allows only one active custom Return-Path per API key, and the availability and setup specifics may vary based on plan details and support workflows. Senders should always consult Mailjet’s latest documentation and support guidance for the most current information.

It is also worth noting that the choice between shared and dedicated Mailjet IPs does not fundamentally alter DMARC’s alignment rules. Whether using shared or dedicated IPs, DMARC consistently evaluates the alignment between your visible From: domain and your authenticated SPF or DKIM identifiers. Dedicated IPs primarily impact reputation control and deliverability troubleshooting, offering greater isolation and control over sending reputation, but they do not change the underlying DMARC authentication mechanisms.

A Roadmap for Mailjet Senders: Ensuring Continued Compliance

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

1. Verify Domain Authentication: Confirm that all sender domains used in the visible From: address are properly authenticated within Mailjet with correct DKIM records. If a custom Return-Path is desired for SPF alignment, ensure its CNAME record is correctly configured in your DNS.
2. Confirm DMARC Record Presence: Ensure your domain has a DMARC record published in DNS. If not, it’s a critical first step.
3. Review DMARC Policy: Evaluate your current DMARC policy (p=none, p=quarantine, or p=reject). While p=none is a good starting point for monitoring, the ultimate goal should be to move to p=quarantine or p=reject to gain the full protective benefits of DMARC.
4. Analyze DMARC Reports: Regularly monitor aggregate DMARC reports (sent to the rua address in your DMARC record). These reports provide a comprehensive overview of how emails from your domain are being authenticated and handled by receiving mail servers, helping identify legitimate traffic, misconfigurations, and potential spoofing attempts. Forensic reports (sent to the ruf address) offer more detailed insights into individual failures, though their availability and privacy implications should be considered.
5. Ensure Alignment: Continuously verify that your visible From: domains align with either your authenticated DKIM signature or your Return-Path (if custom Return-Path is configured for SPF alignment). Mailjet’s defaults ensure DKIM alignment for authenticated domains, simplifying this aspect for most users.
6. Iterate and Optimize: Use the data from DMARC reports to make informed decisions about adjusting your DMARC policy and refining your email sending practices. This is an ongoing process that helps maintain optimal deliverability and security.

The Broader Impact and Future Outlook

The formalization of DMARC through RFCs 9989, 9990, and 9991 signifies a mature and stable standard that is now officially enshrined within the internet’s technical architecture. This move reinforces the industry’s unwavering commitment to combating email-borne threats and fostering a more trustworthy email ecosystem. For the broader internet community, it means clearer guidelines for implementers, improved interoperability between mail systems, and ultimately, a more secure experience for email users.

Looking ahead, we can expect continued emphasis on DMARC adoption and enforcement. Mailbox providers are likely to become even stricter in their authentication requirements, potentially making DMARC with an enforcement policy a de facto prerequisite for reliable inbox placement. This modernization of DMARC also sets the stage for future advancements in email security, providing a stable foundation upon which new standards and technologies can be built. The goal remains a future where the authenticity of an email sender is beyond doubt, significantly reducing the efficacy of phishing, spoofing, and other malicious email campaigns.

In essence, DMARCbis is dead. Long live DMARC. For the vast majority of Mailjet customers already leveraging authenticated domains and correctly aligned identifiers, the new RFCs will feel less like a seismic operational shift and more like a welcome clarification and solidification of existing best practices. The updated DMARC is not a new challenge but a stronger, clearer framework designed to ensure the continued security and integrity of email communications for years to come.