Common email receiving problems due to misconfigured DKIM on the sending mail servers
In the last few weeks we have received an increasing number of calls from our customers with the problem that external people can no longer send them emails. In other words, our anti-spam gateway suddenly classifies incoming emails from certain domains as malicious and rejects them.
Research has shown that in almost all cases the problem is the same: misconfigured or missing DKIM keys on the mail server / DNS of the shipping 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, but 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. In this way, each remote station can verify the signature and thus the origin of the messages.
Several such keys can be generated and stored for a mail domain. They are distinguished from one another by a name identifier, the "selector". An entry on the DNS server is required 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" that they keep to themselves and the "public key" that needs to be installed on the DNS server, as in the example above.
So what's the problem?
Many customers, interestingly often Office 365 customers, seem to simply choose the "Enable DKIM" option - because that'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 customers' domain (DNS) is very often operated elsewhere.
Up until a few weeks ago, many anti-spam gateways apparently tolerated this lapse and forwarded emails anyway. But now, for example, our anti-spam gateway rejects these e-mails with "ERROR - DKIM Invalid Key".
How can this be checked?
If the 'Selector' name is known (see extended e-mail header), you can check e.g. https://mxtoolbox.com/dkim.aspx whether the DKIM is set up correctly.
In the above example with 'nx' as the selector and our domain, it looks like this, so everything is correct:
An example of a key that does not exist, e.g. with 'doesn't exist' as a selector, looks like this:
This example illustrates what we've seen in recent support cases.
Who is responsible for solving the problem?
The sending user's mail server administrators are primarily responsible for ensuring that their mail server and DNS server are configured correctly. They have to store the correct 'public keys' on the corresponding domains in the DNS and check whether they work correctly. So the problem is not with us, or with the receiving mail server or the user.
Fast solution from nextron
Nevertheless, we have now made a (temporary) configuration adjustment to our gateway, where we do not report DKIM key errors as HARD ERROR (the email is rejected), but as a SOFT FAIL (the email is supplemented with [SPAM] in the subject and still delivered) classify.
Addendum
Further investigation revealed the following: Microsoft normally does not expect the classic DKIM entries for public keys that you create in your own DNS, but rather so-called CNAME entries (aliases) that point to Microsoft DNS servers.
But these don't seem to be working at all at the moment: Even in our own test with a customer domain, we carried out everything according to the instructions and even days later the necessary entries on the Microsoft DNS server are not visible or retrievable. It seems that something fundamental is not working on the Microsoft side.
However, we have not found any statements or blogs from Microsoft itself that would indicate the problem and a possible solution. So we can only wait and see.
