Every week I work with multiple customers that have experienced phishing attacks where their own domain has been spoofed by the attacker. The conversation always revolves around implementing SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) to secure their domain. For organizations that cannot use SPF because of its limits (the record is restricted to 10 DNS lookups), we usually discuss DKIM (DomainKeys Identified Mail).
|Note: See the resources section at the bottom of this article for links on these technologies.|
You (yes you!) can currently enable DKIM on your Office 365 tenant through a manual process. My colleague, Terry Zink, has a great blog post on the steps to take to enable DKIM signing for outbound mail from your Office 365 tenant: Manually hooking up DKIM signing in Office 365. Please check out his article (hyperlink in the previous sentence) for the steps on enabling DKIM.
If you have out grown the limitations imposed by SPF, then it’s time to investigate implementing DKIM.
Why DKIM and not just SPF?
The biggest reason companies turn to DKIM is because of a limitation on SPF. SPF records can only contain ten DNS lookups. If you are an organization that uses a lot of third party companies to send mail on your behalf (where they spoof your domain) then your SPF record may contain more than ten DNS lookups, which essentially renders it useless for protecting your domain against spoofing. Most receiving servers will stop evaluating SPF records once they have hit the DNS lookup limit of ten and at that point will stamp “permerror” for the SPF result.
This is where DKIM comes in. First let’s look how it works, and then we’ll look at how it overcomes the DNS lookup limit imposed by SPF. From an EXTREMELY high level view, here is how DKIM works.
- You obtain a certificate for DKIM signing and publish the public key in your public DNS.
- Your mail server calculates a hash for all outbound messages.
- This hash is then encrypted with the private key of your DKIM certificate, and this value is placed in the header of the message
- The Receiving server obtains the sending domains public DKIM key from DNS and uses this to decrypt the hash value that the sender placed in the header. We’ll call this value X.
- The receiving server then re-calculates the hash for the inbound message. We’ll call this value Y.
- If X = Y, the receiving server knows that the message was not tampered with in transit.
|Note: If you need a refresher on why the above works, do some searching on Public Key Cryptography.|
Even with DKIM, you will still want to publish a DMARC record to prevent attackers that spoof using different MailFrom and From headers. See my previous article Using DMARC to Prevent Spoofing.
For DMARC to pass, you need either SPF or DKIM to pass. This means that you can leave an existing SPF record in place while you implement DKIM. Third parties that don’t support DKIM can remain in your SPF record, while third parties that do support DKIM only need to be giving your DKIM private key.
One quick note, EOP does not allow exporting of your private DKIM keys. You would need to set up DKIM with a 3rd party gateway separately. Or, if routing through Office 365 from the gateway, set up a connector using TLS-based authentication (preferable) or IP/domain-based authentication. In that case, Office 365 would attribute the message to the organization and assign the DKIM signature.
The above explanation of DKIM is from 60,000 feet. It is very high level and there are many configuration options and decisions that you’ll need to consider before implementing DKIM. For technical specs on DKIM, DMARC, and SPF, see the links in the Resources section of the article.