Worked example 8 of 11
A message delayed by greylisting and a stuck queue
Four servers in three time zones and two very different delays. Converting every timestamp to UTC shows exactly where the time went.
What to notice
The sender says they emailed at 08:58 in the morning; the recipient got it before 1 pm Central European time. Every Received line uses its own server's local time, so the times only make sense after converting them to UTC:
| Hop | Local time on the line | UTC | Wait |
|---|---|---|---|
| Written (Date header) | 08:58:02 −0700 (PDT) | 15:58:02 | |
| 1, sender's server | 08:58:04 −0700 | 15:58:04 | 2 s |
| 2, sender's outbound relay | 19:09:44 +0000 | 19:09:44 | 3 h 11 min |
| 3, university gateway | 21:46:58 +0200 (CEST) | 19:46:58 | 37 min |
| 4, mailbox server | 15:47:01 −0400 (EDT) | 19:47:01 | 3 s |
The 3 h 11 min gap is inside the sender's own network: the message sat in the queue on mail.example.org until the outbound relay accepted it. The 37 minutes at the university gateway is typical greylisting: the gateway refused the first attempt from an unfamiliar server with a temporary error, and the relay retried later, as SMTP requires (RFC 5321 §4.5.4.1).
The mailbox server's line uses a named zone (EDT) and a two-digit year (26), both obsolete forms that RFC 5322 §4.3 tells readers to accept; MailDingo reads them correctly.
The analysis
Produced by the same code that runs in the analyser.
Looks genuine
Authenticated: it really came from example.org
Your provider's DMARC check passed, so 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.
- Fromexample.org
- Sent from192.0.2.25
- Hops4
- In transit3 h 48 min
Red flags 1
- LowSlow hop: 3 h 11 min
Between hop 1 and hop 2 the message waited 3 h 11 min (at relay.example.org). See the route below. Learn more show in headers
1 note
- Slow hop: 37 min 14 s. Between hop 2 and hop 3 the message waited 37 min 14 s (at gw1.uni.example). See the route below. Learn more show in headers
Authentication
Checked by gw1.uni.example, 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.
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; unprotected
Alignment with the From address
- SPF example.org passaligned (exact match)
- DKIM example.org 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.org selector s2026 · rsa-sha256 · signed 2026-10-16 15:58:04 UTC · covers 5 header fields ↧
Who it claims to be from
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-16 15:58:02 UTC (sender's clock −0700)
- +2 s
- +3 h 11 min
- +37 min 14 sgw1.uni.examplefrom relay.example.org
192.0.2.252026-10-16 19:46:58 UTC (+0200 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. - +3 s
First to last server: 3 h 48 min; the slowest step was hop 2 (3 h 11 min). 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.