Hi Friends,
Welcome to Part One of decoding DMARC. DMARC is mysterious, curious and often times misunderstood technology. None-the-less this technology can help provide security to you and the people you do business with.
DMARC, Domain-based, Message Authentication, Reporting and Conformance is not a tool at all, it’s a technical standard that helps keep the good email going and the bad email out.
If you’re a total DMARC newbie, it can be a bit overwhelming, but basically here’s what it is in a nutshell:
1. Your domain’s authentication practices, what happens if the recipient’s server can’t verify the message sender is who they say they are, are published in Domain Name System (DNS), the phonebook of the Internet.
2. DNS will state what happens when authentication checks fail.
3. Reports are sent of email claiming to be from your domain, if configured.
So how do we do this? By using two authentication standards; SPF and DKIM.
Sender Policy Framework or SPF are the IP addresses of email servers that are allowed to send emails from your domain. IP addresses are identifying numbers given to a computer when it joins the Internet.
Domain Keys Identified Message or DKIM is a lock and key scenario. When you setup DKIM you create a private key that is present on every email you send. In DNS you tell everyone what your public key is. An email from your domain will only be accepted if the private key on the email fits the public key in DNS.
One thing you’ll hear a lot when it comes to DMARC is alignment. Alignment makes sure that SPF and DKIM are in sync. If there is no discrepancy between the two, the email will pass alignment.
Setting up DMARC helps to validate emails that are coming from your domain. Here’s how it works:
1. An email comes to the ACME company from the Widgets company. How does ACME know the email is really from Widgets or is some threat actor spoofing the Widgets’ company domain?
2. Luckily Widgets company configured DMARC so other companies can check for validity.
a. Do the DKIM private and public keys match from what’s in DNS and on the received email?
b. Did the message come from an email server that matches IP addresses placed into DNS?
c. Is there proper alignment between SPF and DKIM?
3. If all three of these conditions are met, ACME company knows the email really did come from Widgets company.
4. But what if the conditions aren’t met? Well, that depends on what is published in DNS. You have three choices:
a. None – Emails will be treated as if DMARC was not used.
b. Quarantine – Accept the email, but put it some place other than the user’s inbox.
c. Reject – If it doesn’t pass, reject it.
When configuring DMARC, companies need to be cautious not restricting email traffic too quickly, since this can potentially cause legitimate emails from being delivered. It is important to investigate all sources that will send email on behalf of your domain.
This concludes Part One of Decoding DMARC.
In Part Two, we’ll take a deeper dive into DMARC policies and how to read them in DNS.
Thanks to DMARC - Explained by SparkPost for ideas for this post!
