Holy smokes, this one’s a tough one to crack.
Or at least that’s what I thought when I first dug into DMARC.
That’s why I went over to Wojtek, our Head of Deliverability here at Woodpecker, and asked him to explain it to me plain and simple. He helped me to understand what DMARC is exactly and why it matters.
I’ve come up with a story that’s perhaps a bit unusual when it comes to the world of email security, but I believe it might help you understand what DMARC is and how it works – even if you know squat about email authentication mechanisms.
This one’s for all of those folks who, like me, scratch their heads when they stumble upon technical matters.
Ladies and gentlemen, put your learning goggles on.
Once upon a time, there was a young queen. She was fair and kind, as they usually are in such tales.
The queen ruled over a beautiful, vast kingdom with her hubby, the king. They led a peaceful and happy life.
Until one summer day, that is, when a messenger arrived, carrying a message from the queen’s elderly father.
(A quick side note: the young queen was wedded and left her homeland a couple of years back, and that’s when she last saw her father. They wrote letters to one another, though – you know, to keep in touch.)
According to the message, her father has fallen ill and needed her help in the form of 10 chests of gold. He asked to send them asap.
The queen was, however, a clever gal.
She noticed that the seal on the message was broken. And when she looked closer at the messenger, she noticed that he wasn’t clad in her father’s men’s uniform either! She knew something was up.
‘Guards!’, she yelled all of a sudden. ‘This man is not who he claims to be. And this message has not been written by my father. This man is trying to rob us of gold. To the dungeons with him!’
‘If I may, m’lady’, interrupted her the royal scholar. ‘According to the law of our lands, the punishment for such crime is not sending the man to the dungeons, but banishing him from the kingdom.’
And that’s what the queen did. The man was sent away, never to set foot in the kingdom again.
Thus ends the story of a bad lad, thirsty for gold, and a young queen who knew how to stay safe. Yes, it was a short one – because the queen wouldn’t be fooled with such trickery, my friends. And you shouldn’t either.
But wait, what does that have to do with DMARC?
Let’s take a step back.
Think of the message the queen got as an email somebody sent you.
The seal on it is like DKIM. When it’s there, you can be sure nobody opened the message after it has been sent.
The messenger is like SPF. When you have it set up, you can be sure that the messenger is who he really claims to be. And by messenger I mean an ESP (Email Service Provider).
And the law that specified what the queen should do in such a case as described in our story is like DMARC. It explains what should happen for the message to go through – and what should happen if the conditions aren’t met.
Now, let’s take two steps back.
In a nutshell – it’s an email security measure that protects your domain against being used by the bad guys and gives you better control of your email deliverability. It’s based on the SPF and DKIM mechanisms (or the messenger and the seal, in our case).
The bizarre-sounding acronym stands for Domain-based Message Authentication, Reporting and Conformance. What does THAT mean, though?
DMARC allows you to conclude if an email you got was legitimately sent by the person who claims to have sent it. That’s the authentication part.
If the email doesn’t pass the DMARC test, it will be handled in line with the DMARC policy that has been set by the receiver (I describe it in detail later on in the article). That’s the conformance part.
DMARC also makes it possible for the receiver to send reports to the sender, describing how the message was handled: was it let through to the main inbox, did it end up in a spam folder or was it rejected. And that’s the reporting part.
All in all, DMARC allows email receivers to check if the incoming email matches with what they know about the sender. And if it doesn’t, it tells the receivers’ servers what they should do with such a message.
It’s not set up by default – you need to do it yourself if you want to put an additional email security measure on top of your SPF and DKIM mechanisms.
But why is it important?
There are three reasons why DMARC is so valuable for email users:
1. It’s a safety measure.
On the sender’s end, it protects your domain against unauthorized use, e.g. by phishers who try to steal your personal information this way. On the receiver’s end, it makes it harder for fraudulent email to go through to your main inbox.
DMARC protects against domain spoofing, aka when somebody who isn’t allowed to use your domain tries to pretend they’re you or that they work at your company to trick someone into believing they’re you. They do it to steal personal data, such as login details or a credit card number.
2. It helps you to better control your email deliverability.
Another perk of employing DMARC is that you’ll be able to better control how many of your emails are considered legitimate and get to your recipients’ main inboxes. And if someone’s trying to impersonate you and send emails on your behalf, but I’ll come back to that in a bit.
3. It protects your brand reputation.
If someone’s pretending to be you and trying to trick people into giving them money or some personal info, it reflects badly on your brand. DMARC helps to avoid that.
DMARC is published in the DNS by the domain owner, alongside SPF and DKIM. It’s a simple one-line record.
Here’s an exemplary one:
v=DMARC1; p=none; rua=mailto:[email protected];
Let’s cover the basics first. As I’ve mentioned earlier, DMARC is based on the SPF and DKIM mechanisms. You may already be familiar with what they are, so here’s just a quick reminder.
Sender Policy Framework (SPF) defines who can send emails on behalf of your domain. Or, in (slightly) more technical terms, the SPF record contains the IP addresses that have the permission to send emails on behalf of your domain.
In our tale of the smart young queen, the messenger is the SPF.
DomainKeys Identified Mail (DKIM) is a set of two coded keys: one is private and the other one is public. The sender encrypts the header with the private key, and the receiver uses the public key to decrypt it. If the two headers match, it means that the message hasn’t been opened after being sent.
Thanks to DKIM you can be sure that an email was sent from the domain that you see in the header.
Again, in our story, it’s the seal on the message.
If you’d like to read an in-depth explanation of what SPF and DKIM are, Cathy wrote an article about those mechanisms – check it out here.
Use Woodpecker to grow your business
Turn more prospects into customers
The anatomy of DMARC
The law in the kingdom is like DMARC.
It specifies what has to happen for the message to go through to the inbox, and what will happen if the conditions aren’t met.
When an email is being tested by DMARC, 4 things might (or should) happen:
- DKIM pass – the additional signature put in the header needs to be validated: the private key matches the public key published in DNS.
- DKIM alignment – the parent domain matches the Header From domain.
- SPF pass – the receiving server will take the domain included in the Envelope From address and check for an existing SPF record (and it checks if the IP address is included in the SPF record).
- SPF alignment – the domain in Envelope From matches the domain in the email’s Header From.
A message will fail DMARC if it fails both SPF and DKIM.
Keep in mind, though, that if you forward a message, only the DKIM stays aligned.
Wait, but aren’t SPF and DKIM already used to protect email?
The SPF and DKIM mechanisms both work to protect against unauthorized use. The thing is, though, that they work in isolation. There is no one universal law to say what the receiver should do when those fail. Every receiver handles such failed messages differently. So for example, one receiver may redirect it straight away to the junk folder, while another will put it to some additional tests to determine where it should go.
Not to mention the domain owner never gets any info about his emails and if they reached the recipient’s main inbox.
DMARC allows us to define our own rules on how to handle an email that doesn’t comply, reducing the risk of our domain being spoofed.
It also allows us to report back to the sender.
Adding a DMARC record to DNS will allow you to set rules for the incoming emails: should they be quarantined, rejected or let through?
There are three possible DMARC policies:
Now, let’s circle back to our story: DMARC is the guidelines for what should happen if someone tries to trick the queen into giving them gold.
- Setting up the ‘none’ policy would mean that anyone could deliver any message and it would be treated as a legitimate one. The result: the young queen gives away 10 chests of gold, thinking she’s helping her father.
- The ‘quarantine’ policy means the message is treated as suspicious. The result: the would-be thief is locked away in a dungeon (but might be set free at some point if he’s not found guilty).
- And the ‘reject’ one – that the message won’t be let through to the inbox. The result: the would-be thief is banished from the kingdom for ever.
In email this means that with a ‘none’ policy all the emails will go through, even if they don’t pass the SPF and/or DKIM test. With a ‘quarantine’ policy set up, the ones that don’t pass will be redirected to the spam folder. And with a ‘reject’ policy, they’ll bounce.
A couple days after you publish a DMARC record in DNS, you’ll start getting reports from ISPs. Those will include stats about all emails sent from your domain (including those that claim to come from your domain).
If you see more emails than you’ve really sent, this means someone other than you is using your domain. The report will give you a clear overview on where the emails come from and if they’d be halted by a “quarantine” or “reject” policy.
These reports will allow you to assess the health of your outgoing messages. What elements do they include? How the messages were handled (in line with the DMARC policies that have been set up), IP addresses that have used your domain to send emails (as well as how many messages have been sent), and SPF and DKIM results.
- Set up SPF and DKIM
First things first: you need to make sure your SPF and DKIM records are set up. If you’ve thought about your deliverability before, chances are you’ve already crossed that off your list.
- Generate a DMARC record, e.g. here.
For now, choose the ‘none’ policy for all emails.
- Add your DMARC record to DNS
- Modify the policy according to data as you go
Analyze several reports that you get and once you know how to maneuver through the DMARC policies, switch from ‘none’ to ‘quarantine’, and later on to ‘reject’.
Over to you
A combination of SPF, DKIM and DMARC is deemed to be the golden trio of email authentication. SPF and DKIM are better known and more widely used. Right now DMARC is more of a nice-to-have than a must-have, but this will probably change in the future as more and more people are setting it up for better domain protection against spoofing and phishing.
How about you – are you ready to set up DMARC?