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.
Subscribe to new posts!
Why does DMARC matter?
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:
How does DMARC work?
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 DKIM and SPF
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?
DMARC policies and reporting
There are three possible DMARC policies:
- None
- Quarantine
- Reject
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.
The reports can be read with a tool such as Postmark or dmarcian.
How to set up DMARC?
- 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?
Source: https://woodpecker.co/blog/dmarc/
