Worked example 2 of 11
A newsletter sent through Amazon SES (received by Microsoft 365)
Bulk mail sent by a mail service on a company's behalf. SPF passes for the service's own domain, and DKIM is what ties it to the company.
What to notice
Newsletters and notifications are usually sent by a service such as Amazon SES, not by the company's own server. That shows up in two places:
- Return-Path is at
amazonses.com. Bounces go to Amazon so it can track undeliverable addresses. SPF therefore checks Amazon's domain and passes, butamazonses.comis not the From domain, so that pass doesn't align. - There are two DKIM signatures. One by
d=amazonses.com(the service signs everything it sends) and one byd=updates.example.org. The second is in the same organisation asFrom: news@updates.example.org, so it aligns, and DMARC passes on DKIM alone.
Microsoft writes its results without a server name at the start of Authentication-Results, and adds compauth=pass reason=100, its own "composite authentication" verdict. The List-Unsubscribe and List-Unsubscribe-Post headers enable the one-click unsubscribe button in mail apps (RFC 8058).
MailDingo reports the different Return-Path as a note rather than a red flag here because the aligned DKIM signature makes up for it.
The analysis
Produced by the same code that runs in the analyser.
Looks genuine
Authenticated: it really came from updates.example.org
Your provider's DMARC check passed, so updates.example.org (or a service it authorised) sent this message. That proves the domain, not the intent: make sure example.org is the organisation you expect.
- Fromupdates.example.org
- Sent from2001:db8:10b6:a03:cafe::8b
- Hops4
- In transit2 s
- ViaMicrosoft, Amazon SES
Red flags 0
No red flags found in these headers.
1 note
- Bounces go to a different domain. Return-Path is at eu-west-1.amazonses.com. That's normal when a mail service sends on someone's behalf, and DKIM still ties the message to updates.example.org. Learn more show in 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.48
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
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 eu-west-1.amazonses.com passpassed, but for a different organisation: doesn't count for DMARC
- DKIM updates.example.org passaligned (exact match)
- DKIM amazonses.com passpassed, but for a different organisation: doesn't count for DMARC
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
Who it claims to be from
- From
- Example Gardens
news@updates.example.org↧ - Return-Path
0102019a1b2c3d4e-5f6a7b8c-9d0e-4f1a-b2c3-d4e5f6a7b8c9-000000@eu-west-1.amazonses.combounces go to another domain ↧- Subject
- October planting guide 🌱 bulbs, garlic and more (decoded from utf-8) ↧
- Date
- Thu, 8 Oct 2026 16:00:12 +0000 = 2026-10-08 16:00:12 UTC ↧
- Message-ID
<0102019a1b2c3d4e-5f6a7b8c-9d0e-4f1a-b2c3-d4e5f6a7b8c9-000000@eu-west-1.amazonses.com>↧- Services seen
- Microsoft (Outlook.com / Exchange Online) mailbox Amazon SES sending service
Route 4 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-08 16:00:12 UTC (sender's clock +0000)
- +7 sco1pepf000075f3.mail.protection.outlook.com Microsoftfrom a2-48.smtp-out.eu-west-1.amazonses.com
198.51.100.482026-10-08 16:00:19 UTC (+0000 local) ↧ - +1 sby3pr05ca0021.outlook.office365.com Microsoftfrom co1pepf000075f3.namprd03.prod.outlook.com
2001:db8:10b6:a03:cafe::8b2026-10-08 16:00:20 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 smw4pr12mb7012.namprd12.prod.outlook.com Microsoftfrom by3pr05ca0021.namprd05.prod.outlook.com
2001:db8:10b6:a03::262026-10-08 16:00:20 UTC (+0000 local) ↧ - +1 ssj0pr12mb6830.namprd12.prod.outlook.com Microsoftfrom mw4pr12mb7012.namprd12.prod.outlook.com
2001:db8:10b6:303::142026-10-08 16:00:21 UTC (+0000 local) ↧
First to last server: 2 s. Reading delays
The headers 19 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.