What is DMARC? How it works and why you need it

According to Statistica, about 293 million emails were sent every day in 2019. Fact is, email is a critical part of our personal and work lives.

But email has a downside – it can be a big security vulnerability. The FBI estimates that email-related scams have resulted in worldwide losses of at least $26 billion since 2016.

To reduce the security vulnerabilities that arose from email, a relatively new email authentication protocol called DMARC was created. DMARC is an acronym for Domain-based Message Authentication, Reporting, and Conformance.

It builds on already established email authentication protocols like SPF and DKIM, allowing email sending organizations to set a policy for how Inbox Providers (Gmail, Yahoo, Outlook, etc) should handle emails coming from their domains.

What is DMARC, in a nutshell?

• It checks whether email authentication is being used, by matching the domain in the email from address to the sender domain (SPF and DKIM). An example of this would be sending an email from hello@getvero.com with getvero.com as the authenticated domain.
• It tells email receivers, based on your instructions, what to do if an email either fails or passes authentication checks.
• Finally, it sends you aggregate reports on emails sent using your domain, whether they’re from you or not.

If your business uses email in any form, here’s how DMARC can help you:

Benefits of DMARC

1. It brings transparency to your email activities, allowing you to see who and what is sending emails on the Internet with your domain.
2. DMARC allows you to stop the unauthorized use of your email address by fraudulent groups or individuals. It protects you, your coworkers, and customers from email-related scams.
3. DMARC makes emails identifiable – as either legitimate or illegitimate — across an increasing collection of DMARC-capable inbox providers. This allows spam to be flagged faster than current email filters allow, resulting in a safer inbox for everyone.

DMARC is a great addition to email authentication, but before we cover how you can set it up, let’s take a quick look at how it works.

How does DMARC work?

To fully understand how DMARC works, you have to understand what a DNS record is. And you also have to learn how email authentication protocols like SPF and DKIM help make emails safer, because DMARC relies on these established protocols.

What is a DNS record?

DNS means Domain Name System. It’s a key part of the Internet that’s responsible for translating domain names like “getvero.com” into their equivalent IP addresses that machines can read. For getvero.com, for example, it’s 96.126.108.187.

A DNS server is a type of computer server that manages domain names and their associated records. A domain’s DNS record contains important information about a domain, and email authentication protocols rely on this record.

Email authentication protocols

SPF: This stands for Sender Policy Framework. It’s an email authentication protocol used to prevent spammers from sending messages on behalf of your domain. SPF allows you to publish a list of mail servers that you send emails from, as a record on your DNS.

With an SPF record, you’re essentially telling email receivers (Gmail, Yahoo, etc.) that if an email is not from a server on your SPF record, it should be treated as if it’s not from your organization.

DKIM: It stands for Domain Keys Identified Mail. It’s another email authentication protocol that allows email receivers to verify that an email was sent, and authorized by the owner of that domain.

It does this by adding an encrypted digital signature to the header of the email, which signifies to the email receiver that an email has not been tampered with.

All of this is done on the server level, so end users usually don’t see it happen. But you can check whether an email uses either SPF or DKIM authentication. If you’re using Gmail, all you have to do is click on the drop down icon to get the sender’s information.

Here’s an example based on an email that I received from Brandon, an account executive with Vero.

The “mailed-by” text in this email means that this email is authenticated with SPF, and the “signed-by” means that it’s also authenticated with DKIM.

Notice how both are from getvero.com?

So I know for a fact that this email came from Brandon and wasn’t tampered with enroute to my inbox. You may be thinking, “If SPF and DKIM already authenticate emails, then why does anyone need DMARC?”

The problem with email authentication

Current email authentication protocols on their own either have loopholes that can be exploited or are held back by incorrect configurations.

For example, SPF is easy to fool because it authenticates an email by checking for an SPF record at the DNS record of the domain that sent the email. Instead of just the domain the email claims to come from.

So if someone sends an email from spammer.com, but spoofs the email so people see the “from address” as domain.com. SPF will check spammer.com for the SPF record and unfortunately it will match because it’s controlled by the spammer.

Domain mismatches can happen, even in legitimate emails when a mailbox rule forwards a message from another domain. So it’s hard for email receivers to differentiate between legitimate and scam emails using just SPF.

DKIM is safer…if your organization uses it

DKIM, on the other hand, is a much safer authentication protocol, but not every organization has both DKIM and SPF authentication enabled. And even those that do may not have all their email sending accounts verified.

So when an email receiver like Gmail receives an email that claims to be from a company, it doesn’t know if it’s a scam, just improperly configured, or an unauthenticated account.

To show just how easy it is to falsify an identity with email, I spoofed an email from the getvero.com domain name, after just a few minutes of web research.

Since Vero has both SPF and DKIM authentication, Gmail immediately marked the email as spam. Unfortunately, not all email receivers are that smart. Also, the fact that an email is in your spam folder gives it a small chance of being retrieved.

A few minutes on the Internet is all it takes to steal an identity through email.

This is where DMARC steps in. It doesn’t only check whether an email is authenticated with SPF and or DKIM, but it also helps businesses specify what they want to do with emails that fail these authentication protocols.

With DMARC, a company can tell email receivers to automatically reject any email that’s not authenticated.

For example, DocuSign, the electronic signature company, has a DMARC reject policy. So when I tried sending an email to myself with their domain, it didn’t even end up in the spam folder. Gmail had rejected it instantly.

We’ve covered what DMARC is, now let’s go over what a DMARC record looks like.

What does a DMARC record look like?

DMARC records are publicly accessible on a website’s DNS records. You can check whether a company has a DMARC record and what their policies are, with tools like MXtoolbox or the DMARC inspector.

Here’s Docusign’s DMARC record:

v=DMARC1; p=reject; sp=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; rf=afrf; pct=100

And here’s Vero’s:

v=DMARC1; p=none; pct=100; rua=mailto:re+mcfawmzsmwc@DMARC.postmarkapp.com; sp=none; aspf=r;

What do these different tags and values mean?

v=DMARC1; – Every DMARC TXT record has to begin with the version tag set to the value of ‘DMARC1.’ This allows email servers to know that this DNS record defines a DMARC policy.

p=none; – The p tag, also known as the policy tag, allows the sending domain to state how they want emails that fail authentication to be handled by email receivers.

The three available options are:

• None: This signifies that the email server shouldn’t take any action. This usually means that the sending domain is in test mode and is in the process of implementing DMARC.
• Quarantine: This value tells the server to quarantine the email, which usually means marking it as spam.
• Reject: With this, you’re instructing an email server to reject the delivery of an email if it fails authentication checks.

pct=100; – This DMARC tag specifies the percentage of emails that will be subjected to filtering. For example, if pct was set to 50, it would mean that only half of a company’s emails will be filtered by the recipient.

rua=mailto: – This is where you want all your aggregate DMARC reports sent to. Depending on how many emails you send, this can be a lot to process. They’re also sent in XML format, so you shouldn’t use your regular work email for this.

sp=none; – This tag simply specifies your handling policy for emails sent from subdomains.

aspf=r; – The aspf tag indicates the SPF identifier alignment portion of your DMARC policy. SPF identifier alignment basically means that an email’s “From” and “Mailed By” addresses are similar. You can set your SPF alignment policy to either be:

• Relaxed (r): Both “From” and “Mailed-By” addresses must be an exact match or a parent/child match, for example, domain.com and mail.domain.com.
• Strict (s): They must be an exact match to pass and anything else will fail. Domain.com will not work with mail.domain.com.

Note that only the version and policy tags are required for a DMARC record to be valid, the other tags are optional but recommended.

How to set up a DMARC record

We’ve talked about what a DMARC record is, why it’s important, and how it works. Now we’ll walk you through setting up a DMARC record for your domain.

Creating a DMARC record is a relatively simple process and there are even tools to help you generate one. However, DMARC can get complicated because it relies on authentication protocols like SPF and DKIM, which are a bit harder to setup.

So we’re going to assume that you already have both SPF and DKIM authentications setup.

Step 1.

Create a DMARC record with your policy. You can either write it yourself or use a tool like the DMARC generator which, through a user-friendly interface, lets you select which tags you want to apply and their values.

Here’s an example of what this looks like:

It then generates a DMARC record you can use in your DNS.

It’s recommended that you start your DMARC policy at none. Until you get a handle on who sends emails in your organization, this allows you to properly setup SPF and DKIM authentication on those accounts.

Note that the rua and ruf tags are set to their own addresses, and you’ll have to point this to the address where you want to receive the reports.

Step 2.

Create a new TXT record in your DNS and fill it with your DMARC record.

If you’re using Godaddy, it should look like this:

Step 3.

Monitor your email activity and adapt your DMARC policy.

Three recommended phases for DMARC setup

1. Set DMARC policy to “none:” As stated earlier, it’s recommended to begin with a DMARC policy set to “none.” This prevents deliverability failures that could happen if email authentication isn’t properly set up.

2. A DMARC policy set to “none:” This allows you to monitor emails from first and third-party sources being sent on your behalf. It also reports email authentication failures, some of which might be from legitimate sources, so you can fix them.

3. Set DMARC policy to quarantine: It’s recommended that you set your policy to quarantine a small percentage of emails that fail authentication, for example 10% or 15%.

When you set your DMARC policy to quarantine you’re indicating to inbox providers that if an email fails authentication it should be treated as suspicious.

In most cases these emails are sent to the spam folder but it’s ultimately up to inbox providers to choose how to handle these emails. This can simply be done by changing your DMARC record to: p=quarantine;

pct=10; Starting at 10% allows you to check whether DMARC implementation is affecting your email deliverability rates and if it is only a small percentage will get affected rather than all of it.

As you become more confident that all of your organization’s emails are authenticated you can slowly raise the percentage of emails to be quarantined.

4. Set DMARC policy to “reject:” As you continue to get reports from DMARC about what legitimate email sources are unauthenticated, you can start fixing them.

Once you’re certain that your legitimate email sources are all authenticated, you can set your policy to reject (p=reject;) and remove the pct tag entirely.

The way forward

A DMARC policy is an important part of ensuring that you, your coworkers, and customers, are safe from email fraud.

It protects your business and your customers from fraudulent attacks and helps boost your reputation in the eyes of ISPs. It’s not a question of if you should have a DMARC policy, but how quickly you should implement one.

The policy should be rolled out in phases to ensure that every legitimate email sending source from your organization isn’t affected.

The more domains there are on the web using DMARC, the safer the entire email ecosystem becomes.