Over the past few weeks, I have been dealing a lot with spoofed email and unfortunately, in a few cases, the consequences of someone falling for a spoofed email. I do not blame the people who fall for them as the ones I have seen have been incredibly convincing.
Today’s Anti-spam solutions are good once they have been tuned a little (and for this I always advocate whitelisting known good domains), but they will often pass spoofed email because essentially, a spoofed email is a legitimate business email. In fact, the people crafting these things do not want them to be caught up in a spam filter as the email is designed to fool someone into thinking it is real, clearly another mechanism is required to handle such emails – Enter SPF, DKIM and DMARC.
SPF
SPF is the sender policy framework, it is probably the one email based txt record that most people already have set up and, in short, SPF will tell a remote server where an email should have originated.
An SPF record is just a DNS text record that uses various options to state which domains/ip’s you send email from. The SPF record has quite a few different options and different combinations of options.
For simplicity, most SPF records list just the domains that email can be expected to originate from and would look like this:
v=spf1 a mx include:[sending domain] –all
MXtoolbox offer a very handy SPF lookup at https://mxtoolbox.com/spf.aspx, this will break down any SPF record and detail and explain what it all means. For my example above:
DKIM
DKIM, more accurately known as Domain Key Identify Marker is a DNS record and a header that is injected into an email before it is sent. These two, in combination confirm that an email is legitimately from the sending organisation. DKIM uses a public/private key setup to validate the sending domain.
As a DNS record, DKIM has three parts, the text record, the selector and the payload. An example of a DKIM record from my own domain:
TXT mta1._domainkey v=DKIM1; k=rsa; p=[public key]
In this example, mta1 is the selector – this can be anything, many people call it “selector” or “mta”, it does not matter as long as it is followed by “._domainkey”.
Once again, MXToolbox have a good DKIM lookup tool at https://mxtoolbox.com/dkim.aspx and it will break down what each part of the record means.
DKIM, while just another DNS text record, can be a little tricky to setup as it requires a public key to be used, this is not the same as a certificate as a certificate includes the public key element. Fortunately, a lot of software that handles DKIM can also generate the necessary keys and helps make the process a lot smoother.
DKIM on Exchange/IIS SMTP
If you have an on-premises Exchange server or if you relay through IIS SMTP then you’re going to need a third party piece of software to inject the DKIM header into the outbound mail. There are quite a few options out there and most are fairly easy to setup as they’ll step you through the process with a wizard that can also generate the DKIM public and private keys and generate the necessary DNS record which you can then just copy and paste into your external DNS provider. Once done, you may need to wait a few hours for DNS to update before it all starts working.
It is certainly worth testing the DKIM DNS records through something like MXtoolbox as that can help find any problems you may have in the DNS record.
DKIM on O365
Enabling DKIM on Office365 is a matter of setting up two DNS records, unfortunately, the tech note at https://docs.microsoft.com/en-us/office365/securitycompliance/use-dkim-to-validate-outbound-email#Publish2CNAME is incorrect. The comments do list the correct CNAMEs require which look like this:
Host name: selector1._domainkey
Points to address or value: selector1-<your custom domain>._domainkey.<onmicrosoft domain name>
Once you have DKIM setup, you can confirm that the record is working by going to the DKIM testing page on mxtoolbox and typing in the selector and the domain, mxtoolbox will then run a check and tell you if there are any issues with the configuration.
Setting up DMARC
Once you have DKIM setup you can then consider DMARC, fortunately, DMARC is just a DNS record and does not need any of the public/private key elements of DKIM. All DMARC does is presents a DNS record that tells a remote server how it should handle any message that violates either the DKIM or SPF policies.
In DNS you’ll need a text record which tells the mail server what it should do should it encounter an email that fails SPF/DKIM resolution. That record will look something like this:
Above, you can see that the DNS record is made up of the version of dmarc and a series of actions that the mail server should carry out. For my example I have any failed mail setup to quarantine with status emails being sent to a monitoring mailbox.
DMARC has hundreds of options that can be set, the DMARC FAQ at https://dmarc.org/wiki/FAQ goes into all of this in great detail.
Finally, to confirm how your DMARC record is setup and to check that it is all working as expected, mxtoolbox have this link: https://mxtoolbox.com/dmarc.aspx
Drawbacks of SPF, DKIM and DMARC
While DKIM and DMARC are good for both validating the sender domain and confirming that an email came from the domain that it says it does and really should be setup on all email domains, there isn’t any protection when someone purchases a similar sounding domain name and sets up DKIM on that. Unfortunately, there is no fix for domain squatting. SPF, DKIM and DMARC DNS records can certainly offer a measure of protection; they are not completely fool proof.
