There’s a new email standard in town and it’s causing your email to end up in the junk pile. It’s called DKIM and recently it became the new enforced standard for spam filtering. If you’re an Office 365 subscriber you’ve probably noticed that there’s been a big uptick in the number of legitimate emails ending up in your junk folder because Microsoft is one of the many spam-filtering services that is now enforcing the use of DKIM. If you’re in the habit of sending email — and who isn’t — and you haven’t yet configured DKIM for your email domain, then your email is likely ending up in the junk folder instead of reaching your intended recipient.
Why are they doing this?
This change is making life difficult for many an email administrator but there’s a good reason behind it. A staggering 93.6 percent of malware seen in 2017 arrived via email, according to the 2017 Cisco Cyber Security Report. We’ve got to step up our game in protecting our email.
What is DKIM?
DKIM is an acronym for Domain Key Identified Mail. It works with your Sender Policy Framework (SPF) record and using public crypto keys it dramatically lowers the odds that your email has been spoofed. Having a DKIM record is almost a free pass to your recipients’ Inbox. In order to get that free pass, though, your recipient needs to have a DMARC record. DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. That’s some big words for making sure that your mail isn’t reported as phishing or spam.
Boiling this all down to reality means that we now need four records to make our email flow from and to its intended destination. These are all DNS records: MX, SPF, DKIM, and DMARC. The latter three are all TXT records while MX is a category unto itself in most DNS servers.
How do they work together?
DMARC counters the illegitimate use of the same domain name as yours in the From field. We’ve all gotten those spoofed messages where the address in the From field looks legit but isn’t. It’s spoofed and that type of spoof is difficult for people to determine when reading their email. It uses both the SPF and the DKIM records to tell the receiving server how to deal with mail that it might get from you that doesn’t match those.
DKIM helps this process along by attaching a digital certificate to the From address, which verifies that the email was sent from your email server and hasn’t been modified along the way. SPF lists the IP addresses of only legitimate email servers for your domain.
So in summary, from the point of view of the receiving email server, it knows that this piece of mail was sent from your email server and the From address has not be modified along the way. And if any of those things isn’t true, DMARC says either Do Nothing, Reject, or Increase the Spam ranking. But remember that these are now being enforced by mail servers so the other option is that if a mail arrives without a complete set of records it goes directly to the Junk file.
Setting up your SPF, DKIM, and DMARC records
I’m going to talk about this in terms of Office 365 but it will apply to any email system. These settings are all entered in your public DNS records, not within the mail server itself.
Create an SPF record
This is the most difficult record to create so I recommend using an SPF generator wizard. I like the one from MXToolbox.com but there are many others available. The wizard is going to ask you a few questions about your email delivery. You will need to know if your website sends mail, if you have any other servers or services that send mail as you. For example, some SQL applications send mail directly and, of course, your antispam service does too.
For a simple system where mail is only sent from your spam-filtering service, in this case, Office 365, your record will look something like this:
V=spf1 include:spf.protection.outook.com -all
Create a DKIM record
DKIM is record type CNAME. In your public DNS you will enter two selector records that look like this:
If you are an Office 365 customer, note above that your record is for the onmicrosoft.com domain because it is the sending server for your domain. If you are not an Office 365 customer, then you will leave the onmicrosoft part above out. Just make sure that you are using the full domain name where your email server resides.
One more thing for Office 365 customers: You need to tell Microsoft that your DKIM records are ready for use. You’ll do this in the Exchange admin console. Under the Protection category, you’ll find the link for DKIM. Once you’re on the DKIM page you’re going to select your domain, not the onmicrosoft.com domain, and click the word Enable on the right. Microsoft will then verify that the records exist and are correct. If not, they’ll offer the suggested change. Once you’ve successfully enabled DKIM it will look like the image below.
Create a DMARC record
The DMARC record type is TXT. In your public DNS you will enter one TXT record that looks like this:
_dmarc _dmarc.yourdomainhere.com 3600 IN TXT “v=DMARC1; p=none”
The p=none means that you’re telling that recipient to do nothing if your emails fail the spoof test. That file is for testing purposes but you’ll want to increase that to p=quarantine to cause the mail to hit their junk folder or p=reject to cause the server to reject any spoofed email from you altogether. This makes DMARC a good neighbor policy. But if your emails are being spoofed and not reaching the intended recipient, wouldn’t you want to know? Of course you would. DMARC has you covered. You can add a reporting option of [email protected] and you’ll get notified with forensic content you so can troubleshoot the issue. This then would make your DNS record look like this:
_dmarc _dmarc.yourdomainhere.com 3600 IN TXT “v=DMARC1; p=reject ;[email protected]”
Notice that in the case of the DMARC record, if you are an Office 365 customer that you are not using the onmicrosoft.com domain but this time you are just using your personal domain name. Also notice that the record starts with an _. I only point that out because it’s a bit unusual.
The blacked out bit is the name of your domain.
Email: What’s next?
Now that you’ve got all of your DNS records into place that can identify that your email is coming from you, what about all of that mail that you’re receiving from people that haven’t implemented this yet? Email is the No. 1 vector for malware delivery. So here’s what we can do:
- Be a good neighbor by adding SPF, DKIM, and DMARC.
- Train employees to identify bad email.
- Deploy a great spam filter.
- Deploy a great anti-malware solution.
- Test your users’ ability to detect phishing and malware.
All of these are pretty easy to do, except for that training piece. I’m on a sort of crusade to get employers to invest in training employees to improve their application usage skills. Sure we have employees showing up for their first job after university at 22 with 21 years of computer experience but that just means they know how to push the buttons and how to use a home computer. They need training on many things for business computer usage including identification of phishing, spam, and malware in email. Join my crusade and let’s raise the level of awareness in our user base and put this spam issue to rest. Once the profit levels fall, the bad guys will move on.
Featured image: Pixabay