MicrosoftMicrosoftThis occurs because Microsoft uses very short DNS timeouts, if the DKIM controller doesn't receive the DNS reply quickly enought, then they will judge that DKIM fail.
Setting long TTL (at least 48h) on your DKIM records will help mitigate the problem.
I don't see how the TTL would affect that -- that just tells the DNS system how long to cache results. Nothing to do with how long it takes MS to fetch the records. . .
Please correct me if I'm wrong.
Microsoft definitely has a DNS bug related to SPF and DKIM evaluation, see posts here about it:
https://forum.dmarcian.com/t/dkim-verification-failures-microsoft-365-exchange-online/2679
https://www.linkedin.com/posts/activity-7250496295558090753-TKoR
https://www.linkedin.com/posts/activity-7257872173409648640-yD-Y?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAACWHZKwBD6Opt3weyOnlHqAOU3JlQ0FCucs
In normal cases (shown in the linkedin posts), a longer TTL would allow the DNS client to use cache more frequently (and longer) rather than querying upstream for the record, which significantly lowers DNS errors (temperrors) with email authentication. In Microsoft's case, TTLs longer than an hour for SPF/DKIM records has almost no effect on their DNS issue unfortunately (specific to the DNS bug).
Hi Mark!
I've consistently found that lengthening TTLs mitigates or even eliminates the DNS timeout problem entirely. But, of course, if the record is a CNAME that in turn points to a record with a short TTL, the solution isn't as drastic as it would be for a direct DKIM record.
Why do you think the DNS bug isn't mitigated by lengthening DKIM TTLs? Is this due to your observations or your knowledge of the exact nature of the bug?
Christophe
I agree with you, it does generally in both cases (TXT/CNAME), yes - but unfortunately not for Microsoft OLC/365's DNS problem. As to why, the exact answer is known only to the product team. It was explained to me as, "a known bug related to DKIM retry, with the way Windows DNS (which the Defender Antispam service utilizes) performs certain DNS requests in certain situations, leading to issues with the way DKIM is handled. This does apply to SPF as well, hence seeing the errors for both."
Because it takes less time for Microsoft to retrieve the record from its DNS cache than it does to wait for the response to a DNS query
Obviously - but if the cache is stale, be it after 12 or 48 hours, they're still going to have to query the actual DNS. You've postponed the problem, potentially, but not really now that we're 2 weeks into the issue.
DNS timeouts are a random issue that occurs x% of the time (x could be around 1); the less you try, the less likely you are to get unlucky. Once Microsoft has successfully retrieved the DNS value, it is best to keep it as long as possible before it is forced to try again.
