DKIM is short for DomainKeys Identified Mail. It is a mechanism to verify that some core information of an email message, such as its body, and the “From” and “Subject” lines, are authentic and haven’t been tampered with by someone while the email was in transit.
So when you send an email using a DKIM-compliant email service, some data of your email is digitally signed, and the signature is added to the email.
In case you’re curious: DomainKeys is the name of an old protocol used for the a purpose similar to DKIM. DomainKeys (the protocol) is now obsolete, and has been replaced with DKIM.
DKIM uses private key cryptography. In a nutshell, your private key is securely stored on email servers, and is used to sign outbound emails. Your public key, on the other hand, is stored on the DNS, where it can be retrieved by anyone to check DKIM signatures presented on your emails.
Before we progress, is is important to understand one basic building block of DKIM: the selector.
Seems complicated, but it is not.
A DKIM selector is just a name. A name you can use to tell email servers where in the DNS your public key can be found. The DKIM record, containing the public, plus other instructions, is stored in that DNS TXT record.
For example, if you own the domain example.com, the DNS record containing the public key for the DKIM selector my-selector is located at
my-selector._domainkey.example.com
DKIM selectors are an important concept because they’re the ones actually used to locate your domain private keys.
By using selectors, DKIM allows you to implement multiple key-pairs for the same domain. For example, you could have a pair of keys for your secure corporate email, another pair for marketing emails on Mailchimp, and so on. You just tell the sending server which selector to use when signing outboud messages.
The receiver, then, uses the selector to load your DKIM record.
A DKIM record is just a textual list of tags, just like DMARC and SPF records.
Generating a DKIM record itself is easy.
The challenging part is to generate a private/public key pair, so you can get the public one to put on your record.
We will look into key-pair handling soon, but suffice to say that you need your DKIM key encoded as a long string.
The public key in a DKIM record is encoded using BASE64.
Here's how a DKIM record looks like:
v=DKIM1;t=y;p=MIGfMA0GCSqGSIb3DQ(…)OJXwviLAsvIutZ6QIDAQABThe example above was abbreviated so we can see the whole record. Encoded public keys can be very long!
As you see, the DKIM record is a list of tags separated by semicolons (“;”).
Here is what tag in the example above means:
v=DKIM1 indicates that the record is a DKIM record. This must come first in the record.
t= contains a colon-separated list of flags with special instructions to email servers. In this example, y tells the servers that you are testing DKIM, so DKIM will still be applied, but not affect email processing.
p= contains the selector private key, encoded using BASE64.
There are a few other tags you can add to a DKIM record, apart from the ones we see in the example. Our example, though, has everything you need to enable DKIM on virtually any domain. See the DKIM RFC if you’re curious about other available tags.
A record as simple as the one above is enough to protect a domain using DKIM. The challenging part is: you need a public key…
Generating and configuring private/public key pairs for DKIM is complicated business.
You not only need to do it right — you need to make sure you’re doing it in a secure way.
Fortunately, almost all email services today, such as Google Workspace, Microsoft 365, and most domain hosting companies, already provide everything you need to set up DKIM, including the public key you need to add to your DNS (some hosting companies even add the key to the DNS for you).
This makes things way easier.
You should check your hosting company support pages about how to enable DKIM on a domain you host with them.
Here are instructions for some common email hosting services:
If your company manages its own email server, you’ll need to ask an experienced IT professional to:
Once you have your DKIM record set up as a TXT record in your DNS, and your email systems configured to sign outbound messages, you’ll be all set.
Here’s an example of email flow on a DKIM-enabled domain:
A user sends an email using an app (for example, Outlook on the desktop), or by using a web-based email, such as Gmail or Yahoo! Mail.
Their message reaches the email routing software – either on a company server, or at servers on Google’s or Yahoo!’s networks.
The email routing software selects some key headers from the email, such as the “From” header, "Date", “Subject”, etc., and digitally signs then using your private key (which they have stored securely on their server). The body of the email is indirectly signed too, via its content hash.
DKIM requires that the “From” header is always signed.
The email software appends the digital signature, the DKIM selector associated with the signing key, and the signing domain to the email. The message is finally sends it on the public Internet.
When the email reaches the server responsible for the recipient mailbox, the server extracts the DKIM selector from the message.
The received server then look up the DKIM record on the DNS. For example, if the signing domain is example.net, and the selector is my-selector, the server will look for a TXT record at
my-selector._domainkey.example.netAlthough not needed in the vast majority of cases, technically it is possible for a DKIM selector to contain more than one DKIM record. The receiving server is free to stop as soon as any one the records validate.
With the TXT records in hand, the server extracts and decodes example.net’s DKIM public keys for selector my-selector.
The server also extract the digital signature from the email.
The server then uses cryptographic algorithms to check if the digital signature extracted from the email is valid, given the public keys, and the headers of the email.
At the end of this process, if the digital signature is valid, then that means that the email wasn’t tampered while in transit. In this case, the email server can trust the email contents, the “From” header, and all other headers used to sign the email. DKIM is a pass.
If the digital signature is invalid, that would mean that, apart from an error in DKIM configuration, the email body or any signed headers were tampered. In either case, the DKIM check fails.
Up until now, we only discussed how DKIM works alone.
If you just implement DKIM, you’re already adding a strong layer of protection to your email system.
However, DKIM has no reporting feature built in the protocol. To get reports which will allow you to know what's going on with your DKIM-enabled email flow, you must also enable DMARC.
With DMARC you also get more control over the outcome of failed DKIM checks.
For example, without DMARC an email provider may drop emails right away when signature check fails. On the other hand, with DMARC you can tell them to deliver anyway (i.e. because you’re testing a new selector, etc.)
DMARC can use DKIM as an authentication mechanism to determine how or if an email should be delivered. To understand how this works we need to talk about DMARC alignment.
DMARC was a concept called alignment. It is used both for SPF and DKIM.
On a DKIM context, alignment is very simple to understand: it means that the domain in the “From” header of the email matches (“aligns”) with the one checked by DKIM.
If you think carefully, that makes a lot of sense.
That’s because DMARC is trying to ensure that what people see in the “From” of the email is legitimate, and to do that it is fundamental that the DKIM signature aligns with the “From” domain.
As we saw, DKIM is an email technology used to ensure that certain information from an email, such as its body content and the “From” header, amongst others, haven’t been tampered with by some malicious email server while the message was in transit.
DKIM is one authentication mechanism used by DMARC. DMARC does so by using the concept of alignment so that even if DKIM passes, the domain checked must be aligned with what is in the “From” line, because the latter is what DMARC cares about.
We hope you could get a good understanding of what DKIM is, and that this post can help you secure your domains by implementing DMARC. Happy emailing!