DKIM, short for Domain Keys Identified Mail, is an email authentication technology used to help verify that the sender of a message is trusted and that the message has not been tampered with in transit. When used in conjunction with other authentication technologies such as SPF and DMARC, DKIM helps decrease the impact of spoofing and phishing on end users, and because of its importance, DKIM signing is highly recommended by Mailbox Providers (MBPs) and not using DKIM is a contributing factor to messages going to the spam folder.
Where SPF is designed to verify that a given server is authorized to send mail on behalf of a domain, DKIM is designed to verify that the message itself is truly from the domain it claims to have been sent from. While it might seem like SPF could accomplish that on its own, a single MTA (Message Transfer Agent) could be used for multiple domains, potentially allowing a malicious peer user to send mail from another’s IP address, passing SPF, or a message could be forwarded from the receiving server to another system, which would fail the SPF check as that server may not be listed in the domain’s SPF record. DKIM would likely still validate in these scenarios, as long as the message is not tampered with.
How Does DKIM Work?
DKIM is based on a cryptographic signature, typically generated by either the first MTA the message is injected into or the last MTA before the message leaves the sender’s network (or even both). The server creates a hash of the body of the message, a list of the headers to be validated, and signs both, creating a header for the message similar to this:
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=mySelector;
c=relaxed/simple; q=dns/txt; i=foo@eng.example.net;
t=1117574938; x=1118006938; l=200;
h=from:to:subject:date:keywords:keywords;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzRThe signature is created using a private key stored on the server performing the signature, with a corresponding public key that gets published to the domain’s DNS records as a specifically formatted TXT record similar to this:
"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3
GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"The location of the record is identified using a selector, seen in the first example as s=mySelector, which is listed under a special _domainkey section of the DNS record, resulting in a host for the record of mySelector._domainkey.example.net.
When a receiving MTA receives a message with a DKIM signature, it uses the d= domain name and s= selector name to assemble the host to look up in DNS for the TXT record, and attempts to validate the signature in the header using the public key found in the record. If the signature validates, it’s a sign that the message is legitimately related to the domain listed in the DKIM signature header.
Multiple Signatures and DKIM Alignment
One important difference between SPF and DKIM is that while SPF specifically is built around checking the IP of the server that is sending a message and ensuring it matches the domain of the message envelope (often called the Return Path, Mail From, or RFC5321.from), the DKIM signature does not necessarily have to be associated with any aspect of the message, even though it is common for the signature to use the domain of the message’s From header address (often call the Friendly From or RFC5322.from).
This means that a sender can sign a message using any domain they want, and as a result, we can’t necessarily use DKIM to validate that the sender’s from address is authentic. This can actually be helpful in certain situations because it allows a party to the sending of the message to identify themselves as such, and allow their reputation to be attached to the message.
One example of this is when an Email Service Provider(ESP) wants to make it clear to an MBP that the message used their platform, even if it is not being sent from their domain. This makes it possible for the ESP to receive abuse reports for the message even though it is sent using their customer’s domain. Many messages sent through an ESP will be double-signed, once with a signature for the from header address’s domain, and once with a signature for the ESP’s domain.
In order to enhance trust, messages should be DKIM aligned. This means that at the very least, the domain used in the from header should match the domain used in the DKIM signature, at least at the organizational level (for example mail.example.com and example.com are the same at the organizational level). This shows the MBP’s server that the from header address can be trusted when shown to their users because DKIM has verified the authenticity of the domain.
How does DKIM Help Deliverability?
Mailbox Providers want to protect their users, which means cutting down on phishing and spoofing. They also want ways to reliably track the reputation of senders both by verified IP and domain. DKIM enables both of these things, and as such the MBPs encourage their use.
Unauthenticated mail is a risk to their users and will be subject to more scrutiny. DKIM is therefore an essential technology for senders that should be deployed and tested before sending begins.
Additional Reading
- DKIM Alignment – Matching of Header Domains – Certified Senders Alliance : Certified Senders Alliance (certified-senders.org)
- Help prevent spoofing and spam with DKIM – Google Workspace Admin Help
- DomainKeys Identified Mail – Wikipedia
- What is DKIM & DKIM Record and Why is it Important? | Mimecast
- RFC 5321 and RFC 5322 – Understand DKIM and SPF – Easy365Manager
