For what it's worth, this is a known issue Microsoft confirmed with me directly through a support matter.
Explained as a known bug related to DKIM retry, with the way Windows DNS (which the Antispam service utilizes) performs certain 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. No ETA to resolution, but there are efforts to fix (or at least improve) this behaviour. This does not diminish the TTL advice, but it needs to be considered in data review. *-Ash Morin* On Mon, Nov 4, 2024 at 8:50 PM Douglas Foster < [email protected]> wrote: > If I understand Mark correctly, his data indicates that DNS works great > unless you are: > > - dependent on Microsoft as a DNS client to submit the query or > - dependent on Microsoft as a DNS server to respond to the query. > > > Sadly, that is a lot of dependent traffic. > > > On Mon, Nov 4, 2024 at 7:18 PM Mark Alley <mark.alley= > [email protected]> wrote: > >> Just sharing on the topic of authentication, DNS, and temperrors - I have >> recent statistics timeline (attached) involving DKIM failure rates for a >> high volume of mail for $dayjob that directly correlates the effect of TTLs >> and caching on temperrors and authentication (with Microsoft being an >> anomaly in this dataset). This volume in total roughly accounts for 738k >> DKIM failures out of 695.5m emails over 30 days, which is about a 0.1% DKIM >> failure rate overall. >> >> Splitting the failures up by reporter, Microsoft currently is the >> overwhelming offender when it comes to temperrors, by magnitudes of several >> thousands of percentage points, compared to all other receivers combined. >> Even increasing TTLs inordinately high had barely any effect on Microsoft's >> DNS errors. All other reporters fell off a cliff once the DKIM TTLs were at >> 24 hours. >> >> This also seems to apply to SPF as well. >> >> - Mark Alley >> On 11/4/2024 5:31 PM, Douglas Foster wrote: >> >> Surprisingly, for email, DNS errors are not rare. I have been >> collecting data from three sources: >> >> - The incoming messages to my server >> - The Aggregate Report data about messages that came from me or appear to >> come from me, and >> - The Authentication Results header fields on incoming messages, which is >> evaluated by unrelated servers about other unrelated domains. >> >> In each case, my TempError rate is 1 in 350 messages or higher. I >> expected something on the order of 1 in a million or 1 in a billion. >> >> I don't understand why the error rates are so high. I may undertake a >> study to determine what percentage of TempErrors are transient events and >> what percentage are highly repeatable events, but I have not done so yet.. >> Perhaps Google or someone else can contribute some insight. >> >> Doug Foster >> >> >> >> >> On Sun, Nov 3, 2024 at 1:29 PM Alessandro Vesely <[email protected]> wrote: >> >>> On Sun 03/Nov/2024 13:56:42 +0100 Douglas Foster wrote: >>> > The other problem is that the Tree Walk makes the entire document >>> > experimental. Tree Walk is a great tool for batch-mode detection >>> of >>> > PSL errors, but it has multiple problems as a real-time tool. >>> > >>> > - It disables best-guess DMARC based on default policy. Instead >>> of >>> > disabling best-guess DMARC, this document should be embracing it. >>> >>> >>> Best-guess DMARC can be a local filtering method, but it's not being >>> standardized. Using the Tree Walk doesn't preclude to use the PSL for >>> any >>> local intent. >>> >>> >>> > - It is prone to inconsistent results and indeterminate results >>> caused >>> > by DNS errors. >>> >>> >>> On a well supplied server, DNS errors are quite rare. An error >>> retrieving >>> DMARC records, which can happen also when the org domain is discovered >>> by PSL, >>> deserves a 4xx temporary error. >>> >>> >>> > - Multiple DNS lookups are reasonably expected to have lower >>> performance >>> > than one database lookup, especially since high-throughput >>> environments can >>> > use memory-resident databases for the PSL lookup. >>> >>> >>> All the involved domains can be queried in one shot. That way the time >>> required is about the same as querying a single record. >>> >>> >>> > - Inconsistent results can be mitigated by using long-term caching >>> > outside of DNS, but that adds complexity and overhead. >>> >>> >>> Agreed. It is much better to deploy a dedicated DNS server. >>> >>> >>> > [...] >>> > >>> > In aggregate, I see no justification for DMARCbis to be given >>> Standards >>> > Track status, unless the Tree Walk is separated out as an experimental >>> > option, either in an appendix or in a separate document. >>> >>> >>> Using the PSL was the experiment. Standardization provides a >>> better-defined >>> method by which a domain owner can decide which domains are >>> "organizational" >>> without having to seek help from a vaguely defined group that maintains >>> a list >>> designed for a different purpose. >>> >>> I don't think experimental status is required for that. Anyway, that is >>> to be >>> decided by the IESG or the RFC-Editor, methinks. Our charter says: >>> >>> The task of defining a standard mechanism for identifying >>> organizational >>> domain is out of scope for this working group. However the working >>> group >>> can consider extending the base DMARC specification to accommodate >>> such a >>> standard, should it be developed during the life of this working >>> group. >>> >>> >>> Best >>> Ale >>> -- >>> >>> >>> >>> _______________________________________________ >>> dmarc mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> >> _______________________________________________ >> dmarc mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> dmarc mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
