This post talks about what Mailkit/Omnivery is seeing with DNS resolution 
problems: 
https://www.linkedin.com/posts/josephineaskinner_in-light-of-the-authentication-related-microsoft-activity-7353364850527412224-BI3s

The relevant bits here: 

> On the SPF side, we are seeing around 1-3% of messages fail SPF when SPF 
> macros are used, and <0.1% if no macros are involved for records with TTL 
> 86400. SPF macros are more difficult to cache, and as a result MS fails to 
> resolve them more often, further supporting the argument this is a DNS issue 
> on their end. 
> 
> Our system is set up in a way that no unauthenticated message can be sent out 
> (barring a major technical failure). When we see these bounces, we know that 
> the SPF, DKIM, and DMARC must have passed rather than failed. Knowing this, 
> we decided to treat these bounces as tempfails and retry delivery 5 minutes 
> later. As expected, these messages get delivered just fine once MS resolves 
> the DNS records correctly, and our bounce rates for Outlook have dropped to 
> almost 0%. 

This isn’t some new standard for Microsoft requiring alignment. Neither 
Constant Contact nor Mailchimp align with SPF and if Microsoft was expecting 
alignment then they would be rejecting over a billion legitimate emails a day. 
This is just Microsoft being broken. 

laura


> On 13 Aug 2025, at 09:34, Dan Malm via mailop <[email protected]> wrote:
> 
> On 8/13/25 10:24, Laura Atkins wrote:
>> MS says both SPF fail and DKIM fail in different cases - I’ve seen both 
>> happen. I missed the part where SPF was actually failing (as opposed to just 
>> MS being unable to do basic inbound mail authentication).
>> If it really is SFP failing then you may want to try SRS? I dunno how well 
>> that will work but it might help. Microsoft makes some rather challenging 
>> and hard to understand decisions about how they filter mail but experience 
>> suggests they are resistant to changing those decisions.
> 
> The error from MS indicates that it's SPF for the domain in the From header 
> that is failing (and that is true). SRS is specified as a solution to 
> "fixing" SPF for the envelope address, and we do in fact do SRS rewriting of 
> the envelope. I don't think we want to go down the path of having to SRS 
> rewrite From headers.
> 
> -- 
> BR/Mvh. Dan Malm, Systems Engineer, one.com
> _______________________________________________
> mailop mailing list
> [email protected]
> https://list.mailop.org/listinfo/mailop

-- 
The Delivery Expert

Laura Atkins
Word to the Wise
[email protected]

Delivery hints and commentary: http://www.wordtothewise.com/blog        






_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop

Reply via email to