Following on from my previous article and because I’ve got to write this anyway I thought I’d take a look at the roles of SPF, DKIM and DMARC for people who don’t really need to know the technicalities. There are many articles out there that cover the technical workings of SPF, DKIM and DMARC and some looking at them all together. Hopefully I’m not going to cover the same ground as those too much. Hopefully though this will provide a reasonable over view of what these records are trying to achieve and how they work together.
Firstly the problem all of these things are trying to solve is that e-mail is insecure and easily abused. This is in part because it was designed in an earlier more trusting time and in part because it is designed to allow anyone to reach out and contact anyone else. Much like telephones if someone knows or guesses your number they can call you, and you have to decide if you want to accept the unknown call or not, you could only accept calls from people in your address book but that would make it a lot less useful especially if you’re a business. To continue the analogy e-mail also suffers from cold callers and the like, except with e-mail they can cheaply cold call thousands of people at the time – which is a bit of a snag. So over the years to try to combat this problem various security measures have been layered on top off the underlying e-mail infrastructure like an every growing mas of sticking plasters of which SPF, DKIM and DMARC are the latest.
This is still a better bet than trying to rebuild a secure e-mail equivalent from scratch.
Ultimately as there is no central source of trust for e-mail all of these initiatives can do is to make it harder for the bad guys to operate. This does have though also make it harder for everyone else to operate, which favours the use of large providers over independent systems which has a knock on effect to the resilience of the system as a whole. We can ignore that for now.
The big difference with the triumvirate of SPF, DKIM and DMARC compared to previous anti-spam approaches is that publishing the relevant records for your domains to implement these technologies will do absolutely nothing to reduce the amount of spam you have to deal with. What they will do though is help other people recognise your emails as (probably) good and so assist other people’s anti-spam strategies so it’s being a good neighbour and also protects your reputation if people decide to pretend to be you for malevolent purposes. One obvious problem that should be readily apparent is that there is nothing to stop the bad guys from also publishing all of the correct records and so also appearing to have a degree of reputability. This is sadly unavoidable, but it does make it a bit more work and it makes it easier to block them when they’ve been identified.
SPF
SPF is the easiest of the three policies to implement as can be seen from how widely it’s been adopted, including by the bad guys. It suffers from many problems, though this have been largely work round since it was first introduced, and on its own really only stops the laziest of spoofing. What SPF does do is to ensure that the envelope from address, which almost no one looks at, is permitted to be used by the machine sending the e-mail. So the bad guys could send from their own server with a valid SPF record and still forge the “From” address that people’s email clients display. So as it stands not very useful and to make matters worse it only does an exact check on the sending “domain”. Which leaves sub-domains and server records vulnerable to spoofing. This becomes more useful if you check that the visible “From” address matches the matches the envelope “From” address, if they don’t match one might be suspicious. If there’s no SPF record for the exact envelope “From” domain then you have no idea what to do. Having mail pass the SPF check is a good thing, especially if both “From” addresses match, but if there’s no SPF record then you don’t know if it’s just missing or a bad guy.
DKIM
DKIM looks at the same “From” address as the user sees and usually other parts of the e-mail header and digitally signs them so that you know they’ve not been tampered with. It however also tells you who’s signed it so, which lets the bad guys forge the mail and sign it – thus vouching for themselves. Which isn’t terribly useful. Though again if the e-mail was signed by someone other than the organisation who sent it we might be suspicious. If it isn’t signed we again have no idea as to if it should have been or not. So as with SPF if the same domains are used and the data is there we can have more faith that it’s legitimate, or it’s at least spam with a bit of effort put into it. Implementing DKIM takes a bit more work though and isn’t yet as widely adopted as SPF.
DMARC
DMARC is the third leg of this triumvirate that props up the whole edifice. This is actually where the tripod analogy falls down because having either SPF or DKIM along side DMARC provides far more utility than having both SPF and SKIM but not DMARC. Though of course interestingly having DMARC without either of SPF or DKIM is utterly useless, if you’re actually sending e-mail. The very simple reason for this is that DMARC fills in the gap of what to do if there is no SPF or DKIM data, it also tells you what level of compliance to expect from that sending domain and how much faith the sending organisation thinks you can put in what it’s published. The crucial difference with DMARC is it does check what the parent domain says and so publishes a security policy for everything under that domain. This fills in the gaps in SPF for servers and sub-domains, and resolves the issue of DKIM signing being self referential. Whilst DMARC does allow for partial deployment in either quarantine mode or to apply to just a percentage of records, realistically if you’re not in test mode assume that your published policy will either be treated as test mode or as dump everything that doesn’t match fully.
I have rather glossed over one of the bits of DMARC that is a lot more work to implement. The problem is the reporting side, which is incredibly useful both before implementing and afterwards but requires a degree of infrastructure to deal with the reports and make them user-friendly. In most cases you’ve probably got mail originating from places you don’t know about that you want to fix before implementing DMARC in reject mode, and afterwards you’ll want to keep an eye to make sure legitimate mail doesn’t start appearing from new sources. The reports you get via DMARC aren’t very human friendly and you’ll really want to aggregate them, so you’ll need a reporting tool either opensource or from a commercial supplier. You can implement DMARC without ever seeing or caring about the reports and for small organizations that may well work. Just bin the reports you receive, or don’t publish an address to receive reports at all. You’ll still benefit from the policy enforcement benefits of DMARC and as long as you understand your mail environment well, then your legitimate mail will get through and other people will have more faith in the mails they receive from you. For most of us though, having at least some visibility of DMARC reports is a good way to make sure your mail environment is behaving as expected. It’s also interesting to see how many people are trying to pretend to be you. If you don’t want to roll your own open source solution and don’t want to pay for a commercial solution there are some free basic DMARC reporting services such as from PostMark. As mail security becomes increasingly dependent on trust and reputation you’ll probably want to rethink how many domains you use to send e-mail from but that’s a topic for another day.
TLDR
SPF – says where mail can come from
DKIM – validates headers/content
DMARC – says what to expect from SPF/DKIM and who to tell when it’s wrong
For SPF or DKIM to be effective you need DMARC