Outlook.Com will always add a signature for a recognized client.   If the customer has configured DNS correctly, it will add a signature for the client domain.  Otherwise, it will a proxy signature for <token>.onmicrosoft.com.   The value of <token> cannot be reliably mapped to the client domain, so it is not particularly useful.

Unfortunately, Outlook.com does not reliably authenticate a client, but it uses a combination of Received headers and ARC sets to convey some information.

If the message originates from an authenticated client, it will add an anonymized Received header with a loopback MAPI connection over a private IPv6 address, like this:

Received:

 from SA1PR11MB7088.namprd11.prod.outlook.com ([fe80::80d5:c51f:3b79:524a])

 by   SA1PR11MB7088.namprd11.prod.outlook.com ([fe80::80d5:c51f:3b79:524a%7])

 with mapi id 15.20.8466.016;

 Sat, 1 Mar 2025 13:00:49 +0000 

If the message leaves the Outlook.com environment for an outbound gateway service, it will add an ARC set of this form:

arc-authentication-results

 i=1; mx.microsoft.com 1;

 spf=pass smtp.mailfrom=<domain>;

 dmarc=pass action=none header.from=<domain>;

 dkim=pass header.d=<domain>;

 arc=none

Note that these values have no connection to reality - it will assert a DKIM Pass even though the message has no signature, and a DMARC Pass even if the domain has no DMARC policy.   The ARC Set is a clumsy way of implying that the client was authenticated.

If the message originates outside of Outlook.com, Outlook.com will add a normal Received header for the incoming connection.   It will also compute SPF, DKIM, and DMARC, then immediately log those values in Received-SPF and X-MS-Exchange-Authentication-Results headers.   Before the message leaves the Outlook.com environment, it will add an ARC Set containing the same information.   Client organizations reliably configure their SPF policy to authenticate messages leaving Outlook.com, but they do not reliably configure SPF to authenticate messages submitted to them, so the messages appear to be potential impersonations.   However, Outlook.com takes no action on authentication failures, so the client has no incentive to change its SPF policy.  This creates a real problem for recipients.  What do we do when the initial ARC Set indicates that the message failed authentication?

The message will arrive at the recipient with dual authentication:  it will have SPF Pass based on the Outlook.com server, and DKIM Pass based on a signature that Outlook.com added to the message.  If the message was submitted by an impersonator, the normal SPF/DKIM/DMARC tests will provide a false Pass.   Detecting that credential upgrade occurred requires an in-depth parse of the message  Even then, many legitimate senders will be mixed in with the few spammers, so each message source must be assessed individually.  Once a particular origination source has been classified, a whole new category of whitelist and blacklist rules are needed to document the results.