According to Neil Wynne and Andrew Walls of Gartner Research, “email will remain the primary targeting method of advanced targeted attacks” through the end of the decade.
Email spoofing – the impersonation of someone inside of your company through the use of a rewritten “From:” mail header – is one of the most common ways that cybercriminals attack companies today. Relying on Secure Email Gateway technology alone is insufficient to protect your company, as impersonation attacks are specifically designed to not trigger the perimeter defenses these systems provide, despite marketing language to the contrary.
However, it is possible to fight back. Robust defense in depth works; combining strong authentication systems with effective data-driven email analytics can catch and automatically remediate even highly targeted spear phishing, whaling, and business email compromise.
In this free guide, we look at the second fundamental component of email authentication: DomainKeys Identified Mail, or DKIM. (If you missed our guide on SPF, we suggest starting there, as DKIM builds on SPF!)
What Is DKIM?
According to DKIM.org, DKIM “provides a method for validating a domain name identity that is associated with a message through cryptographic authentication”. In other words, using DKIM, an organization can prove that a particular message both came from their domain, and was not changed in transit to the recipient.
It was born out of the combination of two earlier standards: Yahoo!’s DomainKeys, and Cisco’s Identified Internet Mail. Formally outlined in RFC 5585, DKIM comes down to a fairly straightforward set of technical steps:
- An organization sending mail creates a special kind of DNS entry to store a DKIM record, which contains both their identity as well as a public crytographic key
- Upon sending mail, messages (or parts of them, such as those messages’ Subject and Body) from that organization are signed by the corresponding private key, with the result stored in a message header
- Upon receipt, mail servers that respect DKIM verify that the incoming message (a) actually came from the purported sender, and (b) was not changed while in transit, using the public key stored by the domain used to validate the DKIM header
In other words, DKIM helps organizations prove that their outgoing mail is actually from them, at least in part. (It isn’t a complete solution, for reasons we outline below.)
The Strong Authentication Chain
DKIM works best when it is implemented alongside SPF, which we’ve covered previously. Together, SPF and DKIM form the first two links in what we call the Strong Authentication Chain — and they help organizations prove that their outbound mail is sent from a server which they authorize to send on their behalf, and that the message is both from their domain and has not been changed.
Both Google Apps and Office 365 will enable DKIM for you by default, but these default rules won’t be sufficient when you reach the final link in the Strong Authentication Chain, DMARC.
In a future post, we’ll look more closely at this third protocol, which extends the foundational protections of SPF and DKIM by checking for alignment between SPF+DKIM and the “From: ” line in your email, but for the purposes of this post, it is sufficient to state that both SPF and DKIM should be manually enabled by everyone using Google Apps or O365.
The good news is that this is easy. Below, we’ll walk through how to set up DKIM for both Google Apps and Office 365, step by step. Let’s get started!
DKIM for Google Apps
If you’re running Google Apps, DKIM is fairly easy to implement, and can materially improve your email security. You need to do only a few things to get up and running:
- Create your DKIM key
- Add the key to your DNS record
- Enable DKIM signing in the Google Apps admin console
1a. Creating a DKIM Key
To create a Google Apps DKIM key, first open GMail, and then click the Gear Icon -> Manage this Domain:
Once you’re inside of the Admin page, navigate to Apps > Google Apps > Gmail > Authenticate email:
In this screenshot, we’ve obfuscated our key; you likely won’t have a key enabled yet, so click “Generate New Record” to create one. For most organizations, the defaults are fine here – simply click “Generate” on the dialog box that pops up:
1b. Creating DKIM DNS Record
With the key created, you’ll next need to add it to your DNS record.
DKIM records are created as TXT records, and should mirror what you see in the Google Admin console above. The name of the record — different registrars refer to this slightly differently, but it’s the field that is NOT the value — should be:
google._domainkey.your_domain.com, where your_domain.com is the name of your domain.
The value here should be the TXT record value from the Google Admin panel, exactly as written. Breaking down what’s in that:
- v=DKIM1 says that you’re using version 1 of DKIM. That’s all that there is so far, so just leave this as is.
- k=rsa denotes the type of key you’re using. rsa-sha256 is the default; leave this as is, too.
- p=[your key] is the public key value that will be used by recipients to validate signed messages they receive from your domain.
1c. Enable Signing
With the key created and the DNS record in place — remembering that DNS has a propagation time, so this may require a delay of a few hours to take effect — you can turn on signing. To do so, go to Apps > Google Apps > Gmail from the Admin panel, and navigate back to the Authenticate email screen.
Once there, click “Start Authentication”, on the bottom right:
That’s it! You’re now using DKIM to sign your messages, a great step forward in protecting your organization from outbound impersonation.
DKIM for Office 365
DKIM setup in Office 365 is slightly different from Google Apps, but don’t worry – we’ve got you covered. We’re going to take just two steps here:
- Create two CNAME records
- Enable DKIM signing in the Office 365 Exchange Admin console
1a. Creating your CNAME Records
CNAME records are a type of DNS record, used to tell the DNS system that the “canonical name” of some domain is actually just an alias to some other domain. While understanding CNAME and DNS records isn’t required to implement DKIM on O365, it’s helpful to understand that Office 365 goes through the hassle of rotating your keys on your behalf — thus the need for TWO CNAME records for every O365 domain you own.
Both records take the same form:
Host name: selector1._domainkey Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain> TTL: 3600 Host name: selector2._domainkey Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain> TTL: 3600
What you need to customize here is the bold text – the domainGUID and the initialDomain values.
Your domainGUID is easy to look up: it’s right in your MX record. If you’re on a Mac or a UNIX machine, you can look this up via a terminal, using the dig command — in the example below, the GUID is “flyingdeliveries-com” — note that this has a hyphen in it, and it’s the first part of the record on the right-hand side of the result line:
If you’re daunted by the use of the terminal, you can also look this up online via the website MX Toolbox. Just type your domain name in, and you’ll see the same GUID as the text before “.mail.protection.outlook.com.”.
initialDomain is the name of the domain you used when you signed up for Office 365; you likely already know this, as it should be the “primary” domain of your company. This isn’t always true, of course; some organizations have aliased domains that they use, but these tend to be circumstances that are well known, not the norm.
Once you have the format for these two CNAMEs (or additional sets of two, for any additional domains you’re using with Office 365), you’re ready to publish them via your DNS registrar.
1b. Enable DKIM Signing for Office 365
With the CNAMEs in place, it’s time to start signing your outbound mail. The easiest way to do this is via the Office 365 Admin Center.
In the Admin Center, navigate to protection, then find your domain and click “Enable”:
That’s it! You’re all set, and signing your outbound email properly with your own DKIM key.
Is DKIM Enough?
DKIM (and especially SPF and DKIM together) are a great combination. However, it’s important to note that these two technologies are insufficient to prevent many kind of inbound mail attacks.
The challenge is that DKIM cannot verify anything other than the data integrity between the time of signing and the time of verifying. Attacks from valid domains that pass DKIM will not be marked as “suspicious”; look-alike domains, imposter DKIM verification headers, and display name spoofing are just a few of the common and highly effective attacks that bypass DKIM and land in inboxes.
Effective email security requires “defense in depth”, and while SPF and DKIM are an important component of that strategy, they are insufficient on their own.
GreatHorn is the world’s first and ONLY comprehensive and fully automated inbound email protection platform. Requiring no setup steps, no change to mail routing, and no reliance upon email gateways or insecure blind copies of mail to third parties, it co-exists with SPF, DKIM, and DMARC to provide the only comprehensive spear phishing protection on the market.
With GreatHorn Inbound Email Security for Google Apps and Office 365, you can take control (via the GreatHorn Policy Engine) of how to handle messages that don’t get caught by SPF and DKIM. For example, GreatHorn allows you to:
- Extend mail authentication analysis to include content analytics, quickly identifying wire transfer frauds, CEO impersonation attempts to steal employee W2s, and other forms of PCI, PII, and PHI theft
- Detect and remove messages that come from domains that are look-alikes of your domain – for example, yourcompany.com vs yourcornpany.com
- Quarantine messages that violate GreatHorn policy, removing them from the inbox and placing them into a folder, similar to a Spam folder
- Automatically flag suspicious or anomalous messages to your users, providing truly effective realtime end-user awareness, rather than often ignored training
Setting up SPF and DKIM are important, but if you’re running Google Apps or Office 365, and want to truly protect your organization against inbound email threat, GreatHorn stands alone in its ability to defend your users.