KitWharfFREEFast & Private Web Apps
Hop-by-Hop MTA Delays • SPF/DKIM/DMARC Audit • 100% In-Browser Privacy

Email & Message Header Analyzer

Paste raw RFC 5322 email headers to trace routing hops, pinpoint delivery delay bottlenecks, verify SPF, DKIM & DMARC authentication, and spot phishing indicators with zero data leaks.

Paste Raw Email Headers(21 headers detected)
Originating IP
192.30.252.204PUBLIC
Transit Delay
4sacross 2 relays
SPF Auth
passgoogle.com: domain of support@github.com designates 192.30.252.204 as permitted sender
DKIM Signature
passCrypto signature
DMARC Policy
passDomain alignment
Spoof Risk
Low RiskValidated sender
Chronological Hop Path (Sender → Relays → Mailbox Destination)Sorted earliest to latest
1
Hop #1Protocol: ESMTPS
+0s
Received Frommail4.github.com (mail4.github.com. [192.30.252.204])
[192.30.252.204]public
Received Bymx.google.com
for: recipient@company.com
Tue, 20 Oct 2026 14:15:28 -0700 (PDT)Queue ID: o14-20020a17090b39ce00b00290bbff817csi1829474pjg.12.2026.10.20.14.15.28
2
Hop #2Protocol: SMTP
+4s
Received FromUnknown Host
Received By2002:a05:6512:3503:b0:53f:10ad:986a
Tue, 20 Oct 2026 14:15:32 -0700 (PDT)Queue ID: w3csp1928430lfg

How Email Routing Hops and Latency Delays Work

When an email is sent, it rarely travels straight from the sender’s laptop to the recipient’s inbox. Instead, it passes through a sequence of intermediate Mail Transfer Agents (MTAs), such as internal submission gateways, corporate relay clusters, spam firewalls, and MX host servers.

Every MTA that handles a message prepends a new Received: header to the very top of the email. By parsing these headers from bottom to top, the KitWharf Email Header Analyzer reconstructs the complete chronological path taken by the email, calculating the delay (latency) incurred at each hop.

Normal Transit Times

Direct cloud hops (e.g. Gmail to Google MX, or Outlook to Microsoft Exchange) typically take 0 to 3 seconds.

Delay Bottlenecks

Delays over 30 seconds usually point to greylisting mechanisms, deep anti-malware attachment sandbox inspection, or MTA queuing spikes.

The Email Security Trifecta: SPF, DKIM, and DMARC

Modern email providers (Google, Yahoo, Microsoft) require strict sender authentication to prevent business email compromise (BEC) and domain spoofing:

  • SPF (Sender Policy Framework): A DNS TXT record specifying authorized sending IP addresses for a domain. If an unlisted IP sends mail purporting to be from that domain, SPF fails.
  • DKIM (DomainKeys Identified Mail): The sending MTA signs the email headers and body with an asymmetric private key. The recipient validates the signature against the sender's public key published in DNS.
  • DMARC (Domain-based Message Authentication): Enforces that either SPF or DKIM aligns with the visible From: address, giving domain owners policy control (none, quarantine, or reject).

Email Authentication & Deliverability Protocols Comparison

ProtocolDNS RecordValidation MethodProtection ProvidedFailure Impact
SPFTXT (v=spf1 ...)IP address whitelist matching envelope Return-PathBlocks forged sender envelopes from unlisted IPsSoftfail (~all) or Fail (-all), marked as spam
DKIMTXT (selector._domainkey)Asymmetric cryptographic signature over body & headersDetects message tampering / modification in transitInvalid signature, authenticity alert
DMARCTXT (_dmarc.domain)Domain alignment of visible From: with SPF/DKIMPrevents executive impersonation & exact-domain phishingPolicy action: none (monitor), quarantine (spam), reject (drop)
ARCIn-Header sealsCryptographic chain of custody for mailing lists & forwardsPreserves SPF/DKIM validation when forwarders break alignmentAllows legitimate forwarded messages to reach inbox
BIMITXT (default._bimi)SVG brand logo verified by VMC certificate in DNSDisplays verified corporate trademark in recipient inboxesStandard initials or generic placeholder icon displayed

Frequently Asked Questions