Alaris, like pretty much any other company, primarily uses email to communicate internally and with our clients. As a result, email trust and delivery is paramount here in the Alaris IT department. Both our users and our clients need to know that an email sent from Alaris is coming from Alaris, and not from someone trying to do something nefarious. Impersonation with the goal of fraud or phishing to get access to internal networks has become alarmingly common over the past few years.
I responded to this by making Alaris one of only a handful of companies that run a strict rejection policy on all mail that fails authentication. In my research I only found one other company in our field to take it as far as we have.
The authentication issue is caused by a simple problem: email is old. The first email between two networks was sent in 1971, and the Simple Mail Transfer Protocol (SMTP) was drafted in 1981. That’s back when computer security was handled with physical locks and keys. Because SMTP was made before spam and fraudulent mail had become a concern, it simply does not check if the mail being sent is valid. SMTP has since become so ubiquitous that it will likely outlast you and me.
The industry has come up with three email authentication protocols that offer protection if they are properly set up. All three of these methods are set up at a domain level, outside the control of email itself, and if you have a simple email setup with only a few servers, this can be handled in an afternoon. While I won’t cover specifics of how you can implement these yourself, I’ll describe the Alaris implementation and maybe give you an idea of what you’ll need to tackle.
Sender Policy Framework (SPF)
This is a simple list of servers that are allowed to send mail from a domain. We have a deliberately simple setup to send mail internally, but we use a few other services that also need to send email using our domains. SPF policies are published publicly, and you are welcome to look ours up if you wish. If you’re like me, it can be interesting to see how different companies send mail.
DomainKeys Identified Mail (DKIM)
This method is more complicated. To keep things short: mail sent is “signed” with a unique identifier that the recipient can verify with a domain you specify. Most email providers support DKIM these days, but if you’re using an internal Microsoft Exchange server, it does not support DKIM out of the box. Free open source signing agents are available for Exchange, however.
Any service that sends mail to one of our clients from an Alaris domain must support DKIM. There are no exceptions to this. This policy is mostly to assist with email delivery, since there are instances where SPF will fail even with a legitimate sender. The recipient using an email forwarding service is a common reason.
Domain-based Message Authentication Reporting and Conformance (DMARC)
This is the most interesting of the three protocols, because it builds upon SPF and DKIM. DMARC tells a recipient what you want them to do with mail that fails authentication, so it effectively acts as a statement of how confident you are in your email configuration. DMARC policy, like SPF policy, is public and you are free to look up the Alaris policy if you wish. Ours is very simple: do not deliver mail that fails authentication, and we request reports be sent to us.
Reports are the other feature of DMARC. Most recipients won’t bother sending reports, but the bigger email hosts such as Yahoo, Google, and Microsoft will send enough reports that you can get an idea of how your SPF and DKIM configurations are behaving before you enable a DMARC policy. I was monitoring reports for four months before I was comfortable turning on the rejection policy, and it was still a nail-biting moment for me.
It should be noted that DMARC is very much optional. I can see that my bank, for instance, does not have DMARC set up, but they have a strict SPF policy in place and their mail is signed with DKIM. I would still recommend DMARC be configured if you’re setting this up now, however. Enough companies have misconfigured SPF over the years that some mail services treat it as suggestion instead of policy, but there are very few that will not follow DMARC policy.
And that’s how email authentication works here at Alaris. As I brought up above, very few companies seem to go through the trouble to lock email senders down this thoroughly. Companies with multiple servers or lots of services to accommodate will have a harder time than I did, but nonetheless this is an important security step every company should take for themselves and their clients.
Dave Willman, Senior IT Support Technician - Alaris