DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails.
DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain. It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message.
The recipient system can verify this by looking up the sender’s public key published in the DNS. A valid signature also guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed. Usually, DKIM signatures are not visible to end-users, the infrastructure rather than the message’s authors and recipients verify and affix them. DKIM specifications are defined n the RFC 6376 .
DKIM allows the recipient server to make sure (or to verify) that the received message was sent by the genuine sender of the associated domain and that content of the original message was not altered on its way.
How Does SPF Differ From DKIM?
While DKIM allows receiving mail server to verify the authenticity of message content and its association with sending domain, through looking up the public DKIM string, associated with particular sending system, the SPF allows checking if received email indeed came from an authorized source (eventually from an IP address), defined by the sender via publishing authorized “sending sources” list in DNS.
What is the advantage of using DKIM over SPF?
- In the majority of cases, the DKIM signature (or the result of previous verification) is being retained during email auto-forward, which allows receiving server to make sure that received email is genuine (though there a few exceptions, which are mentioned in the next point), while SPF almost always breaks during email forwarding (with the most obvious exception when auto-forwarding takes between recipients within the same domain).
- Auto-forwarding messages use 2 methods:
- Some ESPs (e.g. Outlook/Hotmail, iCloud, MailRu) retain original smtp.mailfrom (return-path) address, so SPF authentication check results show domain alignment but fail since smtp.mailfrom domain’s SPF record does not cover forwarding server’s IP address.
- Other ESPs (e.g Gmail/G Suite, O365, Yahoo, Yandex Mail) rewrite smtp.mailfrom (return-path) address with their domain, so SPF authentication check results show domain misalignment but pass since in the rewritten smtp.mailfrom domain’s SPF record includes the forwarding server’s IP.
So, in both cases, SPF check fails, since the prerequisite of Header From domain alignment with smtp.mailfrom domain and its SPF record validation never happen.
When Can DKIM Fail the Check?
DKIM check fails happens when the DKIM authentication checks fail. Here are possible reasons for a DKIM fail:
- DKIM signature domain and sender (Header From) domain do not align;
- DKIM public key record, published in DNS, is incorrect or is not published at all;
- Sender’s domain DNS zone is unreachable for lookup. This is quite a usual situation for poor hosting providers;
- The length of the DKIM key, used for signing, is too short. Nowadays 1024 and 2048-bit long keys are supported. So if your webmail hosting provider signs emails with smaller length DKIM key, the outcome is DKIM fail: the signature did not verify;
- There were modifications in the message body during auto-forward.
Let’s dig into the last case.
E.g. when the forwarder appends the compliance footer text to received email and auto-forwards it, it alters the original message content, so it breaks message integrity. As a result, the receiving server will not be able to verify the DKIM signature, and the DKIM verification result, included in the received message header will be read as “dkim=neutral (DKIM signature body hash not verified)”. Below is the extract from the Gmail message header.
Authentication-Results: mx.google.com;
dkim=neutral (DKIM permfail “body hash did not verify”) [email protected] header.s=google header.b=QR1SAS6X;
arc=pass (i=2 spf=pass spfdomain=company.com dkim=pass dkdomain=company.com dmarc=pass fromdomain=company.com);
spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender)
smtp.mailfrom=”[email protected]”;
dmarc=fail (p=REJECT sp=REJECT dis=NONE arc=pass) header.from=company.com
Is it Possible to Avoid DKIM Fail During Checks?
All listed above cases, except the last one, are technical issues that you can address them by taking relevant actions.
In regards to the last case – it is not realistic to avoid it, since you cannot force recipients to stop appending compliance footers, which is quite usual practice and sometimes even mandatory action, particularly in a corporate environment.
What will happen with such auto-forwarded emails, which fail both SPF and DKIM, when you enforce DMARC “reject” policy?
- A few years ago this was a real challenge for recipient servers to handle such non-authenticated but genuine emails but now, when many major ESPs started to use Authenticated Received Chain (ARC) Protocol, the situation has improved.
- ARC is a protocol that allows each mail server, processesing the message, to identify which mail server handled it before and what the message’s authentication assessment was at each step in the handling chain.
So, when e.g. Google receives an email, which failed both SPF and DKIM alignments checks, they can identify from the message header if an email had passed SPF and DKIM alignments check with previous mail server, which forwarded a message to Gmail / G Suite and if it passed, Google downgrades the sending domain “reject” policy to either none or quarantine, so the “reject” policy does not apply to such messages (see the screenshot below).
Why do I See DKIM=Neutral (DKIM Permfail “Body Hash Did Not Verify)?
When you get the status of a DKIM signature “body hash not verified”, that means the computed hash of the message body does not agree with the body hash value stored in the “bh=” tag of the DKIM signature.
Some corporate email servers append inline text to the bottom of incoming emails before anti-spam agents parse them. In situations like that, the body hash would be invalidated.
The email(s) from this source failed the DMARC check. This means that the email was not DMARC compliant, therefore SPF and DKIM are both invalid. This can mean two things:
The source failed the DMARC checks because DKIM and/or SPF were not set up correctly;
The source failed the DMARC checks because someone has sent malicious emails on behalf of your domain.
It is important to investigate all sources that appear in the failed section to identify the sources as valid or as malicious. If you recognize a source as legitimate, you can dig in the data and make sure to set up and align SPF or DKIM correctly. If you don’t recognize a source you will have to investigate this, because this source might try to send malicious emails on behalf of your domain.
Several reasons that may cause DKIM= neutral (body hash did not verify)
- A forwarder, a smart-host, or another filtering agent modified the body of the email;
- The signer calculated the signature value incorrectly;
- Someone spoofed the email and signed it without having the correct private key.
- The public key specified in the DKIM-Signature header is wrong;
- The public key published by the sender in their DNS is wrong;
The steps that you can take to investigate the source:
- Do I recognize the source as a partner of my company?
- Search on Google what kind of source this is.
- Does the source appear on RBL blacklist websites?
- Check the forensic reports to see what kind of emails the source sends.
- If the source is valid, search for documentation to set up DMARC correctly.
- Contact the source.
DKIM fail in reports
Like SPF, DKIM is a critical aspect of DMARC. When DKIM alignment fails—or when the d= value in the Header From does not match the d= value in the DKIM signature—it can negatively impact deliverability as mailbox providers may send the message to the spam folder or block it entirely.
Mistake: Multiple DKIM signatures
The spec permits emails to have two DKIM signatures. The first signature had a d= value matching the Header From the domain of the email and the second had a d= value of a domain, owned by the third-party sender.
As a reminder, for a message to pass DKIM alignment, the d= value in the DKIM signature must match the d= value in the Header From address. By drilling down into the result reported by each mailbox provider, we could see that the mailbox providers reporting both DKIM pass and DKIM alignment were using the d= value in the first signature, which matched the d= domain in the Header From to check alignment. Because of this match, the mailbox providers reported a positive result.
The culprit can be the d= value in the signature, as it did not match the Header From address.
The solution: Get rid of the second DKIM signature
A sender creates the DKIM by “signing” the email with a digital signature. This “signature” is located in the message’s header. The sending mail transfer agent (MTA) generates the signature by using an algorithm applied to the content of the signed fields. This algorithm creates a unique string of characters or a “hash value.”
When the MTA generates the signature, the listed domain stores the public key used to generate it. After receiving the email, the recipient MTA can verify the DKIM signature by recovering the signer’s public key through DNS. The recipient MTA then uses that key to decrypt the hash value in the email’s header and simultaneously recalculate the hash value for the mail message received. If these two keys match, then the email has not been altered, giving users some security knowing that the email did originate from the listed domain and that nothing has modified it since it was sent.
When sending large numbers of marketing messages per day, it’s inevitable that some small percentage will fail DMARC. Some of these messages fail because forwarders break their DKIM signatures and thus fail DMARC at their final destination.
Even though failure percentage may be low (0.1% or below), if you’re sending millions or tens of millions of messages per day, that amounts to thousands of failures. Wading through that noise is extremely challenging and time-consuming.
Does DKIM Filter Email?
No, it doesn’t. However, the information it provides does help filters that the receiving domain sets up. For instance, if the email is from a trusted domain and can successfully be verified through DKIM, the email may have its spam score reduced. If the email’s DKIM signature cannot be verified (because the email was faked or for another reason), the email might be marked as spam and either be quarantined or have a spam tag added to the subject line (to warn recipients that the email is suspicious).
As a domain owner, it’s important to understand that you don’t control what’s included in the DMARC failure report — that’s up to the receiver. And if the report is a false positive (an email that failed DMARC but shouldn’t have) that can mean ‘real’ information may be included in the failure report. That makes the failure report an easy way to leak confidential corporate or customer information.
