Why Haven't You Set Up DMARC Yet?

For cybersecurity professionals in email security and anti-phishing, the beginning of 2024 marked the start of an evolution. 

In January, adoption of the email standard for protecting domains from spoofing by fraudsters — Domain-based Messaging Authentication, Reporting and Conformance, or DMARC — became a necessity as companies prepared for the enforcement of mandates by email giants Google and Yahoo. DMARC uses a domain record and other email-focused security technologies to determine whether an email comes from a server authorized to send messages on behalf of a particular organization. 

Yet three months later, DMARC adoption is already starting to taper off, and many companies have completed only the most minimal configuration of their domains, such as setting DMARC to flag issues rather than quarantine or even reject messages. 

Unfortunately, many organizations remain concerned that DMARC is just another security control that, if done wrong, could break critical email services, says Rahul Powar, CEO of Red Sift, a threat intelligence provider.

"Many organizations are rightly concerned that if they go and they do a DMARC policy and it's not correct, that they could block something that's really material to the business, such as a massive marketing campaign, or that the CEO's email won't land in the right inbox," he says. "There's a concern about getting it wrong."

As of the end of April, about 7.9 million domains have some sort of DMARC record (yellow), but only 32% are BIMI ready (green). Source: BIMIRadar.com

However, DMARC — and the underlying technologies of Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) — are not difficult to set up for small or midsize businesses that have simple email infrastructure through a third-party service, such as Google Workspace or Microsoft 365. However, if there are older systems or some segmentation using subdomains, the configuration can get complex — fast, says Gerasim Hovhannisyan, co-founder and CEO at service provider EasyDMARC.

"The problem comes when you have legacy systems and multiple sending sources and infrastructure," he says. "Not only enterprises, but the midmarket can have huge problems during email authentication deployment. It's straightforward or easy to do at first glance, but if you do something wrong, totally valid emails will be rejected."

Here is what to keep in mind when setting up DMARC for your organization.

1. SPF Alerts Recipients to Emails From Nonapproved Sources

The first DNS record that an organization needs to set up is SPF, a string that lists the IP addresses and domain names of the mail servers authorized to send email on behalf of the domain. This record is typically set up through your domain provider or email hosting provider. 

A typical SPF record is a DNS TXT record and looks like:

v=spf1 ip4:192.168.1.1 ip4:192.168.2.1 include:example.com -all

The "v=spf1" designates the string as an SPF record and is required for all SPF records. The "ip4" fields list the IP addresses that are allowed to send email on behalf of the domain and can include network addresses using the slash notation. The "include" tag lists the third-party domains that are authorized to send email for the domain, while the "-all" flag specifies that every other domain is not allowed. Other variants, such as "~all," are possible and specify that mail from other domains are allowed but marked insecure, while "+all" allows any server to send email on behalf of the domain.

While the SPF record is a good first step, spammers could exploit the fact that other organizations using a common third-party server, such as Google's, would be authorized to send email on behalf of every other organization using that server.

2. DKIM Uses PKI to Verify Email Messages

DKIM solves the problem of multiple tenants on the same email server and adds email verification as well. The DKIM selector and key is generated by your email provider and then registered as a TXT record in your DNS service provider. 

A typical DKIM record is a DNS TXT record with a selector — a name — such as "[third party]._domainkey" and a value of:

v=DKIM1; k=rsa; p={public key string}

The "v=DKIM1" designates the TXT string as a DKIM record and is required for all DKIM records. The "k=rsa" designates the type of encryption used for the public-key data, with RSA as the default and other values, such as Edwards-curve Digital Signature Algorithm (EdDSA), allowed as well. The "p=" tag contains the public-key data generated by the email service provider. 

As with any public-key encryption infrastructure, organizations should make sure to regularly rotate the keys for their domain infrastructure, says EasyDMARC's Hovannisyan. 

"We have password management systems or rotating passwords for other [types of] keys, but we don't do that with DKIM keys," he says. "This is something that should be in place and each time something can be broken, you need to have alerting."

3. DMARC Establishes Policies for Email Recipients

DMARC uses the already-established controls of SPF and DKIM and specifies an organization's email policy — not for emails coming into the organization, but for emails claiming to be sent on behalf of the organization. Organizations that specify a DMARC record gain two benefits: They can tell a receiving server what to do with an email that fails authentication — such as allow delivery, quarantine the message, or reject it — and they direct the receiving server to generate reports about any messages sent to the domain. 

The result is that an organization using DMARC gains visibility into how its domain name and brand is being used by unauthorized parties. 

A typical DMARC record is a DNS TXT record with a "_DMARC" and a value that is a string with a number of fields, such as:

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:[email protected]

In this example, the "v=DMARC1" is the required identifier, the authentication policies for both SPF and DKIM at set to strict — as designated by the "aspf=s" and "adkim=s" tags — and the DMARC reports are sent to an organization-specific email at a third-party provider. In this case, the policy is set to reject, but companies can start with a policy of "none" to gain access to the reporting and move to a policy of "quarantine."

4. Check Your DMARC Reports Regularly and Maintain Records

Establishing a DMARC policy is fairly simple, but using the added information as part of an email-security and brand-protection program requires an alerting mechanism and regular oversight. Often companies will just insert a valid DMARC record in their DNS with a policy of "none" and then forget about the added threat intelligence, Hovannisyan says.

"One of the biggest mistakes with DMARCs is [a company saying] that once it's done, I don't need to do anything more," he says. 

Instead, companies should advance through the different policies, starting with "none" but quickly moving to "quarantine" and then finally "strict."

While DMARC can be easy to manage for small companies, large enterprises will likely want to adopt a service to manage the configuration of its email infrastructure and make use of the added capabilities.

"For a small deployment, where you basically just have a Google or an Office 365 on your domain, it's pretty straightforward," says Red Sift's Powar. "I mean, the spec is quite simple, but as soon as you add a little bit of complexity — once you start including a marketing department, an HR department, or maybe a procurement department — you're going to find a lot of senders suddenly start to appear out of your infrastructure."

5. Consider BIMI to Increase Trust

Finally, companies have a fourth standard that can help add more trust to their email messages. The Brand Indicators for Message Identification, or BIMI, standard allows companies to register their logos for use in email clients, but only after they have adopted the maximum level of strictness for their DMARC policies. 

While almost three-quarters of large organizations (73%) have adopted the most basic version of DMARC, the share of those organizations that would pass the most stringent standards vary significantly by nation: In the US, 77% of companies have a strict policy, while only 40% in Germany and 15% in Japan do, according to data from Red Sift. Of all domains, only 3% are considered ready for BIMI, but 32% of the 7.9 million DMARC-enabled domains have strict enough policies to adopt BIMI, according to the BIMIRadar tracking site.