In recent weeks, we have received an increasing number of calls from our customers with the problem that external persons can no longer deliver emails to them. In other words, our anti-spam gateway suddenly classifies incoming emails from certain domains as malicious and rejects them.
Investigations have shown that the problem is the same in almost all cases: Incorrectly configured or missing DKIM keys on the mail server / DNS of the sending partner.
What is DKIM actually?
DKIM stands for Domain Keys Identified Mail and, like SPF, checks the email domain of the „Mail from:“ address. However, the IP address of the sending server is not compared; instead, the message and the mail header are digitally signed. To do this, the sending system uses the private part of an asymmetric key pair. The public counterpart is made accessible via a DNS entry in the email domain. This allows each recipient to verify the signature and thus the origin of the messages.
Several such keys can be generated and saved for a mail domain. They are distinguished from each other by a name identifier, the „selector“. An entry is required on the DNS server for each selector, which looks like this, for example:
The selector here is now ’nx‘.
How is such a key created?
Most mail servers can create such keys. They create the „private key“, which they keep for themselves, and the „public key“, which must be installed on the DNS server, as in the example above.
So what is the problem?
Many customers, interestingly often Office 365 customers, seem to simply select the „Enable DKIM“ option – because it’s a good thing in itself. But then they forget to set up the „Public Key“ on the DNS server itself. The Office365 cloud servers cannot do this automatically because the customer’s domain (DNS) is very often operated elsewhere.
Until a few weeks ago, many anti-spam gateways apparently tolerated this lapse and forwarded emails anyway. Now, however, our anti-spam gateway, for example, rejects these emails with „ERROR – DKIM Invalid Key“.
How can this be checked?
If the ’selector‘ name is known (see extended email header), you can check, for example, on https://mxtoolbox.com/dkim.aspx whether the DKIM is set up correctly.
In the example above with ’nx‘ as the selector and our domain, this looks like this and everything is correct:
An example of a non-existent key, e.g. with ‚gibtesnicht‘ as selector, looks as follows:
This example illustrates what we have seen in recent support cases.
Who is responsible for solving the problem?
First and foremost, the mail server administrators of the sending user are responsible for ensuring that their mail server and DNS server are configured correctly. They must store the correct ‚public keys‘ on the corresponding domains in the DNS and check that they are working correctly. The problem therefore does not lie with us, the receiving mail server or the user.
Quick solution from nextron
Nevertheless, we have now made a (temporary) configuration adjustment to our gateway in which we do not classify DKIM key errors as HARD ERROR (the email is rejected), but as SOFT FAIL (the email is supplemented with [SPAM] in the subject line and delivered anyway).
Addendum
Further research has revealed the following: Microsoft does not normally expect the classic DKIM entries for public keys that you create in your own DNS, but wants so-called CNAME entries (aliases) that point to Microsoft DNS servers.
However, these do not seem to work at all at the moment: Even in our own test with a customer domain, we did everything according to the instructions and even days later the necessary entries are not visible or retrievable on the Microsoft DNS server. It seems that something fundamental is not working on Microsoft’s side.
However, we have not found any statements or blogs from Microsoft itself that would point to the problem and a possible solution. So we can only wait and see.