DMARC
Domain-based Message Authentication, Reporting & Conformance

Anyone can send emails that appear to come from your domain. DMARC is a way to let email servers know what emails are actually coming from you, and how they should treat emails claiming to be from you.

With a DMARC policy in place on your domains, email providers (like Gmail and Outlook) will start investigating emails coming from your domains. They'll report back to you when fraudulent email messages are received and even block those email messages from ever reaching their recipients.

For example, you can say "I send emails from MailChimp and Convertkit. If you, dear mailserver, receive an email claiming to be from emailsherpa.com, and it is not from one of those senders, please put it into the spam folder immediately."

Why is DMARC needed?

A big problem inherent in email is the fact that a recipient cannot know if an email was actually sent from whoever claims to have sent it. All emails has a header telling the recipient who sent the email, but they can claim to be anyone.

It's a bit like you calling people on the phone, telling them you're the pope [1]. The receiver only has your phone number and your guarantee that you are who you claim. It is up to them to evaluate if you're telling the truth. Luckily most people will catch your ruse, but email servers aren't that clever.

Control and visibility

DMARC provides a way for senders to specify how recipient servers should handle non-authenticated emails. In addition to this, it provides a reporting framework making it possible to get insights into what email servers actually recieve.

How it works

DMARC is not a standalone technology. It builds on top of SPF and DKIM to prevent spoofing from their domains.

In short, an email passes DMARC if:

Domain alignment basically means that the domain name should be the same.

Gradual rollouts

A big benefit of DMARC is the ability to roll it out gradually. You can start out just in monitor mode, where you're getting nothing but visibility into what emails are being sent from your domain.

When you're confident your legitimate messages are passing the authentication checks, you can request that failing messages get quarantined.

And finally, when you've been quarantining mails for a while without problems, you can start request them being rejected entirely.

What does a DMARC record look like

To opt in to DMARC for your domain, you have to add a DMARC DNS record to your domain. It's added as a TXT record on a subdomain called _dmarc.

So for example if your domain is emailsherpa.net, you'd add a TXT record for _dmarc.emailsherpa.net to enable DMARC. The value for a simple DMARC record could look like this:

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

The above DMARC record consists of 3 parts:

Policies

DMARC reports

The reports you receive as part of the DMARC compliance process come in two different versions:

Common for both report types is the fact, that they are sent via email, are in XML format and very hard to read for normal human beings. Typically you'd want a service to help you parse and understand the reports.

Aggregate reports

Aggregate reports gives an overview of all emails received by an email server for a given domain. They are sent to the email address specified in the DMARC record under the `rua` key, usually once every day.

Forensic reports

Forensic reports - or failure reports - are sent to the email address specified in the DMARC record whenever an email fails the DMARC checks. They are detailed reports and contain information about that single email.

However, due to their detailed nature, they contain information that can be seen as personally identifiable, which has led to privacy concerns. Thus, most services no longer generate and send those reports.

Resources