What is DMARC?

This happens more often than we think: an employee receives an email from his boss requesting him to do something.

It might be something as simple as requesting a document.

Or more serious, such as the credentials to the company’s social media accounts. Or to transfer several thousand dollars to some bank account XYZ.

The employee sees the request coming from boss@example.com, then it is a request from the boss. It must be a request from the boss.

It was her name on it!

With this mindset, he dutifully carries on with whatever was requested in the email.

This is a classic email spoofing scenario. Scammers have been doing this for years.

So what is DMARC then?

DMARC, then, is an Internet protocol designed to prevent that type of scenario happening.

If DMARC was properly configured on the above company’s email servers, the employee would never see the email pretending to be coming from the boss, but that actually was sent by a scammer using an untrusted server.

You may ask, how come an untrusted server can send emails on behalf of your company?

Well, Internet email was created on the basis that its users could be trusted.

Unfortunately that’s not true anymore.

However, this trust paradigm is still present on the basic email protocols, and cybercriminals have been taking advantage of this to scam people.

In a sense, DMARC (which, by the way, stands for Domain-based Message Authentication, Reporting and Conformance) is an upgrade to the email protocols that adds security to Internet messages.

How does DMARC work?

DMARC works by sending instructions to email providers, such as Gmail and Yahoo! Mail, about how to check the emails they receive pretending to be from your company.

Most importantly, with DMARC you can also tell providers what to do when they catch a potential spoof attempt.

Technically speaking, DMARC – and its auxiliary protocols SPF, and DKIM – work by adding special instructions to a domain in the form of TXT records (see The DMARC DNS record below).

On top of giving instructions to providers about how to handle your emails, DMARC allows you to ask email to send you periodic (usually daily) reports about how they have actually delivered your messages.

That’s exactly it: with DMARC you can get reports from Google, for example, telling you how many of your emails they accepted on Gmail, how many got sent to user’s spam folders – or how many were rejected altogether.

That looks interesting, doesn’t it? We will talk more about DMARC reports later.

At this point, all you need to know is that this is all done behind the scenes. Once you properly configure DMARC the magic of dealing with spoofed emails begins.

Before we continue explaining how DMARC works, let’s briefly see how it is implemented technically. This will be useful to understand other concepts we will talk about later in this post.

The DMARC DNS record

DMARC works by configuring a DNS TXT record at an address named _dmarc under your domain.

For example, if your domain is example.com, then your DMARC record should be setup at _dmarc.example.com.

This is how a DMARC record looks like:

v=DMARC1; p=reject; rua=mailto:a-1-1-xzza@inp.dmarcpal.com,mailto:bob@example.com

The example record above is composed of tags separated by semicolons (“;”). Here’s what each tag means:

• v=DMARC1 confirms that the DNS record is a valid DMARC record.

• p=reject is the DMARC policy. This tells emails providers that all emails that fail DMARC check should be rejected.

• rua=mailto:a-1-1-xzza@inp.dmarcpal.com,bob@example.com defines where DMARC reports should be sent to. As you can see, DMARC reports can be sent to more that one address.

A few other commonly use tags are:

• pct=N tells provider that the DMARC policy should be applied only to N percent of emails. N must be a number between 0 and 100. This is usually used for testing.

• sp= is the DMARC policy to be applied specifically for subdomains. Accepts the same values as the p= tag.

• aspf= and adkim= are SPF and DKIM alignment to be considered when checking an email, respectively. Values can be s for strict, or r for relaxed (the default). Check What is SPF? and What is DKIM? to understand how alignment works.

The DMARC policy (tags p= and sp=) are the ones that tell the providers what to do with emails that fail DMARC checks. You can use the following values on those two tags:

• none - Do nothing. Just accept the email. This is usually used for testing while implementing DMARC.

• reject - Reject the email.

• quarantine - Neither accept, nor reject the email. Usually this means “accept, but save the email to spam/junk folders”.

We will be talking about DMARC policies later in this post, but for know we need to talk a little about SPF and DKIM.

SPF and DKIM

DMARC stands on the shoulders of two giants: SPF and DKIM.

These are the two Internet protocols used by DMARC-compliant email servers to check the origin and legitimacy of an email.

We won’t go into much details about SPF and DKIM here. For more details about those, check out our posts What is SPF? and What is DKIM?.

Suffice to say, though, that SPF is used to check if an email server is allowed to send emails on behalf of a domain name.

On the other hand, DKIM is used to digitally sign the “From” address (along other data) of an email.

Let’s use Gmail as an example. For each email Google receives pretending to be from your company they’ll do this:

• Check SPF to see if the email server got the message from is authorized to send emails from your company.

• Then, they’ll use DKIM to determine if the “From” field is legit, and hasn’t been tampered. They do that by checking the DKIM digital signature attached to the email against the public key signature they got from the DNS.

• If either checks pass and are aligned with your DMARC configuration, then this will tell Google that the email is legit and can be delivered to the end user.

If neither SPF or DKIM passes, then we probably have a spoofed email…

A spoofed email. What now?

At this point, assuming that SPF and DKIM are properly configured and the email failed both checks, Google has three alternatives:

1. Ignore the checks, and deliver the email anyway;
2. Reject the email; or
3. Compromise – don’t reject, but don’t deliver. How? By saving the email to the user’s Spam folder, for example.

Clearly option #1 is bad. They know that an email isn’t legit. It just feels wrong to put it in their user’s mailbox?

Option #2 seems sensible, but... wait. What if people have just configured their email system? What if DNS hasn’t propagated yet (SPF and DKIM put their configuration on the DNS too)? Just rejecting an email doesn’t sound sensible anymore. It may be an important email.

Option #3 is a compromise, with all the pros and cons of the two other alternatives.

So how does Google decide?

They don’t!

In your domain’s DMARC configuration, you have that p= tag (the DMARC policy, remember?) that tells Google – all email providers, actually – what to do when they find a potentially spoofed email from your domain.

Basically you tell them what course of action to choose, amongst the three above.

The trick part is: how do you choose?

That’s when DMARC reports come into play.

DMARC reports

One of the greatest features of DMARC is the periodic reports you get telling you how email providers have handled messages they got from your domain (deliver, reject, send to span, remember?).

Once DMARC is properly configured, you will start to get those reports from Google, Outlook.com, etc., right into your mailbox. Plain and easy.

Each report comprises a period of time – usually a day – and contain several lines (called DMARC records) with information about how many emails they got, the email server they got the emails from, the results of SPF and DKIM checks, and – most importantly – the DMARC outcome: deliver, reject, or quarantine.

With this information in hand, and control over your DMARC, SPF, and DKIM configuration on the DNS, it is possible to implement a controlled DMARC roll-out process, where you first set your DMARC policy to “none” (check, but accept all emails), monitor reports for a while, fix all legitimate email servers that are failing DMARC, check reports a little more, move to a “quarantine” policy, monitor…

Once you’re confident that all your email servers are properly configured and authorized, and that you’re not seeing failed DMARC checks on the reports, you can set your policy to “reject”, and keep monitoring.

At this point, your domain is protected. All spoofed email will be blocked by the email providers.

That is easy to understand. Sounds easy to implement too, doesn’t it?

Well, the concept is easy to understand and, to a certain extent, easy to implement.

There’s a problem, though. A big problem…

The anatomy of a DMARC report

According to Statista, almost 320 billion emails were sent per day, on average, in 2021.

Shy of 320B. In a single day.

A big chunk of those messages flow through big providers like Gmail and Outlook.com. And for each email they get, they need to make sure it goes to the right person, all span checks are done, viruses are eliminated, etc. That’s a lot of work.

To implement DMARC, they would also need to keep track of all email servers they got messages from, aggregate all the data, and send back reports to all interested parties. That last step alone means sending thousands and thousands of emails every day to domain owners.

That is a heck lot more work!

The designers of the DMARC protocol were sensible to the challenges already imposed on email providers, and the burden a new reporting system would be. With that in mind, and to facilitate the implementation of DMARC, they specified that DMARC reports would follow a specific, machine-readable format that is simple for a provider’s email server to compute and store.

This would ease the implementation of DMARC by everyone, and make the Internet a more secure place.

They were right. DMARC is now a widely adopted protocol that made the Internet Safer.

The keyword here, though, is “machine-readable”.

How do you open a DMARC report?

Soon after you configure your domain to receive DMARC reports, you will start receiving in your mailbox many emails with the reports, from many providers around the world.

When you open those emails, you see that they only contain attached files. No nicely formatted tables. No Excel spreadsheets.

Not even an explanation of what to do next…

If you try to open the attached files, you’ll probably see your computer complaining that it does not have an application that understands those files. And even if you manage to open a file, it is very likely that you won’t understand what you’ll see.

The reason is simple: as we saw earlier, DMARC reports are designed to be machine-readable.

In other words, you need a specialized tool to open a DMARC report.

You need a specialized tool to open DMARC reports

The subtitle says it all. You need a tool to open the reports, compile the data, and present them in a way that can be useful to implement DMARC and secure your domain.

Such a tool can be as simple as a one-to-one translator of raw DMARC data to a format that you (at least!) can comprehend.

Or they can be full-featured, and present the reports in nicely formatted pages, allowing you to sort records, filter, view reports or records at email provider level, etc.

Those tools usually work by allowing you to upload daily DMARC reports, or they receive the reports directly. They then do all the processing, and translate the raw DMARC data into useful, human-readable reports you can use.

DMARCPal is an example of a full-featured tool that helps you secure your domain with DMARC. With DMARCPal, you get a DMARC record address that connect your domain directly to our platform. This in turn will connect the service directly to email providers, so you do not need to periodically upload anything. DMARCPal will receive all machine-readable reports, process them, and present them to you in simple and uncluttered web pages, allowing you to browse and sort the data to get all the information you need for a successful DMARC roll-out. On top of that, you get access to many additional tools designed to implement a smooth roll-out of DMARC to your domains. See the features page for more info.

Wrapping up what is DMARC

In a nutshell, DMARC is a protocol that works together with SPF and DKIM to give domain owners control over how providers like Gmail and Yahoo! Mail can check messages they receive pretending to be coming from your company, and act according to whatever instruction you give them when they find a spoof attempt.

In addition to that, you can receive reports summarizing how the providers have handled your emails. For example, the reports can tell you how many emails were delivered, and how many sent to Spam folders. With this information in hand, you can execute a safe roll-out plan of DMARC to your domains that will shield it against spoof attempts, and improve your email deliverability

Lastly we saw that DMARC reports are machine-readable, so you need a specialized tool to open, and present them in a way that you can understand. Fortunately, DMARCPal is a tool that can do that, while also allowing you to filter and sort all DMARC data for easy finding of misconfigured email servers, and identification of the origin of emails spoofing your domain name. This is invaluable information for a smoother DMARC roll-out process.

So that’s it. We hope that this post has helped you understand what DMARC is. Happy emailing!