Deliverability starts with a D (that’s DMARC)

What's DMARC got to do with deliverability?

You might have come across DMARC, which stands for Domain-based Message Authentication, Reporting & Conformance. It is an email protocol that many people are familiar with or even utilize. It presents a classic scenario of the "egg and chicken" situation.

The recommended approach is to start by implementing SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) for domain authentication. Then, consider using DMARC as the next step.

DMARC is not a domain authentication protocol. It is still safe and possible to send emails securely without implementing DMARC. However, it is worth incorporating DMARC because it can be beneficial along the way - after completing the DMARC journey (sounds like an adventure, because it is). According to a study by Yahoo, they have seen an increase in open rate when DMARC is enforced (more on that later).

Note: Sella will be leading a discussion on this blog post during the OI-members-only Live Zoom on Thursday, August 3, 2023. OI members -- see you there!

Not a member? Join today -- or reach out to Jeanne, our general manager, to learn more.

DMARC first

I can understate the reason behind the (bad) advice to implement DMARC only AFTER implementing SPF and DKIM. That's because DMARC relies on two email authentication protocols: SPF and DKIM. SPF allows email senders to define which IP addresses are allowed to send mail for a particular domain. DKIM allows the receiving side to check that an email claiming to have come from a specific domain was indeed authorized by the owner of that domain. DMARC will put the two domain authentication protocols (SPF and DKIM) into context.

What is DMARC?

DMARC is an email protocol designed to protect an organization's domains and brands from being used for email spoofing and phishing.

A DMARC record is a TXT record in your domain's DNS. This record instructs mail servers on how to handle emails that claim to be from your domain but fail SPF or DKIM checks. The receiving side also generates DMARC reports that are sent to a specified email address. Here is where the magic happens (or not. That's dependent on you).

Sometimes, when examining DNS domains, you may come across DMARC records that are ineffective or even detrimental to deliverability. For example, a DMARC record that looks like this: V=DMARC1; p=reject. This record is useless and may negatively impact deliverability. Similarly, a DMARC record like this: ‘V=DMARC1; p=none’ is also useless.

Unfortunately, DMARC is often overlooked, not only by small and medium-sized businesses but also by banks, insurance companies, and Fortune 500 companies. Many either fail to implement DMARC or implement it incorrectly, potentially putting their clients at risk. By correctly implementing DMARC (the DMARC journey), brands can improve deliverability and reduce the risks of phishing and impersonation.

Check out the adoption reports available here. And here.

DMARC aggregate reports

The DMARC reports generated by the receiving side are in a non-human-readable XML format. In order to analyze the reports, you need to use a DMARC monitoring tool (see recommendations below). This is also the reason why there is no point in receiving the reports to your regular mailbox email address. I bet you will not be able to examine the XML files effectively.

An initial DMARC record will look like this:

DMARC reports show your mail servers (your servers and third-party infrastructure) that send emails on your domain’s behalf. This allows you to fix incorrect domain authentication settings on these servers.

The reports include details such as: who sent (from, mfrom), the IP address from which the email was sent, the authentication status (SPF, DKIM authentication and alignment), the policy that was received and the policy that was implemented in practice by the receiving party (in some cases the receiving server is downgrading the policy).

What's more, DMARC reports will flood malicious systems that may be impersonating your domains. After all, this is the primary goal of DMARC to protect your domain from abuse and impersonation.

The foundation

Nowadays a strong technical email setup is essential as it is the foundation for ensuring deliverability. The implementation of DMARC can aid in the accomplishment of that objective. One of the first things I do as a deliverability consultant is implement DMARC using a DMARC reporting tool. This helps me to discover all the email platforms that are used for emailing under that brand domain.

DMARC should be the first protocol that all email senders should adopt, as it helps to identify and address email authentication issues.

Source: BIMI Radar

The DMARC journey - climbing the DMARC mountain

DMARC is like embarking on a journey to reach the summit of a majestic mountain. There are summits along the way for climbers to rest before continuing to the next level.

The DMARC journey starts with a monitoring only policy (p=none), monitoring the reports in a DMARC reporting tool (see below), and acting accordingly.

You move on to fixing email authentication on all email sending platforms and only then do you climb to the next level (p=quarantine) until the goal is reached (p=reject), the monitoring continues.

If a brand completes the DMARC journey until enforcement, it can reach a higher level by adding a BIMI record and obtaining a VMC certificate. As a bounce, this will result in the brand getting a blue checkmark on Gmail.

The end goal: an enforcement policy

DMARC reporting tools

Easydmarc (this is my favorite)
Dmarc digests
Cloudflare (in beta)
Dmarcly
MXToolbox
dmarcian
kdmarc
dmarcanalyzer
Dmarc report
Kickbox (part of their deliverability tool)
Glockapps
And here are several other tools.

Source: dmarc.org

DMARCbis - DMARC 2.0

DMARC 2.0, also known as DMARCbis, isn't vastly different from the existing DMARC. It maintains backward compatibility.

The primary aim of DMARC 2.0 is to simplify many aspects that were previously misunderstood, improperly utilized, or not implemented at all. For instance, certain features or attributes, such as the percentage (PCT tag), are being eliminated due to their complexity and the difficulties they posed for implementation on the receiving end.

The reporting interval (ri tag) is also being removed, as it was largely disregarded. The majority of recipients (receiving side) produced reports based on their own schedules, which appeared to be more reasonable. Additionally, there will be a modification in how DMARC is retrieved from the DNS record.

This change will impact subdomains and their parent domains. This was originally based on the Public Suffix List (PSL). If you had a DMARC record at the specific subdomain level, it would be used. Otherwise, it would default to the domain at the organizational level. However, this became complex to understand and implement when dealing with multiple levels of subdomains, leading to confusion.

The reliance on the Public Suffix List also added to the complexity. The new version will employ a TreeWalk method, which will examine each level above until it reaches the top. These are the primary changes in DMARC 2.0.

Please note that DMARC 2.0 is still in the draft stage. It was discussed at M3AAWG (June 2023). However, we will need to wait until it becomes an RFC.

To sum up:

The process of implementing DMARC can be quite intricate, particularly for organizations of a larger scale. You should definitely consider collaborating with an email security and authentication expert to ensure the correct implementation. This is how you can improve your email deliverability and enhance email security.

Resources

DMARC record checker (HTML code)

DMARC record generator