Email Authentication Basics – SFP, DKIM, & DMARC
Chances are you’ve heard at least one of SPF, DKIM, & DMARC before, if not regarding email than at least when it comes to buying sunscreen! Let’s start with some basic definitions.
SPF aka sender policy framework: an email authentication method that detects forged sender addresses by checking if the sender of the message matches a published list of authorized senders. The authorized senders list is contained with a DNS record.
DKIM aka domain keys identified email: an email authentication technique that uses digital signatures to allow the receiver to check that an email was authorized/sent by the sending domain’s owner and hasn’t been tampered with along the way. A DKIM signature is added to outgoing messages so the recipient can verify it using the sender’s public key published in DNS.
DMARC aka domain-based message authentication, reporting, & conformance: an email authentication framework that gives domain owners the ability to protect themselves from email spoofing by authenticating incoming messages based on the DMARC DNS entry. SPF and DKIM are both part of the DMARC framework.
How does it work?
DMARC fits into your existing email authentication process by helping receivers determine if an inbound message matches what is known about the sender. If there isn’t a match, DMARC provides guidance on how to handle that message. Policy specifics and match criteria are primarily served via DNS records.
The Email Authentication Process laid out by the DMARC Project
You can add DMARC to your domain fairly easily – there are only 5 steps:
Deploy SPF & DKIM.
Ensure your mail servers align with your identifiers.
Publish a DMARC record starting with a none flag for your policy so you start getting reports.
Analyze the reports and modify mail streams as needed.
Modify your DMARC policy flag to quarantine or reject as you get comfortable with the content of the reports.
SPF records
An SPF record contains your list of authorized email senders. Typically you’ll see a mix of servers using the various syntax options.
"v=spf1 ip4:198.20.42.0/24 ip4:198.20.51.123 -all"
The domain using this record sends email from servers in the 198.20.42.0/24 subnet along with a host at 198.20.51.123 and rejects all others.
Check out Wikipedia for a good overview of all the options.
DKIM records
Your DKIM record is the digital signature linked to your domain name that is attached to outgoing emails so the recipient can verify the message is valid by looking up your public key. Valid signatures can also guarantee that parts of the email have not been modified in transit.
Check out Wikipedia for a good overview of the whole process.
DMARC records
A DMARC record in DNS is just a text record that contains your dmarc policy. The most common options are protocol version (v), domain policy (p), and percentage (pct).
"v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@domain.com"
This record uses DMARC version 1 (so far there’s only version 1), rejects email that doesn’t match, checks 100% of messages, and sends aggregate reports to postmaster@domain.com.
For a good overview of all the options, check out the DMARC Project or this useful list!
If you want aggregate reports (aka you used the rua or ruf option in your DMARC record) sent to a domain other than the one you’re setting up DMARC for, you’ll also need to publish an external domain verification (EDV) record. The EDV record grants permission for a specific domain to receive another’s reports. In our example dmarc record above we specify postmaster@domain.com for our aggregate reports. If this is domain.com’s dmarc record than we’re good to go but if it’s anyotherdomain.com we will need to add an EDV record to domain.com giving permission to receive anyotherdomain.com’s reports. The EDV record in domain.com looks like this:
anyotherdomain.com._report._dmarc.domain.com
You need an EDV for every external domain you want to receive reports for. You can either accomplish this with individual records for each domain or use a wildcard to allow any domain’s reports:
*._report._dmarc.domain.com
Setup
Setting up this infrastructure is relatively easy – you just need access to your DNS and email servers. If you use Exchange on Premises, you’ll find these instructions helpful.
If you use Office365 keep in mind that you need to manually configure DKIM if you have more than one custom domain or are going to set up DMARC. The instructions are very straightforward and you should be able to configure multiple domains in under an hour once you connect via PowerShell.
After all that you’re probably wondering if you got it all right! Fortunately dmarcanalyzer.com has some useful tools to help you figure it out.
Let us know if you have any questions or want to add these records to your domain.
-Paola