Why are some messages to Microsoft 365 bouncing with SPF or DKIM errors?

Start with the exact bounce code and diagnostic text, then compare a failed message with a successful one. Look at the connecting IP, Return-Path domain, DKIM signing domain, and selector. An occasional failure can point to a different sending server or a selector that doesn't resolve correctly.

Also check alignment with the visible From domain. DMARC can pass through either aligned SPF or aligned DKIM, so a valid record alone doesn't tell you whether the message will pass DMARC.

I wouldn't focus on TTL first. A longer TTL mainly changes how long DNS answers can be cached, and it won't fix an unauthorized sending IP or a bad signature. Query the actual SPF and DKIM records used by the failed message, not just the records you expect it to use.

Are you collecting DMARC aggregate reports? They can help identify which IPs are sending mail for the domain and whether SPF or DKIM is passing and aligned. Compare those sources with your approved senders, including any services that send on the domain's behalf.

The reports are aggregated, so use them alongside the individual bounce and message details rather than expecting them to explain every failed delivery.

Don't rule out reputation just because public blocklists look clean. Microsoft has its own reputation signals, and its sending data service may offer another clue. Still, check the actual rejection text first so you don't chase reputation when the server is explicitly reporting an authentication failure.