Worked example 3 of 11
An order receipt sent through SendGrid with a custom domain
A transactional email from a shop that set its sending service up properly: both SPF and DKIM align with the From domain.
What to notice
Compare this with the Amazon SES newsletter. Here the shop has configured SendGrid to use its own subdomain for bounces (em4821.shop.example.net), so the Return-Path, the SPF check and the From address all belong to the same organisation, example.net. SPF passes and aligns.
DKIM is doubled again: d=shop.example.net (aligned) and d=sendgrid.net (the service's own signature, not aligned). Either aligned pass would have been enough for DMARC.
The long bounce address bounces+28371-9f1c-sam=example.com@… is a VERP address: the recipient's address is encoded into it so the shop can tell which address bounced. That's normal, not suspicious.
Note the route: SendGrid's outbound server (o1.ptr2214.shop.example.net, a reverse-DNS name the shop set up to point at SendGrid's IP) handed the message to Google in under a second.
The analysis
Produced by the same code that runs in the analyser.
Looks genuine
Authenticated: it really came from shop.example.net
Your provider's DMARC check passed, so shop.example.net (or a service it authorised) sent this message. That proves the domain, not the intent: make sure example.net is the organisation you expect.
- Fromshop.example.net
- Sent from203.0.113.21
- Hops4
- In transit9 s
- ViaGoogle
Red flags 0
No red flags found in these headers.
Authentication
Checked by mx.google.com, the server that added the top Authentication-Results field: normally your own provider. 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.
domain policy p=reject · 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.
google.com: domain of bounces+28371-9f1c-sam=example.com@em4821.shop.example.net designates 203.0.113.21 as permitted sender
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.
The signature verified: the signing domain really handled this message and the signed content is unchanged.
Alignment with the From address
- SPF em4821.shop.example.net passaligned (same organisation, relaxed)
- DKIM shop.example.net passaligned (exact match)
- DKIM sendgrid.info 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 Shop
orders@shop.example.net↧ - Return-Path
bounces+28371-9f1c-sam=example.com@em4821.shop.example.net↧- Subject
- Your order #40127 is on its way ↧
- Date
- Tue, 20 Oct 2026 09:14:50 +0000 (UTC) = 2026-10-20 09:14:50 UTC ↧
- Message-ID
<9xYzAbCdEfGhIjKlMnOpQ@geopod-ismtpd-12>↧- Services seen
- Google (Gmail / Google Workspace) mailbox
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-20 09:14:50 UTC (sender's clock +0000)
- +0 s
- +1 sfilterdrecv-5c8d9b7f6-x2k4p2026-10-20 09:14:51 UTC (+0000 local) ↧
- +7 smx.google.com Googlefrom o1.ptr2214.shop.example.net
203.0.113.212026-10-20 09:14:58 UTC (−0700 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. - +1 s2001:db8:4a5:10::9a22026-10-20 09:14:59 UTC (−0700 local) ↧
First to last server: 9 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.