What does DMARC do, exactly?

It puts you back in control if your domain's email

In order to explain what DMARC does, I need to give you a brief introduction into how email works for your domain name.

Let's say you have a great business idea, so you go and buy a domain name. I've always dreamed of opening a pirate themed gym called "Slimmer Ye Timbers!" where people can work on their Arrrms and walk the Planks. The marketing kinda writes itself and be honest, you're a little curious right now.

Anyway, say I go out and buy the domain slimmeryetimbers.com for my website. Then I have to get a hosting company and setup a DNS record to point slimmeryetimbers.com to that web host to so people go to the right place when they visit the domain.

Email doesn't work like that. If I setup a mail server and point to it with an MX DNS record so that people can send messages to my new arrrgh@slimmeryetimbers.com address, it works great. Exactly like running a website and pointing the domain to the right place.

The difference is that anyone, anywhere can send an email to somebody else claiming to be from my fancy new domain. This is why we have spam. This is why we have phishing. By default, anyone can send email claiming to be from any domain that exists.

Arrgh...

DMARC lets you turn it off and control exactly what's allowed to get through, so the only email saying it's from your domain is actually from your domain.

SPF & DKIM

DMARC isn't the first specification to try to fix the spam problem. Multiple others have come along in the past with differing degrees of adoption. DMARC builds on two of them, called SPF and DKIM. Both of these protocols have gaps that are addressed by the other. With DMARC setup, you're telling any mail server that get an email claiming to be from your domain "If this email doesn't pass either SPF or DKIM for my domain, it's not from me and you can discard it (or send it to spam)."

It's important to keep this in mind too. Without DMARC, every email server that gets a message claiming to be from your domain has to make it's own rules to figure out if the message is legit or not. That means running blacklists, IP reputation scores, spam algorithms, machine learning, checking the age of the domain, doing reverse DNS look ups on the IP address where it came from, among other things. Ever been asked to add a business to your contact list? That's why.

Even if you do have SPF and DKIM setup, receiving mail servers have no way of knowing if you have it everywhere so they still have to guess. With DMARC, you're removing the guesswork for them and telling them exactly what to do.

SPF - Sender Policy Framework

The Sender Policy Framework works by publishing a DNS record(s) that lists the IP addresses or domains that are allowed to send email from your domain. All that you need to publish or modify an SPF record is access to your domain's DNS, so it's fairly straightforward to setup. The biggest challenge is identifying everywhere that you're sending email, which DMARC will make easier for you.

Here's an example of an SPF record for your domain, which is just a simple TXT record.

v=spf1 mx ip4:64.18.0.0/20 include:_spf.google.com ~all

This simple record says these IP addresses are allowed to send email from our domain...

• mx allows the servers referenced by our DNS MX records, which points to the email servers that receive email since many will also send email.

• ip4:64.18.0.0/20 allows any IP address in the 64.18.0.0/20 range to send email. We can also specify individual IP addresses. ip6 can be used as well.

• include:_spf.google.com allows us to delegate management of some of our IP addresses to Google, who can update this record whenever things change without us having to worry about it.

The v=spf1 indicates that this is an SPF record since DNS TXT records can be a lot of different things. The ~all at the end covers how strictly to enforce the rule, which we'll talk about in deployment.

When a mail server receives an email from us it will be able to see the IP address of the server that sent it and the domain name it claims to be sent from. That mail server will then check to see if there is a corresponding SPF record and verify that the sending IP addresses exists in this approved range.

SPF has flaws

It's so simple that it makes you wonder why anything else is even necessary, but email is a big world and SPF doesn't cover all of the use cases. If you send an email to a mailing list like a LISTSERV, your email is sent to the server of the list serve itself and then the list serve forwards the message from you out to every address on the list. In this case, the email will come from you but be sent from a server that you have no control over at all which will fail an SPF check.

Another situation is if you send an email to someone who is using a forwarding address, like a collegiate @alumni.university.edu address. The SPF check will fail after forwarding and if you're enforcing SPF too strictly legitimate messages will be entirely lost.

Lastly, an email server which is used by multiple domain names may allow other people to send on your behalf if the owner of the server hasn't taken steps to prevent it.

DKIM - DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) Signatures works by attaching an encrypted email signature to each outgoing message. A private key on an outgoing mail server will reference a public key published in your domain's DNS that can be used by the receiving mail server to verify the signature. Because the signature is based on the body of the message, a failing DKIM check can also indicate that they message may have been modified in transit.

It's more complicated to implement since it has to be setup individually for each sending mail source, but it's more reliable because the signature survives forwarding which fills the gap in SPF. Most 3rd party email senders today will require you to setup DKIM before even allowing you to send an email, but go out of their way to make this process easy for you.

DKIM has flaws too

The biggest flaw with DKIM is that if a mail server receives a message that doesn't include a DKIM signature, it has no way of knowing that there was supposed to be one present. This will lead to treating DKIM as a trust modifier if it's present, but not a dis-qualifier if it's not.

You can see this if you look at the scoring system for a tool like SpamAssassin, which is a popular open source library used to help filter potential spam messages. It uses a scoring system to judge messages based on a lot of different criteria. If a message scores higher than a certain score threshold, it will be classified as spam. Valid DKIM signatures will lower your score, but lack of a DKIM signature doesn't really hurt you.

Sometimes modified emails are good

There are a number of corporate email systems and vendors who provide services that will inspect incoming emails. Sometimes these just scan for viruses in attachments, but others will wrap the links in an email message with a new URL that will inspect the contents and warn you of hazards when you try to click them. These link replacements will invalidate the DKIM signature since the message was modified. Luckily, these systems are usually setup by the entity with the receiving mail server itself so steps can be taken to verify the DKIM signature before the message is modified.

Key Strength Matters

When we talk about using public/private key encryption there's always an associated bit strength to the encryption. 256, 512, 1024, 2048 or even 4096 are what's commonly circulated as of this article. The lower the strength, the easier it will be to crack the private key. This is important because if anybody finds out the private key, email can be sent impersonating the domain and fully pass the authentication checks.

The most famous DKIM cracking incident actually happened at Google thanks to Zachary Harris, Math Pirate. He received a headhunters email coming from Google and thought that the message might have been spoofed, so he looked at the DKIM signature and realized it had a weak 512-bit key. The DKIM standard calls for 1024-bit minimum. He didn't believe that Google would be so careless, so he thought it was a recruiting test and proceeded to crack the key before sending an email to Larry Page from Sergey Brin, Google's founders. 2 days later Google's DKIM key was using a 2048-bit key, but Zachary never got a response.

Key Rotation Matters

When you setup a secure certificate on a website, it comes with an expiration date that will require it to be renewed. DKIM keys have the same need, but it's not required so it's often neglected. Protecting your DKIM private keys is extremely important, otherwise none of this matters. If a DKIM key is cracked in the wild and you don't know about it, the cracked key will keep working until you rotate yours. That means periodically rotating your keys on every outgoing email server that you have, which is going to be tedious if it's not automated.

Luckily, more and more email providers are automating this process for you by providing you with two CNAME DNS records that they can manage for you. This will allow them to change the key on one record while the other is still in use to avoid any disruption to recently sent mail. I know that several already do this, but I'm not aware of a comprehensive list of providers who offer automatic DKIM rotation. Personally, I would go out of my way to avoid providers who don't.

Even if you have a very high strength key, the knowledge of how many years it would take to crack doesn't protect you from everything. A departing employee with privileged access could take the key or leak it. A compromised or unpatched server could allow the key to be stolen. And let's be honest here, if you have IT staff who aren't willing to take the time to rotate those keys how likely is it that the mail server is being properly secured anyway?

DMARC fills the gaps

DMARC builds on both SPF and DKIM, providing clearer rules about their usage while filling their weak spots. Here's how it accomplishes it.

First, the requirement for a message to pass a DMARC check is that it must pass a domain-aligned SPF or DKIM check, not both. What does that mean?

• We've established that SPF doesn't survive forwarding, so receiving mail servers know that if a message doesn't pass SPF for the domain it must pass DKIM...which does survive forwarding.

• We've established that mail servers have no way of knowing if DKIM should be present when they receive a message without it, DMARC indicates it must be there unless the message passes SPF.

DMARC also introduces domain alignment to both SPF and DKIM, because it's possible for SPF and DKIM validation to both pass using domains that are not visible to the user at all which have nothing to do with the From address that you see in your email client. In order for SPF or DKIM to pass with DMARC, these checks must match up with the domain name in the From address so users can see it too. That's alignment. There are several simple examples present at the end of the DMARC specification to help alignment make more sense.

Here's an example of aligned DKIM...

DKIM-Signature: v=1; ...; d=example.com; ...

From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample

The best part though, is that DMARC is extremely simple to setup to provide all of those benefits. It's just a single DNS TXT record. Most of the work comes from trying to figure out all the places you're sending email...but DMARC even helps with that.

This article was originally published on as part of a 3 part DMARC Guide at Brightball.