SPF fail, DKIM pass, DMARC pass: A confusing Microsoft rejection

Here's a confusing rejection that an email sender asked me about the other day. It's a Microsoft OLC (Outlook Consumer, aka Hotmail or Outlook.com) rejection, authentication related, saying that the message in question doesn't pass authentication checks:

550 5.7.515 Access denied, sending 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

DKIM passes, and DMARC passes. DKIM and DMARC passing means that the DKIM d= (the domain set up with the DKIM signature) matches (aligns with) the visible from domain. If it was me sending email, it'd probably be d=spamresource.com, with a visible from address of something@spamresource.com.

That's a good start -- but, SPF is NOT passing, and that's enough for the whole delivery attempt to collapse here.

What gives? In this age of DMARC, wasn't it that SPF or DKIM passing would be good enough? That it didn't have to be both? Yes...and no. DMARC is passing here, based on the DKIM signature being present, working properly, and matching (aligning with) the from domain, as I note above. But, back in April, 2025, Microsoft warned that starting in May, they were going to require that bulk email senders pass SPF, DKIM and DMARC checks, all three are required. And in May, they began rejecting email messages that fail any of those checks, including this particular email message that failed SPF checks.

Where to go from here:

• If this is happening to a lot of email messages you're sending, the SPF record for the sending domain or subdomain is likely misconfigured. This is the first place I'd check, because if you get SPF wrong, you're going to have big problems.
• If this is happening to only a few messages, a tiny percentage of sends, you might want to see if future sends to the same person go through just fine, without any configuration changes. That could indicate that Microsoft's having intermittent trouble resolving your SPF record in DNS.
• If this is happening to only a few messages here and there, and you've tested and confirmed that your SPF record is absolutely perfect, then it also could be due to email forwarding. If you're sending to a recipient, and that recipient is forwarding their mail on to a Microsoft mailbox, that forwarding step will break SPF authentication. Not your problem, not your fix. The recipient really can't forward mail in this way nowadays. How can you tell? The recipient address will likely be at some other domain, not a Microsoft-hosted domain, like outlook.com or hotmail.com. That'll be your indicator that the issue is forwarding related.

Remember how TV news anchors used to open the late evening newscast with, "It's 10pm. Do you know where your children are?" This makes me think of something similar: "You're sending email campaigns. Do you know what's in your SPF record?" SPF is in theory an easily configured email authentication protocol for a domain, but in practice, it gets tricky. It's manual, it's got a 10 DNS lookup limit, it doesn't trickle down to subdomains automatically, and people can and do get confused. So if you haven't checked your SPF record lately (maybe using a tool like aboutmy.email or the Valimail Domain Checker), that's a good place to start.