DMARC
Domain Message Authentication Reporting & Conformance
DMARC is the framework that combines SPF and DKIM to reduce spam and email abuse. RFC7489 has been an approved standard since 2015.
High-level description to give it some context
DMARC – what is it?
Emails are digital messages which consist of headers and a body. Headers are a collection of fields including from, to, and subject. Usually, people tend to focus on the body of the email. However, it can be beneficial to be able to look for specific header fields to help determine the authenticity of an email. It is somewhat analogous to handling monetary notes. If you receive a monetary note and want to determine its authenticity, you can look for features like a watermark or hologram. Hence, with a basic understanding of DMARC, you should know what headers to look for to validate the authenticity of any email.
One crucial piece of terminology to understand is what is meant by domain. If your email were me@organisation.org.uk, the domain would be everything after the @. In other words, organisation.org.uk
The DMARC framework relates to controls around the domain. That is whether an email has come from the domain (i.e. organisation) shown or if it has been spoofed or faked.
I think about DMARC in 3 distinct ways.
- It’s a governance framework designed to protect the organisation owning the domain
- It enables an organisation to send out email that doesn’t fall foul of SPAM filters
- It enables people within an organisation to spot fake emails
1 Governance Framework
It is a way of configuring email, making it much harder for anyone to spoof email from the organisation’s domain. It’s relatively trivial to spoof email that doesn’t have DMARC protection configured. See the video in the link below for a short explanation:
https://www.ncsc.gov.uk/information/mailcheck
The organisation’s support team must configure the following controls, which are not generally accessible to the regular user.
Anti-spoofing
DMARC – establishes policy to be used by servers receiving emails claiming to be from this domain
SPF – specifies which email servers are authorised to send email from this domain
DKIM – defines the domain key to be used for signing the outgoing emails by the sending server
PTR – reverse DNS record which maps a domain name back to an IP address
Email Privacy
TLS – TLS, or Transport Layer Security, is a cryptographic protocol that ensures secure communication
MTA-STS – is a security standard for email that ensures inbound emails are securely transmitted using TLS encryption
From a governance perspective, this is analogous to virus scanning. Just as virus scanning doesn’t completely prevent you from ever getting a virus, it would be negligent not to have adequate anti-virus scanning for an organisation. Likewise, configuring DMARC controls doesn’t completely prevent email abuse; it would be just as negligent not to have them adequately configured.
2 Enhanced sending of emails, particularly bulk email
Suppose you don’t authorise the sending server by having SPF correctly configured, and you don’t digitally sign using DKIM. In that case, the likelihood of the email ending up in the recipient’s spam folder somewhat increases and will likely rise as DMARC becomes more adopted. Sometimes, you become aware that the email you send doesn’t reach the recipient, but often, it can be a hidden failure. If DMARC reporting is used, an organisation can monitor rejected emails.
3. Ability to spot fake emails
Let’s face it: if you receive an email invoice, you want to spot whether it is genuine or fake. Just as with monetary notes, you wouldn’t usually check every single note you handle nor check every email, but if you have any doubts, you want to know how to verify the email sender’s authenticity.
Is the SPF check in the header a ‘pass’ or a ‘fail’?
Is the DKIM check in the header a ‘pass’ or a ‘fail’?
The DMARC rules state that an email must pass the SPF and/or DKIM checks to ‘pass’ the DMARC check. That said, I get very suspicious of any email that doesn’t ‘pass’ SPF. Note that it is not uncommon for DKIM to fail if the email has been forwarded, etc. This is why it is good practice to comply with both SPF and DKIM so that one check can fail and the email won’t be rejected outright.
A good starting point in terms of appreciating the landscape for your own domains is to sign up for Valimail’s Free Monitoring Service:
https://www.valimail.com/try-monitor-free
Tools for checking DMARC, SPF and DKIM
If you use Mozilla Thunderbird, I highly recommend using https://addons.thunderbird.net/en-us/thunderbird/addon/dkim-verifier
A good way to understand how your email is configured is to use the free online checker provided by the National Cyber Security Centre (part of GCHQ).
https://checkcybersecurity.service.ncsc.gov.uk/email-security-check/form
Another free and enlightening resource is well worth sending an email to see a detailed analysis.
Another free yet invaluable resource is the online interactive checker provided free by uriports.com.
Another free tool that provides a good high-level summary.
Google can be beneficial if you have received an email and want to understand what you see in the headers.
https://toolbox.googleapps.com/apps/messageheader/analyzeheader
URIports has a set of easy-to-understand online tools for DMARC
https://www.uriports.com/tools
SPF
Sender Policy Framework
SPF is a way of specifying a group of servers authorised to send emails on behalf of an internet domain.
This requires looking up resources on the internet to determine if the server identified as the email’s sender is indeed authorised to send it.
https://www.spf-record.com/spf-lookup
DKIM
DomainKeys Identified Mail
DKIM is a method of digitally signing emails to identify them as originating from a specific domain. Normally, the receiving mail server adds headers indicating the status of the authorisation check, whether it has passed or failed. However, this doesn’t always give the whole picture, and further analyses of the email and headers can be useful.
The following link is an easy online way of analysing email headers. Be careful not to paste anything sensitive into this web portal.
https://www.appmaildev.com/en/dkimfile
If you would prefer to be able to analyse emails locally on your PC, why not try installing Perl and the Mail::DKIM::Verifier package from meta::cpan
I’d recommend installing the latest MSI installer for Strawberry Perl.
https://metacpan.org/pod/Mail::DKIM::Verifier
Then download the tar.gz from meta::cpan and install, copy, and paste the following into your command prompt.
cpanm Mail::DKIM(This single package includes both the DKIM Verifier and the ARC Verifier)
Here is a Perl executable script which uses the above modules to produce a readable report locally.
https://nigelpentland.co.uk/perl/dkimv.txt
Follow the link above, select all the text (Ctrl-a), copy (Ctrl-c) and paste into a text editor, and save file as
dkimv.plTo execute the script open a command prompt, and type dkimv.pl followed by the filename of a text file containing email headers such as email.eml.
e.g.
dkimv.pl email.eml
Down the Rabbit Hole
Here are some links that give various insights and references, which I have found very enlightening.
More techie online tools – https://emailstuff.org
Metaspike has a lot of interesting content on their website, and I would recommend the following as a good starting point – Leveraging DKIM in Email Forensics
Next is a relatively old but still interesting video which gives lots of insights as well as helpful background about the evolution of DMARC, SPF and DKIM – DomainKeys Identified Mail Technology
This is a video from the CEO of Metaspike giving anecdotal stories of forensically analysing email and is full of insights – Forensic Investigation of Emails Altered on the Server | SANS DFIR Summit 2019
Here is a full explanation of how to calculate a DKIM signature by hand (complete with Python code and superbly documented) – Verifying a DKIM signature by hand
For completeness, here is the RFC for DKIM-Signature for those wishing to delve deeper – https://datatracker.ietf.org/doc/html/rfc6376
For background, here is the RFC for DomainKey-Signature, the pre-runner to DKIM-Signature and subtly different – https://datatracker.ietf.org/doc/html/rfc4870
Manual calculation of the body hash “bh” as found in the DKIM Signature block
First, you need to capture the body and canonicalize it. Two methods can be used as defined in RFC6376, and one of these methods will be referenced in the DKIM Signature block.
The “simple” Body Canonicalization Algorithm
Here is a Perl script with a caveat: I only remove a single empty line from the end of the message when the RFC requires ALL empty lines to be removed.
https://nigelpentland.co.uk/perl/simple.txt
or
The “relaxed” Body Canonicalization Algorithm
Here is a Perl script with a caveat: I only remove a single empty line from the end of the message when the RFC requires ALL empty lines to be removed.
https://nigelpentland.co.uk/perl/relaxed.txt
Follow the links above, select all the text (Ctrl-a), copy (Ctrl-c) and paste into a text editor and save the file as either
simple.plorrelaxed.pl
To execute the script, open a command prompt and type the script’s name followed by the filename of a text file containing email headers, such as email.eml.
e.g.
relaxed.pl email.eml > body.txtThe vast majority of emails use relaxed canonicalization for the body hash, the exception being email from gov.uk which typically uses simple.
Then once you have canonicalized the body use the following OpenSSL command. For this example I have used body.txt as the file containing the canonicalized body text.
openssl dgst -sha256 -binary body.txt | openssl enc -base64
Note: the above command assumes sha256 hashing, so if you come across the older sha1 referenced in the DKIM Signature block you will need to change this parameter from -sha256 to -sha1
Useful info when investigating why body hash fails to compute – https://en.wikipedia.org/wiki/Whitespace_character