This tidbit is part two in a series on understanding some mechanisms available to you for protecting e-mail sent from your domain. We covered this topic in last month’s Tech Talk / SYSOP meetings but for all those that missed them or those that want a refresher, I am covering this again here in this series.
Putting into practice what we share here will not only potentially help with protecting you from inbound spoofed SPAM and malware but also help ensure that your domain’s legitimate e-mail actually gets delivered. Many of the larger e-mail providers such as Google or Microsoft are becoming more suspicious of e-mails received that can’t be verified as from a legitimate sender which is exactly what these mechanisms are designed to do.
All of these methods involve setting up special DNS records in your domain’s master zone file that help tell potential recipients of mail from your domain whether or not that mail came from a location authorized by you to transmit mail on your behalf.
Over this series, we are going to look at three different mechanisms that if all employed can work in concert with each other to help protect your e-mail:
• SPF – Sender Policy Framework
• DKIM – Domain Keys Identified Mail
• DMARC – Domain-based Message Authentication, Reporting, and Conformance
All are set up around DNS TXT records in your DNS domain's authoritative zone file
This week - DKIM records
We covered SPF records in my last post so this time we talk more about DKIM.
Use of DKIM records starts a process to apply an encrypted key to each outgoing message sent from your authorized mail server. If the receiving server can successfully decrypt and validate the key than the receiver can know with certainty that the message was valid.
Two keys are used with DKIM:
• Private key – generated and known only to your server and used to encrypt the header signature of each e-mail sent by the server.
• Public key – used by the receiver to decrypt the signature. This key is contained in the DKIM record in your DNS zone file
The format of a typical DKIM record looks something like this:
*_domainkey.mydomain.com IN TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAraC3pqvqTkAfXhUn7Kn3JUNM
Those of you that have worked with certificates and certificate signing requests should find some familiarity with what you see in there. The process for creating and retrieving the needed key (all of what you see after the p=) is similar.
*_domainkey – is a required” host” entry, the “*” can be anything unique in your domain but obviously must match what you used when you generate the private key on the sending server environment.
mydomain.com is simply the identifier for your domain name
IN TXT – is the record identifier in DNS that this is a TXT or “Text” record type
v=DKIM1 – identifies the version of DKIM
k=rsa – identifies the algorithm of the key that follows
p= - identifies that what follows is the actual public key
The exact DKIM private / public key generation and installation process is typically defined by your specific e-mail provider. Some helpful links are provided below for the most popular providers for our clients:
Google Apps - https://support.google.com/a/answer/174126
Office 365 - https://docs.microsoft.com/en-us/office365/securitycompliance/use-dkim-to-validate-outbound-email
Here is a third-party link with information on using DKIM with various versions of Microsoft Exchange Server:
https://www.emailarchitect.net/domainkeys/kb/dkim_exchange_2007_2010_2013.aspx
If you have questions about using DKIM or want help implementing DKIM for your domain contact our support team.
In our next Tidbit on this subject, we will explore the use of DMARC records.
Until next time…….
You must be logged in to post a comment.