Solutions can raise new problems, but they also provide opportunities to address them and provide solutions for wider problems.
This happened to us in Common Technology Services (CTS) while developing our secure email guidance. We needed a way to make sure email came from where it says it came from. Our discovery work brought us to Domain-based Message Authentication, Reporting & Conformance (DMARC) as a solution.
Protecting your email from spoofing and phishing is obviously important because they let other people to pretend to be you. They’re more commonplace than you might think and DMARC provides protection against both.
What is DMARC?
DMARC is Domain-based Message Authentication, Reporting and Conformance. It's a mouthful but it says what it is. It provides a way to authenticate email for specific domains, get reports, and conform to a published policy.
It's almost an internet standard listed as 'Informational' at the The Internet Engineering Task Force (IETF), although it's already widely used particularly by the larger, consumer-facing email providers.
What can DMARC do?
An example of DMARC in action is in a charity where I’ve worked in my spare time. It’s a small place that works in the local community, exposing young people to nature and providing some vocational training. They run a small cafe and do most of their work on site. They have a website and an email newsletter and the staff send about 1,500 emails a week between them.
I enabled DMARC monitoring for this charity recently, and found that in addition to the legitimate emails their domain was spoofed around 300 times a week. If such a small organisation is being spoofed it’s likely to affect almost every domain.
DMARC is important as it helps you block spoof emails and reduce spam, malware, and the potential for fraud.
Secondly, DMARC shows you where your email comes from. You get a view of your whole email environment - how your email is used, for good and bad.
Finally, because you’re getting protection against spoofing, so are your customers. This makes communications from you more trustworthy.
How DMARC works
The diagram below shows how DMARC works. The sending domain has an email service and a Domain Name System (DNS) record with a DMARC entry. When it sends an email the recipient email service does some authentication checking. It also checks the sender's DNS to look for a DMARC policy.
If the email fails the authentication checks, and there's no policy with instructions on what to do with failed checks, the email may still end up in the recipient inbox. If there's a policy to reject email that fails authentication checks then the email gets sent to spam.
Lastly there's a reporting mechanism. This lets other email systems send reports on email they receive from you. This is great because it tells you if someone is pretending to be you, or if you have legitimate services sending email that you don’t know about (like a third party marketing tool).
Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) provide the authentication for DMARC.These are well established internet standards for protecting against email spoofing.
- SPF tells the recipient where legitimate email for a domain should originate from
- DKIM signs outbound email so the recipient can check the signature is intact on arrival, and therefore the email came from a legitimate source and hasn’t been tampered with in transit
DMARC uses these to check the authenticity of the email. If it fails these checks and your policy says reject or quarantine, it conforms to that policy.
This is on top of existing email filtering for spam and malware based on message content and algorithms. There’s plenty you can still do, but DMARC is simple and free, and makes it very easy for email services to make quick decisions about your email without having to employ more complex analysis.
How to do it
DMARC is straightforward to set up, particularly if you have access to your DNS records. It’s also possible to do a fair bit without doing anything to affect your email flow - you set yourself up in ‘monitoring mode’ and go from there.
This is a basic DMARC record that you would put in your DNS:
v=DMARC1;p=none;rua=mailto:dmarc@yourdomain.co.uk
It says, this is a DMARC record, don’t change the way you filter my email, and send reports to the email address supplied.
The ‘p=none’ is the policy part. This record will have no effect on your email flow, but after a couple of days you’ll start getting reports sent to the email address you include.
As the reports build up you get a picture of where your email is coming from, and where the gaps are on the ‘conformance’ side of things - are people spoofing your domain, and are there legitimate email sources you didn’t know about?
On a practical level this is where you start adding sender domains to your SPF record, and enable DKIM signing where possible. For example if your business email comes from Office 365 or Google Apps, your SPF would include their IP addresses so that email gets through. You can enable DKIM in your email service as well.
Adding a third party service
There’s also a good chance you’re sending email from somewhere else. For example a line of business application in finance or payroll that sends email. You need to add their sending IPs to the SPF record. Older applications may not let you add the DKIM signature but you can still use SPF.
You may have a third party service sending email on your behalf. Maybe you use a third party service to send email newsletters. It’s still coming from your email domain, but it’s actually sourced from somewhere else, so you need to add their sending IP addresses to your SPF record, and make sure they stamp their outbound email with your DKIM signature. Some services already do this, but not all are on board yet.
If you’re using a service that won’t let you sign messages, or sends from an IP range that changes frequently, then you need to include an optional tag in your DMARC record. This tag - fo - tells recipients to check DKIM and SPF, but only bounce the email if it fails both tests. If it passes either SPF or DKIM, it’s probably OK. It’s not a complete solution but it’s OK until you can implement the ‘reject’ policy. It also means you don’t have to change all your services until you’re ready.
Getting to reject
This is where we’re trying to get:
v=DMARC1;p=reject;rua=mailto:dmarc@yourdomain.co.uk
p=reject means email from your domain that fails the checks gets rejected. It’s simple and powerful, particularly when you consider what it can help prevent.
DMARC is pretty effective in preventing spear-phishing; specific, targeted attacks against known or likely individuals. For example an organisation I worked for was targeted by spear-phishers. They sent an email pretending to be from a member of the management team asking people to put their corporate Twitter account details into a Google Sheet.
We used Google Sheets all the time, and although the request sounded suspicious they targeted enough people to find one distracted enough to put the details in. The account was taken over and abused, and it took a number of calls to Twitter to get the account back.
This case caused embarrassment, but similar attacks could lead to people transferring funds, leaking private data, or giving access to other systems for use in subsequent attacks. Having a DMARC policy with p=reject prevents those emails getting through.
Within government we’ve asked all organisations to use DMARC on every domain they have, and it’s now a requirement for digital services. To support that we applied a DMARC policy to GOV.UK: the top level domain for the UK government.
There is no legitimate email from @gov.uk, so we put in a policy and monitored. We quickly saw substantial abuse, so after making sure there really wasn’t any legitimate email we applied a p=reject policy. This blocked all email from that domain, so it can no longer be abused in that way.
Checking DMARC inbound is also important. Some services enable it by default, but others don’t, so check and turn it on if it’s there. If you don’t have the option think about moving to a service that does. If someone publishes a DMARC policy, they will have taken the time to make sure it’s right, so you should respect it.
Email providers have constantly updating filtering tools to help identify legitimate email. They are complex to maintain and can make mistakes. Having a published DMARC policy bypasses much of that and makes sure your email is delivered consistently.
Beyond that, email providers like Google are putting more and more emphasis on DMARC - using it to show end users when email is authenticated. When you open an email from an authenticated sender you’ll see their logo or profile picture to show it came from a legitimate source. If it doesn’t, you’ll see a question mark next to the name. So not having a DMARC policy can impact how your email is viewed by the recipient.
And so...
That’s the benefits of DMARC and how to do it:
- protect against email spoofing
- know where your email comes from
- improve trust and simplify email processing
There can be costs to implementing DMARC as well. It varies by organisation, but you may have to pay for DNS changes, and for a dashboard type service that helps you understand the reports.
There are a number of these available including some free ones, but it depends on your needs.
The biggest cost is time and effort. I’ve setup SPF, DKIM, DMARC with DNS records on a new domain in 15min, but it varies depending on the complexity of the environment you’re working in.
Analysing the reports, understanding where your email is coming from, fixing any issues, and iterating your record to get to a p=reject policy can take time. Monitoring helps but putting in the work to get to reject, and staying there to protect your domains, is well worth the effort.
If you have any comments or questions let us know by commenting below.