Worked example 5 of 11
Business email between two Microsoft 365 companies
What Exchange Online headers look like: many internal hops with IPv6 addresses, 'Microsoft SMTP Server' as the protocol, and Microsoft's own compauth verdict.
What to notice
Microsoft 365 headers are long and look intimidating, but most of the hops are inside Microsoft's network. Reading from the bottom:
with mapi: Jordan's Outlook handed the message to their mailbox server. Server names likeDM6PR11MB4610.namprd11.prod.outlook.comare Microsoft datacentre machines ("namprd" = North America).- Two more internal hops inside the sender's tenant, then out through
outbound.protection.outlook.com(Exchange Online Protection), which signs it (DKIMd=example.com, selectorselector1) and adds an ARC seal bymicrosoft.com. - The recipient's side receives it from
198.51.100.25, checks SPF, DKIM and DMARC, and writescompauth=pass reason=100. compauth ("composite authentication") is Microsoft's own verdict combining the checks; it's not an IETF standard.
The whole journey took 12 seconds, almost all of it before the message left the sender's tenant. Microsoft's Authentication-Results doesn't start with a server name, which RFC 8601 requires; MailDingo handles that by treating the field as your provider's anyway when it's the top one.
The analysis
Produced by the same code that runs in the analyser.
Looks genuine
Authenticated: it really came from example.com
Your provider's DMARC check passed, so example.com (or a service it authorised) sent this message. That proves the domain, not the intent: make sure example.com is the organisation you expect.
- Fromexample.com
- Sent from2001:db8:10b6:405:cafe::2
- Hops6
- In transit5 s
- ViaMicrosoft
Red flags 0
No red flags found in these headers.
Authentication
The top Authentication-Results field names no server (Microsoft 365 writes it this way), so MailDingo treats it as your provider's. show in headers
DMARC DMARC asks: did SPF or DKIM pass for a domain that matches the From address you see? That match is called alignment.
SPF or DKIM passed for a domain that aligns with the visible From domain: the From address is authentic.
applied: none
SPF SPF checks whether the server that delivered the message was allowed to send for the envelope (bounce) domain.
The sending server is on the envelope domain's list of permitted senders.
sender IP is 198.51.100.25
DKIM DKIM checks a cryptographic signature that a domain (d=) put on the message, proving that domain handled it and the signed parts were not changed.
The signature verified: the signing domain really handled this message and the signed content is unchanged.
signature was verified
Other checks
A vendor-specific or less common result (reason 100).
Alignment with the From address
- SPF example.com passaligned (exact match)
- DKIM example.com passaligned (exact match)
At least one passing check is aligned with the From domain, which is all DMARC needs. Alignment is shown in relaxed mode (same organisation); a domain can demand strict mode (exact match) in its DMARC record, which this tool can't look up.
DKIM signatures on the message
- example.com selector selector1 · rsa-sha256 · covers 7 header fields ↧
ARC chain 1
Each forwarding server that sealed the message recorded what it saw. These are claims by those servers; they only count if your provider trusts the sealer.
- i=1 sealed by
microsoft.comcv=nonesaw: spf=pass dmarc=pass dkim=pass arc=none↧
Who it claims to be from
Route 6 hops
Oldest first. Each server adds a Received line on top, so this is the header list read from the bottom up. Times are converted to UTC.
- Written Date header: 2026-10-20 09:31:40 UTC (sender's clock +0000)
- +7 sdm6pr11mb4610.namprd11.prod.outlook.com Microsoftfrom dm6pr11mb4610.namprd11.prod.outlook.com
2001:db8:4a1c:2b3d:5e6f:7a8b::12026-10-20 09:31:47 UTC (+0000 local) ↧ - +1 sdm6pr11mb3962.namprd11.prod.outlook.com Microsoftfrom dm6pr11mb4610.namprd11.prod.outlook.com
2001:db8:10b6:5:1d0::122026-10-20 09:31:48 UTC (+0000 local) ↧ - +2 sbn2pepf000044a8.mail.protection.outlook.com Microsoftfrom mail-eastus2azon11012025.outbound.protection.outlook.com
198.51.100.252026-10-20 09:31:50 UTC (+0000 local) ↧ - +1 sbn9pr03ca0123.outlook.office365.com Microsoftfrom bn2pepf000044a8.namprd04.prod.outlook.com
2001:db8:10b6:405:cafe::22026-10-20 09:31:51 UTC (+0000 local) ↧Probably where your provider took the message in from the outside world. The IP here was seen by the receiving server, so it is the most trustworthy origin address in the headers. - +0 ssa1pr12mb7272.namprd12.prod.outlook.com Microsoftfrom bn9pr03ca0123.namprd03.prod.outlook.com
2001:db8:10b6:408::72026-10-20 09:31:51 UTC (+0000 local) ↧ - +1 smn2pr12mb4549.namprd12.prod.outlook.com Microsoftfrom sa1pr12mb7272.namprd12.prod.outlook.com
2001:db8:10b6:806::222026-10-20 09:31:52 UTC (+0000 local) ↧
First to last server: 5 s. Reading delays
The headers 23 fields
sender route authentication ARC
All names, domains and addresses on this page are fictional: domains under example.com/.net/.org and the reserved .example and .test names (RFC 2606, RFC 6761), IPv4 addresses from the documentation ranges in RFC 5737 and IPv6 from 2001:db8::/32 (RFC 3849). Signatures are placeholders and won't verify.