Is DMARCbis a game-changer or just an upgrade to DMARC?

Back in 2012, when DMARC was first published, it emerged as a revolutionary solution to email-based attacks, which the email infrastructure natively couldn’t block. However, cyberattacks have evolved since then; they have become more sophisticated and complex to detect. 

So far, DMARC has been doing a good job of protecting domains against direct spoofing attacks by ensuring that only authorized senders can use a domain in the “From” field. But as the email ecosystems became more complex and intertwined, the authentication protocol began to fall short on certain fronts. 

For instance, when your emails don’t go directly to the receiving server, they pass through mailing lists, forwarders, or security filters, which modify the email slightly. Even if they make minute changes, such as adding a footer, altering the subject line, or modifying headers, DMARC checks can fail, and your legitimate emails might end up in spam.

To fix this problem, a new and improved version of the protocol is introduced, and it’s called ‘DMARCbis.’ It’s not a replacement, but an upgrade that builds on the original DMARC framework to make it more reliable in today’s complex email landscape. 

Let’s see how the new upgrade is any different from its predecessor, or if it’s just a cursory patch on an already existing one. 

What are the proposed updates in DMARCbis?

Although we have come a long way in email security, there are still some gaps that we need to patch. This is where DMARCbis comes in. It does not come with radical changes like changing the entire authentication method or a complete overhaul of the previous version; it is the small changes that are introduced to improve clarity, security, and interoperability of the protocol. 

Here are some of the upgrades that you should know about:

Rearranging and rewriting the specifications 

One of the first things that the Internet Engineering Task Force (IETF) is introducing with DMARCbis is the rewriting and reorganization of the entire specification. The primary reason for this is to make the protocol easier to understand and implement.

Adding new sections 

To define best practices for all-around protection, the IETF has added a new section called “Conformance Requirements for Full DMARC Participation.”

This section clearly explains what both senders and receivers need to do to ensure full participation in the system.

For instance, as a domain owner, you should make sure your emails pass both SPF and DKIM checks, publish a DMARC record, and actually review the reports you get to spot any problems.

For a mail server like Gmail or Outlook, its primary role is to verify the DMARC records published by others, perform the necessary checks on incoming emails, and send daily reports back to the domain owner.

Upgrades in DMARC tags

DMARCbis also added new tags to give domain owners more control over their domain’s security. IETF came up with multiple new tags so that you can fine-tune how your DMARC policy works and how much data you receive in reports.

For instance, the new ‘np’ tag lets you set a DMARC policy for subdomains that don’t even exist. This is a much-needed addition. Attackers often try to send emails from fake subdomains that were never actually created, like login.yourdomain.com. The new ‘np’ tag ensures that these attempts don’t get through.

Another new tag added to this list is ‘psd’ (public suffix domain), particularly meant for domains like .co.uk or .gov.in that are used by many different users or organizations. It will be used to specify the root domain of the ‘From’ domain using other values. 

There is also a ‘t’ tag in the new upgrade that lets you tell the receiving servers that you’re still testing your DMARC setup. It’s like when you move from pct=0 value to pct=100 value, but in a simpler way by replacing them with binary values— y and n. 

Additional upgrades

There are additional upgrades in DMARCbis that enable you to address real-world email challenges better. 

• Instead of relying on the old Public Suffix List, DMARCbis now uses a DNS tree walk algorithm to more easily and accurately support public suffix domains.
• It also warns against using a strict ‘p=reject’ policy when your emails go through mailing lists, as those can modify the email slightly and break authentication, which means your legitimate emails might get blocked.

Are you prepared for DMARCbis?

Clearly, DMARCbis is not like a simple upgrade to DMARC. It is a more thoughtful shift that aligns your authentication setup with how emails work today. To ensure a seamless transition, it’s essential to understand what remains the same and what you need to revisit. 

Your existing v=DMARC1 records will work just as well with DMARCbis, so you don’t really have to change them. But it is still recommended to review your email setup so that you can make the most of the new features and improvements DMARCbis brings.

For example, when DMARCbis is finally published, check your existing record for outdated tags like pct, rf, and ri, and remove them. You will no longer need them in the new setup.

Once you have removed the older tags, you can add the new ones— np (non-existent policy), psd (Public Suffix Domains), and t (testing mode).

When will DMARCbis be launched?

Now that you know what DMARCbis brings to the table, the next big question is, when can you start using it?

As of now, DMARCbis is in the “IETF Last Call” phase, which is the final stage before it officially launches. So, it is expected to be published sometime in 2025. While there is still some time before you can officially start using DMARCbis, you can begin reviewing your existing DMARC setup, cleaning outdated tags, and preparing to adopt the new ones.

It’s also a good idea to seek expert guidance to ensure your updated setup aligns with the new specification and does not disrupt your email delivery. To know more, reach out to us today!