This post originally appeared on the Armadillo Blog and has been lightly edited for clarity.
Most organisations have been successful in blocking malicious emails targeted at their employees, at least to some extent. Various on-premise and cloud providers exist to take care of anti-spam, anti-virus, reputation scores, and advanced features such as sandboxing of executables.
As a service provider with a list of blue-chip clients, we have been looking for a way to protect our clients from bad guys impersonating us by spoofing our email domain to phish for credentials. Until recently, organisations have washed their hands of this issue, putting the onus on end customers to educate themselves to identify and avoid clicking on malicious emails. Personally, I do not believe that is acceptable, particularly when a range of technical solutions is available to help you exercise a reasonable duty of care to your customers.
A number of open protocols have existed for some time to make things easier. DomainKeys Identified Mail (DKIM 2011), Sender Policy Framework (SPF 2014), and Domain-based Message Authentication, Reporting and Conformance (DMARC 2015) can all help, but until now, understanding and implementing these protocols has not been easy and organisations have typically not been willing to experiment with critical email systems.
At Armadillo, we evaluated a few services to help us to protect our customers from cybercriminals spoofing our domains and decided on Agari. This blog documents our experiences so far in implementing these features.
The first order of business was to understand at a high level what these three protocols do, and how they work together:
- DKIM is a method of linking an email message with a domain name. As the domain owner, you can cryptographically sign messages using asymmetric keys so that the receiver can validate messages as being sent by the owner of the domain.
- SPF allows you to provide a list of the hosts that are allowed to send email on behalf of a particular domain—a whitelist of mail servers in effect.
- DMARC is the glue that binds it all together. Using DMARC allows you to say to a receiving mail server, “I use DKIM and SPF—if any messages from me don’t pass these checks, I would like you to reject them.” DMARC also allows the receiving mail servers to send back summary reports and forensic reports so you can check that things are working as intended.
So, time to get to work! The first step is to turn on DMARC on your domain. The recommendation is to do this in what’s known as “p=none” mode. This turns on all the reporting features, but without the risk of falsely blocking messages. To do this, it is just a simple addition to your DNS record. Once you do this, the Agari DMARC Protection dashboard then gives some great pointers on what to do next.
After enabling DMARC on my personal domain, I noticed a lot of dodgy stuff going on.
The only way my emails should be sent is via my Gmail account. There is no valid reason for my emails to be sent from a server in Suriname or Ecuador. So, someone is spoofing my domain…
Thankfully, the wearearmadillo.com domain is spotlessly clean. However, we saw some other legitimate domains we did not originally consider. Our ticketing system sends emails from our domain but from a different mail server, as does as the system we use for email marketing. Having DMARC enabled in monitoring mode allowed us to spot these and update our configuration without risking the delivery of legitimate messages.
Updating the SPF record is really easy too, as it is another simple DNS record listing the authorized IPs that you allow to send email on your behalf. The Agari DMARC Protection dashboard tells you the exact syntax to configure in your DNS provider, which you can input yourself. As an alternative, Agari hosted solutions automate the process completely so you never have to make your own DNS changes. When Agari hosts the SPF record, they completely take over the DMARC authentication process for all senders, including third-party ones, thereby relieving the burden from the user.
This week, we’ll be enabling DKIM on our Office 365 tenant, which should complete the bulk of the configuration. We’ll then monitor the DMARC reports for a month or two. At this point, we can switch the DMARC mode to “p=quarantine” which asks receiving mail servers to deliver possibly spoofed messages to spam folders, or directly to “p=reject” which discards spoofed messages before they ever reach the inbox. With Agari’s hosted DKIM service, similar to SPF and DMARC records, organizations can choose to save the DNS management, infrastructure, and full-time employee costs related to authentication by taking the DKIM management out of their environments.
While we could have done all this without using Agari, I’m not sure we would have managed it without unintentionally dropping legitimate messages, nor would we have progressed along the journey so quickly. The tools provided by Agari to view failure samples and lead you through the process have been invaluable in getting us up to the current state of the art in email protection. With Agari’s hosted model, the entire process is fully automated, so customers don’t have to make any DNS changes themselves.
In addition, the Secure Email Cloud adds another really useful feature to complete the jigsaw – the ability to protect against attacks involving display name deception, look-alike domains, and compromised accounts. For example, while DKIM, SPF, and DMARC work great to prevent people spoofing your real domain, cybercriminals can still launch sneaky targeted attacks where they register similar domains, perhaps swapping an ‘o’ for a ‘0’. Agari will alert us if any similar domains are registered, allowing us to warn our customers. In addition to alerting for these sneaky domains, the Cloud Email Protection solution provides a proactive solution to stop look-alike (also known as cousin domains), display name deception, and account takeover types of attacks that cannot be stopped with DMARC.