DKIM verification failures - Microsoft 365 / Exchange Online

Hi everyone,

There has been an issue happening for some time regarding Microsoft Exchange Online / 365 where DKIM verification reported as part of DMARC shows “temperror” or “fail” as a verdict. You may notice in your DMARC report that this issue only occurs with Microsoft, and that after verification you find nothing wrong with the DKIM public key record and your DNS.

Review of email headers for those emails failing DKIM will reveal the following details in the Authentication-Results header:

  • dkim=fail (dns timeout) for temperror verdicts
  • dkim=fail (no key for signature) for the fail verdicts

In this circumstance, this is highly likely due to a bug being investigated by Microsoft regarding the way it handles its DNS check to obtain the DKIM public key record. Microsoft is aware and are working on a fix with a deployment ETA of end of February.

In my review of failures across dmarcian customers and their data, the failure rate due to this bug is about 0.25 to 0.5%. Email sources that are DMARC compliant strictly through DKIM only will be impacted by the “dkim=fail (no key for signature)” verdict. Meanwhile, the issue causing the temperror verdict, dkim=fail (dns timeout), will see the severity of policy applied reduced by 1 level: reject → quarantine and quarantine → no action. This is a behaviour I was able to confirm through testing with Exchange Online.

The only mitigating steps is to have both DKIM and SPF alignment configured wherever possible. If this issue occurs, then SPF alignment will still allow a passing DMARC verdict, and prevent impact to legitimate mail flow due to the bug. However, some sources are not capable of SPF alignment, such as MailChimp. For information on whether or not a source is capable of SPF alignment, refer to our source database here: DMARC.io

If you are a dmarcian customer and you have further question or require support regarding this issue, contact us at support@dmarcian.com. Otherwise, feel free to discuss your findings here.

Thank you!

4 Likes

Has anyone been able to find anything in service health in the M365 portal? I was hoping to track when this is fixed in there.

Hi CIGRK and welcome to the forums.

This bug is not currently documented publicly by Microsoft, so there is nothing to find unfortunately. I met with them on Feb 28th and the issue is ongoing. The rollout has not yet completed, and no ETA was given.

I will share what I learn as soon as they provide me another update. Meanwhile, I can confirm the issue is still ongoing through data analysis across our customer base.

Let’s hope we hear back soon.

1 Like

A review of data shows the issue is still ongoing as of March 27th. The frequency of “temperror” results are on the way down, but failures due to to “dkim=fail (no key for signature)” remain. I will provide an update once more information becomes available.

2 Likes

@Asher, would you be willing to request Microsoft convert this to a bug that is tracked and acknowledge publicly by their team. I think it would be to their benefit to limit additional unnecessary support requests and needless troubleshooting.

1 Like

It was brought up already, but they have not acknowledged whether or not they intend to do that.

I have attempted to open a ticket with Microsoft to push them to get this issue fixed or at least acknowledge it. So far, they’ve been saying it’s an issue with my spam filter.