App StoreApp Store
Google PlayGoogle Play
Temp Mail Logo

Temp Mail safeguards your privacy while keeping your inbox free from spam.

🔬 SPF · DKIM · DMARC · Routing Trace · Origin IP · Spam Score

Email Header Analyser

Free online email header analyser — paste raw email headers to inspect SPF, DKIM, and DMARC authentication, trace the full routing path, identify the origin IP, and detect spam signals.

✓ SPF / DKIM / DMARC✓ Routing hop trace✓ Origin IP✓ Spam score✓ Full field viewer✓ 100% client-side
Paste Raw Email Headers
All analysis runs in your browser — headers are never sent to any server.
What this tool does

Free email header analyser — analyse SPF, DKIM, DMARC and trace email routing

Every email message carries a block of metadata called headers, added by each mail server that handles it. These headers record who sent it, who received it, when, and via which route — along with authentication results that prove (or disprove) the message is legitimately from its claimed sender. This tool parses that raw header text and presents the information in a structured, human-readable format.

The Authentication tab shows SPF, DKIM, and DMARC results at a glance — the three standards that together define modern email authentication. A message with all three passing is authenticated end-to-end. Any failure is worth investigating: it may indicate a spoofed sender, a phishing attempt, a misconfigured mail server, or a legitimate message caught by a configuration error.

The Routing tab reconstructs the delivery path in chronological order from the originating server to your inbox, with per-hop timing. Unusual delays, unexpected relay servers, or unrecognised origin IPs can all be spotted here. The origin IP — extracted from the oldest Received header — represents the actual network address that first injected the message, which cannot be spoofed the way the From header can.

Key header fields explained
Received
Added by each mail server that handled the message. Multiple Received headers trace the full delivery path.
Authentication-Results
Added by the receiving server. Contains SPF, DKIM, and DMARC verdicts. Cannot be forged by the sender.
Received-SPF
The receiving server's SPF verdict including the client IP and envelope-from domain checked.
DKIM-Signature
The cryptographic signature header. Contains the signing domain (d=), selector (s=), and algorithm used.
Return-Path
The bounce address — where delivery failure notifications are sent. Often differs from the From address.
Message-ID
A globally unique identifier for the message, assigned by the originating mail server.
X-Spam-Score
Numerical spam score from SpamAssassin or similar. Negative = clean. Above 5 = typically flagged as spam.
X-Mailer
The software or service used to compose or send the email. Can help identify bulk senders or ESPs.
Examples

Authentication results explained -- what each outcome means

The Authentication-Results header determines whether an email is legitimate. These are the most common result combinations.

Pass -- AuthenticAll three checks pass -- fully authenticated legitimate email
Authentication-Results: mx.example.com; spf=pass smtp.mailfrom=sender.com; dkim=pass header.d=sender.com; dmarc=pass p=reject header.from=sender.com Hops: 2 | Total delay: 0.8 seconds

SPF pass confirms the sending server is authorised by the domain's DNS. DKIM pass confirms message content was not modified in transit. DMARC pass with p=reject means the domain enforces its policy. Two hops and under one second total delivery time indicates clean, direct delivery with no suspicious relay involvement.

Fail -- SpoofedDMARC fail with p=reject -- CEO impersonation attempt blocked
Authentication-Results: mx.example.com; spf=fail smtp.mailfrom=attacker.com; dkim=none; dmarc=fail p=reject header.from=victim.com Return-Path: bounce@attacker.com From: ceo@victim.com

The From: header claims the email is from victim.com but the actual infrastructure belongs to attacker.com. SPF fails because attacker.com's servers are not authorised for victim.com. DKIM is absent entirely. This is a classic Business Email Compromise (BEC) attempt. The p=reject DMARC policy caused receiving servers to block delivery.

Warning -- SoftfailSPF softfail -- sender not explicitly authorised but not blocked
Authentication-Results: mx.example.com; spf=softfail smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass p=none header.from=example.com

SPF softfail (~all) means the sending server is not in the authorised list but the domain has not explicitly blocked it. DKIM still passes and DMARC passes on DKIM alignment. The p=none policy means no enforcement action is taken. This is typical of domains in DMARC monitoring mode before upgrading to quarantine or reject.

Info -- ForwardedSPF fail due to forwarding -- not a spoofing attempt
Authentication-Results: mx.example.com; spf=fail smtp.mailfrom=originalhost.com; dkim=pass header.d=sender.com; dmarc=pass p=quarantine X-Forwarded-To: user@example.com Received: from forwarder.university.edu

Email forwarding breaks SPF because the forwarding server's IP is not in the original sender's SPF record. DKIM passes because the signature travels with the message intact. DMARC passes on DKIM alignment so the message is delivered despite the SPF failure. This is normal behaviour for alumni forwarding, mailing lists, and server-side redirect rules.

Fail -- Suspicious12 hops and 4-hour delay -- unusual routing pattern
Received hops: 12 (expected: 2-4 for direct delivery) Total delay: 4 hours 17 minutes DKIM: none SPF: neutral

Legitimate email from major providers typically delivers in 1-30 seconds via 2-4 hops. Twelve hops and a four-hour delay strongly suggest the message was held in a spam queue or passed through multiple untrusted relay servers. The absence of DKIM and a neutral SPF result add to the suspicion.

FAQ

Frequently asked questions about email header analysis

What is an email header?
An email header is a block of metadata prepended to every email message by each mail server that handles it. Headers record the sender's address, recipient, subject, timestamps, routing path through mail servers, and authentication results for SPF, DKIM, and DMARC. They are hidden by default in most email clients but can be viewed via a 'Show original' or 'View source' option.
How do I copy email headers from Gmail, Outlook, and Apple Mail?
In Gmail: open the message, click the three-dot menu (⋮) → 'Show original' -> copy all text. In Outlook (web): open the message, click the three-dot menu -> 'View' -> 'View message source'. In Outlook (desktop): open the message, go to File -> Properties and copy the 'Internet headers' box. In Apple Mail: open the message, hold Option and click View -> Message -> All Headers, then select all and copy.
What do SPF, DKIM, and DMARC results mean?
SPF (Sender Policy Framework) verifies that the sending server's IP address is authorised to send email for the domain. DKIM (DomainKeys Identified Mail) verifies a cryptographic signature proving the message was not altered in transit. DMARC (Domain-based Message Authentication) ties SPF and DKIM together and specifies what to do with messages that fail — none (no action), quarantine (spam folder), or reject (block). All three passing means the message is authenticated end-to-end.
What does SPF fail or DKIM fail mean?
An SPF fail means the sending IP is not listed in the domain's SPF record — the message may be spoofed or sent via an unauthorised server. A DKIM fail means the cryptographic signature did not match, which could indicate the message was altered in transit or that the signing configuration is incorrect. Either failure is a strong indicator of spam, phishing, or misconfiguration worth investigating.
How do I trace where an email came from?
The routing section of the analysis shows each mail server hop in order from origin to destination. The first Received header (oldest) contains the originating IP address — this is the server that first injected the message into the internet's mail infrastructure. You can look up this IP in WHOIS or a blacklist checker to identify the sending organisation or flag known spam sources.
What is the originating IP and why does it matter?
The originating IP is the IP address of the first server to handle the message — usually the sender's mail server or the device that submitted the email. It is found in the oldest (last) Received header. Unlike the From header, which can be spoofed, the originating IP reflects the actual network infrastructure used to send the message, making it valuable for tracing phishing attempts and spam.
What is a routing hop and what delays are normal?
Each 'hop' represents a mail server that received and forwarded the message, adding a Received header with a timestamp. Normal delivery completes in under 30 seconds. A single hop with a delay of several minutes may indicate a slow relay, greylisting, or a congested mail server. Very large delays (hours or days) can indicate delivery problems, spam filter holds, or deliberate timestamp manipulation.
What does the X-Spam-Score header mean?
The X-Spam-Score header is added by spam filtering software (typically SpamAssassin) and reflects a numerical score based on characteristics of the message content, headers, and sending IP. A score below 0 is typically clean mail. Scores above 5 are usually flagged as spam. The exact thresholds vary by configuration. The X-Spam-Flag header shows YES or NO as the final verdict.
Can email headers be faked?
Some headers can be forged. The From header is trivially easy to spoof — it has no technical enforcement by itself. Return-Path and some Received headers can also be manipulated. However, authentication headers like Authentication-Results, Received-SPF, and DKIM-Signature are added by the receiving mail server and cannot be forged (the receiving server writes them). Always trust authentication results from your own mail server, not from headers added by external servers.
Is my email content processed by this tool?
No — this tool only analyses the header portion of the email, which contains routing and authentication metadata. The email body (text, HTML, attachments) is not used in any way. Additionally, all parsing runs entirely in your browser using JavaScript. No header data is transmitted to any server or stored anywhere. Your email headers are processed entirely client-side in the browser -- sensitive routing details, IP addresses, and server hostnames never leave your device.
Related Email Security Tools

Need a disposable email address?Generate a free, instant throwaway — zero signup, zero trace.

Get Free Temp Mail ->