The last in the email security series, DMARC, or Domain-based Message Authentication, Reporting and Conformance, builds on both SPF and DKIM. Improving security further and allowing reporting, you can monitor your domain for fraudulent or spoofed emails to take action.
DMARC
As another DNS TXT record, DMARC is easy to setup and configure with no impact on the end user. Mail servers will transparently apply the policy and if configured, a designated admin email address will receive reports of what's happening out in the wild. You need to have DKIM and SPF setup before you deploy DMARC, so if you haven't done that already, read those blogs and get them setup first. As usual, here is the RFC link but you can save yourself the trouble of reading it and continue below!
The DNS record
The DMARC DNS TXT record can be made up of several different values but only 2 are required to actually create a valid policy.
v | p | adkim | aspf | fo | pct | rf | ri | rua | ruf | sp
The 2 required values are v and p, so let's start with those.
v
This is the version and the only valid value is DMARC1.
p
This is the policy to enforce and only has 3 values, none, quarantine or reject. If you specify none, you're telling someone receiving email from you that fails DMARC to take no action. Quarantine could be something like moving it to a spam folder or further scrutiny and reject would tell them to outright block the email from being delivered.
The remainder of the flags allow for fine-tuning of the policy and you can also enable reporting.
adkim
This value allows you to set strict (s) or relaxed (r, which is the default) alignment for the DKIM identifier. This loosely translates to an email from [email protected] being accepted if the DKIM policy is for scotthelme.co.uk in relaxed mode. In strict mode that would be blocked as the FQDN has to be an exact match. The default is probably sufficient for most.
aspf
This value has the same settings and impact as the adkim value above, but is for SPF instead.
fo
The failure options allow you to configure when reports should be sent. The values are 0 (the default) which means a report should be sent if an email fails DKIM and SPF checks, 1 to send a report if either DKIM or SPF checks fail, d to send a report only for DKIM failures and s to send a report only for SPF failures.
pct
The percent of emails that should have the policy defined in p applied to them that are affected. This is an integer from 0-100 inclusive with the default being 100. This allows for an incremental roll out of DKIM and removes the 'all or nothing' problem. You can set this to 1% and only 1% of emails that would have been blocked or quarantined will be. The other 99% will be treated as if the policy didn't exist. This is a great option to use for testing DKIM in a steady rollout.
rf
This value defines the format that reports should be sent in and only has 1 value, afrf, which is the default, so you can ignore it for now.
ri
The requested interval between DMARC reports being sent as an integer for the number of seconds. The default value is 86400.
rua
This is the address where you'd like aggregate reports to be sent to. They won't be sent if the address isn't specified. An example value would be mailto:[email protected].
ruf
This is the address where you'd like forensic reports to be sent. They're detailed reports on each failure and take the same format as the rua value above.
sp
The subdomain policy is applied to all subdomains of the domain in question. It takes the same format as the p value above.
Creating your record
The DNS TXT record itself should be created with the _dmarc prefix, such as _dmarc.scotthelme.co.uk. From there we need the minimum required values and I've also enabled reporting so I can see if people are trying to send forged emails from my domain.
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]
You can see that I'm introducing the policy with no enforcement, p=none, so that whilst I'm starting out there will be no adverse effects on email delivery. This is just so I can ease into it and get a few reports to make sure everything is working properly and I don't accidentally see to it that all of my emails end up in the spam folder! I've defined rua and ruf to send me emails so I can start to gather reports and the adkim and aspf values will default to r for relaxed mode for now. As things progress and you gain confidence in your deployment there are a few ways that you can start to tighten things up.
Strengthening your policy
The policy above is very basic but makes for a great starting point. We need to take that policy and strengthen it into something that will offer us the protection we want.
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; aspf=s; adkim=s
Here I've set aspf and adkim to strict mode as I'd like the FQDN to be an exact match. Again, the policy is still taking no action but I can gather feedback to see what effect it would have. Once I'm happy with that I can introduce some action to be taken.
v=DMARC1; p=quarantine; pct=5; rua=mailto:[email protected]; ruf=mailto:[email protected]; aspf=s; adkim=s
I've now instructed the policy to start taking some action and quarantine 5% of emails that fail to meet the requirements. Again, I'm not jumping straight in at 100% whilst testing things out but I will get feedback on any action that is taken. The last step is to fully enforce the policy and gradually increasing your pct value.
v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; aspf=s; adkim=s
In this policy I've removed the pct value because the default is 100% so it doesn't need to be defined. With the policy in quarantine mode the emails will still be delivered by may end up somewhere like a spam folder, have some kind of mark placed on them or be subject to extra scrutiny of some kind. The other option is to instruct the receiver to discard emails that don't conform to your DMARC policy.
v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; aspf=s; adkim=s
You should consider whether or not you want to change the p value from quarantine to reject but this will now tell the receiver to reject any incoming mail form you that doesn't meet the requirements of the DMARC policy. If you're confident in your setup and want to ensure that no one receives a spam/forged email claiming to be from you, this is the best configuration.
This concludes the email security mini-series covering SPF, DKIM and DMARC. All 3 of these technologies are incredibly useful and important to a secure setup so I hope it's been useful and that you will consider deploying them on your own sites. As usual, comments, suggestions and feedback below please and let me know of any success stories!