MicrosoftMicrosoftMicrosoft 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."
