Worked example 11 of 11
Mail forwarded by an alumni address (SRS keeps SPF working)
A forwarding address that does it right: it rewrites the bounce address (SRS) so SPF still passes, and doesn't touch the message, so DKIM survives.
What to notice
Taylor writes to chris@alumni.example.edu, an old university address that simply forwards everything to Chris's current mailbox at example.net. Plain forwarding breaks SPF, because the alumni server isn't on Taylor's domain's list of permitted senders. This forwarder avoids that with the Sender Rewriting Scheme (SRS):
Return-Path: <SRS0=Hk3q=RW=example.com=taylor@alumni.example.edu>
The forwarder replaced the envelope sender with an address at its own domain that encodes the original one (taylor@example.com) plus a hash and timestamp, so bounces can be routed back. SPF now checks alumni.example.edu, which passes but doesn't align with From: taylor@example.com.
DMARC still passes, because the forwarder didn't change the message: Taylor's DKIM signature (d=example.com) verifies at the final receiver and aligns. This is why domains that send through forwarders and lists should always sign with DKIM: SPF rarely survives forwarding, DKIM usually does.
The route shows the forwarder's hop (mx.alumni.example.edu) between Taylor's provider and Chris's.
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 from203.0.113.60
- Hops3
- In transit5 s
Red flags 0
No red flags found in these headers.
1 note
- Bounces go to a different domain. Return-Path is at alumni.example.edu. That's normal when a mail service sends on someone's behalf, and DKIM still ties the message to example.com. Learn more show in headers
Authentication
Checked by mx2.example.net, 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=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.
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.
2048-bit key
Alignment with the From address
- SPF alumni.example.edu passpassed, but for a different organisation: doesn't count for DMARC
- 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 sel1 · rsa-sha256 · signed 2026-10-24 20:30:09 UTC · covers 7 header fields ↧
Who it claims to be from
Route 3 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-24 20:30:05 UTC (sender's clock +0200)
- +4 smail.example.comfrom host-198-51-100-61.isp.test
198.51.100.612026-10-24 20:30:09 UTC (+0200 local) ↧ - +3 s
- +2 smx2.example.netfrom mx.alumni.example.edu
203.0.113.602026-10-24 20:30:14 UTC (−0400 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.
First to last server: 5 s. Reading delays
The headers 15 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.