If you haven’t checked out the articles on SPF and DKIM, I recommend you do that before reading this one. SPF is cool. DKIM is cool. But SPF, DKIM, and DMARC? Super cool. SPF and DKIM go with DMARC. Do them all! As stated previously, school districts can secure email by using the magic three frameworks: SPF, DKIM, and DMARC. This article’s focus is on DMARC.
DMARC is the easy way of saying Domain-based Message Authentication, Reporting, and Conformance. Of SPF, DKIM, and DMARC, DMARC wins as the most interesting and powerful. It builds on SPF and DKIM, so, again, both should be in place before traveling down the road of DMARC. Mail servers that are receiving can look at the sending domain’s DMARC policy to know what action to take (e.g., report, quarantine, reject) if SPF or DKIM fail. (Side note: Not EVERY receiving mail system honors DMARC, but all the major ones do.)
So why use DMARC? It provides control over forged messages that appear to come from your domain. It adds some reporting that isn’t available with SPF and DKIM, and this reporting can help you identify legitimate third-party sources to include in your SPF record.
Examples and Explanation
DMARC is constructed in a TXT record format for DNS. So open log into your DNS provider and follow along.
Start by creating the name of TXT record: _dmarc.your_domain.org
Now let’s create the record itself.
Sample value: “v=DMARC1; p=none; sp=quarantine; pct=100; rua=mailto:dmarc_reports@domain.org”
- v=DMARC1: This is the DMARC version. Always use DMARC1.
- p=(policy): This is the requested action for messages from domain.org that fail the DMARC check. Servers have discretion on exactly how to handle them.
- none: Send a report. Take no further action.
- quarantine: The receiving server may send the message to spam, hold it, or further process it in some way.
- reject: Reject the message outright.
- sp=(policy): This is the requested action for subdomains of domain.org.
- pct=(number): This is the percentage of messages to be affected by the policy. It allows for gradual testing. If omitted, the default is 100.
- rua=(mailto:address): This is the address to send aggregate reports. It is recommended to use a special email account for this purpose.
Here are some additional examples:
Report only: Does not affect mail flow.
“v=DMARC1; p=none; rua=mailto:dmarc_reports@domain.org”
Moderately aggressive: Quarantine all failing messages from the domain; reject those from subdomains.
“v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc_reports@domain.org”
Aggressive: Reject all failing messages.
“v=DMARC1; p=reject; rua=mailto:dmarc_reports@domain.org”
So how’s it work? When a mail system that supports DMARC receives a message, it checks DNS for the “from” domain’s DMARC policy. If a policy exists, DMARC will pass if either SPF or the DKIM tests pass with alignment — that is, the SPF/DKIM domain is the same as the “from” field. If both SPF and DKIM fail outright or, because of non-alignment, DMARC fails.
Reports?
So are there reports? Yes. Some mail system providers, including Google, send XML reports of how they act on your domain’s messages. There are also services that process DMARC XML reports so that you can read the data well. You can check these out:
Final Thoughts
DMARC is best done with a gradual approach. Start with reporting only, then move on to quarantine once your logs look good. Then, if you so choose, move on to a reject policy. You can adjust your SPF policy as needed, and you’ll know better what’s needed from the logs. Remember: DMARC passes if either SPF or DKIM pass with alignment.
If you have a Google Domain (Gmail), then here’s a Google link that is a “how to” on DMARC: https://support.google.com/a/answer/2466580?product_name=UnuFlow&hl=en&visit_id=637898791728516139-4166345023&rd=1&src=supportwidget0&hl=en
That’s pretty much it. You now have all the tools to improve the posture of your email security by implementing SPF, DKIM, and DMARC!