MicrosoftMicrosoftHi Aleeri!
These random SPF fails to Microsoft Office 365 recipients may be caused by DNS lookup timeouts.
Long TTLs on SPF records (at least 24h or even 48h, if possible on your DNS provider) can help to reduce this problem.
We are in control of our own DNS server so I can change this. However I also suspect that customers may forward emails from another ESP like one.com to Office 365 hence rewriting the original dedicated source IP breaking SPF. Most but not all emails rejected in the sendgrid logs are sent to mx for one.com but then Blocked by outlook.com.
Example in Sendgrid logs:
Email to recipient - processed 9.45 am
Received by mx3.pub.mailpod8-cph3.one.com
Delivered 9.45 am
Blocked 12.45 pm
550 5.7.515 Access denied, sending domain OUR DOMAIN doesn't meet the required authentication level. The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender. To learn how to fix this see: https://go.microsoft.com/fwlink/p/?linkid=2319303 Spf= Fail , Dkim= Pass , DMARC= Pass [AM8P193MB1204.EURP193.PROD.OUTLOOK.COM 2025-09-11T10:45:48.127Z 08DDEEE6DC97CEB1] [MN2PR07CA0005.namprd07.prod.outlook.com 2025-09-11T10:45:48.180Z 08DDF08D6DECFFF6] [BL6PEPF00020E64.namprd04.prod.outlook.com 2025-09-11T10:45:48.185Z 08DDF0A9681C7467] (in reply to EOD command)
One.com does indeed provide email addresses on its customers' existing domains. It's likely that a good number of them have configured forwarding to Outlook addresses. If the forwarding performed by One.com doesn't use SRS but instead retains the original envelope domain, then SPF fails from Outlook's perspective. This is a known side effect of the systematic requirement for SPF success: forwarders not using SRS will be blocked. Forwarding without SRS is incompatible with Microsoft's new requirements and, to a lesser extent, with other email services as well.
