Outlook has three ways of saying it is not sure who sent a message, and they often appear together on the same email: a banner that reads "We can't verify that this email came from the sender so it might not be safe to respond to it", a question mark in place of the sender's photo, and the word "via" followed by another domain next to the sender's name. All three come from Microsoft's authentication checks, and all three are fixed by the sender, not the reader.
The question mark and the banner
Microsoft documents the question mark, under unauthenticated sender indicators, as shown when a message passes neither SPF nor DKIM and fails both DMARC and Microsoft's own composite authentication. Composite authentication is Microsoft's verdict that weighs SPF, DKIM and DMARC together. The banner is the same verdict in words.
From the sending side this is the same failure Gmail reports as "Be careful with this message": the message carries nothing that ties it to the From domain. A service sends as your domain without being in SPF, or without signing DKIM under your domain. The checks on the Gmail warning page apply unchanged.
Adding the sender to Safe Senders does not remove the banner. In a Microsoft 365 organisation an administrator can allow the sender through the tenant's spoof settings, which also lets forgeries from that same source through.
The "via" tag
"Via" appears when the domain in the From address differs from the domain in the DKIM signature or in the envelope sender. A newsletter that shows you@example.com via sendgrid.net was signed by the provider's domain, with its bounce address there too.
It is not a failure on its own: the message may pass everything. It is still the visible half of the same setup gap, and it goes away the same way. Set up DKIM for your domain in the sending service, and where it offers one, a custom return path on your domain, so that both identities match the From line.
Mail from your own colleagues
When the warning shows on internal mail, the message usually went out through something other than the organisation's mailbox: a scanner, a ticketing system or a marketing tool sending as a colleague's address. That system needs the same treatment as any outside service, an SPF entry or, better, DKIM under the domain.
Checking the fix
Send a test message through the service in question and read the authentication results the way the DMARC fail page describes. When the DKIM d= and the return path both match the From, the DMARC result passes on either of them, and neither the question mark nor "via" has anything to point at. The records themselves can be looked up with the SPF, DKIM and DMARC checkers.