Worked example 4 of 11
A mailing-list post rescued by ARC
Mailing lists add subject tags and footers, which breaks the author's DKIM signature. ARC lets the list pass on what it saw before it changed anything.
What to notice
Alex posted to the hikers list from example.org. The list server at lists.example.net added [hikers] to the subject and a footer to the body, then sent a copy to every member. Two things break on the way:
- DKIM fails. Alex's signature covered the original subject and body, so
dkim=fail header.i=@example.orgat the final receiver. - SPF passes, but for the list. The list re-sends with its own envelope sender,
hikers-bounces@lists.example.net, which isn't aligned withFrom: alex@example.org.
So DMARC fails for example.org, even though nothing malicious happened. Before changing anything, the list recorded what it saw (ARC-Authentication-Results: i=1; lists.example.net; dkim=pass … dmarc=pass) and sealed it (ARC-Seal: i=1 … cv=none). The final receiver verified the seal (arc=pass) and, trusting the list, delivered the message anyway: dis=NONE.
MailDingo shows the DMARC failure as a medium flag here, not a high one, because the ARC chain is intact and the message carries List-Id. Whether the receiver should trust the list's seal is its own decision.
The analysis
Produced by the same code that runs in the analyser.
Check carefully
Forwarded: DMARC failed, but a forwarder vouches for it
A mailing list or forwarding service changed the message, which broke the original authentication; its ARC seal records that the message passed before it was changed. Trust it as far as you trust that list or forwarder.
- Fromexample.org
- Sent from198.51.100.7
- Hops4
- In transit9 s
- ViaGoogle
Red flags 1
- MediumDMARC failed, but a forwarder vouches for it
Your provider recorded dmarc=fail for example.org, but also arc=pass: a forwarding server or mailing list sealed what it saw before it changed the message. This message came through a mailing list, the usual reason. Learn more show in headers
1 note
- Bounces go to the forwarder or list. Return-Path is at lists.example.net: a mailing list or forwarder re-sent the message with its own bounce address, which is normal. Learn more show in 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.
Neither SPF nor DKIM passed for a domain aligned with the From domain, and that domain publishes DMARC: the From address is not authenticated.
domain policy p=quarantine · 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 hikers-bounces@lists.example.net designates 198.51.100.7 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.
A signature was present but did not verify: the message was changed after signing, or the signature is forged.
ARC ARC records what earlier servers (forwarders, mailing lists) saw, sealed with their signatures, so the final receiver can trust results that forwarding broke.
The ARC chain is intact: every forwarding server's seal verified.
i=1 spf=pass spfdomain=example.org dkim=pass dkdomain=example.org dmarc=pass fromdomain=example.org
Alignment with the From address
- SPF lists.example.net passpassed, but for a different organisation: doesn't count for DMARC
- DKIM example.org failDKIM fail, so it can't count
No passing check is aligned with the From domain, so DMARC can't pass. 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.org selector mail2026 · rsa-sha256 · signed 2026-10-15 11:02:07 UTC · covers 5 header fields ↧
ARC chain 2
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.
Who it claims to be from
- From
- Alex Moreau
alex@example.org↧ - Return-Path
hikers-bounces@lists.example.netbounces go to another domain ↧- Subject
- [hikers] Saturday route: ridge loop, 14 km ↧
- Date
- Thu, 15 Oct 2026 12:02:07 +0100 = 2026-10-15 11:02:07 UTC ↧
- Message-ID
<a81f3c2e-77d0-4b8e-9c1a-5e2f6d7b8c90@example.org>↧- Mailing list
- Weekend hikers <hikers.lists.example.net>
- 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-15 11:02:07 UTC (sender's clock +0100)
- +5 s
- +3 s
- +6 smx.google.com Googlefrom lists.example.net
198.51.100.72026-10-15 11:02:21 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. - +0 s2001:db8:4a5:10::512026-10-15 11:02:21 UTC (−0700 local) ↧
First to last server: 9 s. Reading delays
The headers 26 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.