Paste email headers to trace the delivery path, see SPF/DKIM/DMARC results and spot phishing. Analyzed in your browser.
Built & maintained by Pappu Venkata Subbi Reddy, founder of Clacify · Updated October 2026
Email Header Analyzer explains what an email's hidden headers say about where it really came from. Every message carries a block of technical headers that your inbox normally hides: one Received line added by each server that handled it, the verdicts your provider's server recorded when it checked SPF, DKIM and DMARC, the envelope sender that bounces go to, and the addresses behind the friendly names. Paste that block in and the tool turns it into a readable report: a verdict at the top, the message facts, the three authentication results with whether each one aligns with the From address, the delivery path as a numbered timeline with the delay and encryption at every hop, and a list of findings. The analysis runs in your browser, so headers that mention internal server names and IP addresses never leave your device. One more click re-checks the sender's domain against today's DNS, which helps when a message is old and the records may have changed since. It is built for IT and security teams triaging reported phishing, for email administrators working out why a message was delayed or sent to spam, and for anyone who wants to know whether a "your account will be suspended" message is genuine.
Headers are unfolded first (a line that starts with a space or tab continues the one above, as RFC 5322 defines), then split into fields. Received headers are added at the top by each server as the message passes through, so the tool reverses them to show the journey from the sender's side to your inbox. From each one it extracts the "from" host and IP, the "by" host, the protocol (ESMTPS and similar values mean the hop used TLS) and the timestamp, and it computes the delay between consecutive hops. A delay above five minutes is highlighted, and a hop that appears to arrive before it was sent is reported as a clock problem, not as a real negative delay. Authentication comes from the Authentication-Results header defined in RFC 8601. A message can carry several, some added by the sender's own systems and some forged, so the tool uses the topmost one, which is the one your provider added when it received the message. From it the tool reads the spf, dkim and dmarc results, the envelope domain (smtp.mailfrom), the DKIM signing domains (header.d or header.i) and the DMARC policy. It then repeats the DMARC alignment test itself: SPF counts only if the envelope domain shares an organizational domain with the From address, and DKIM counts only if a passing signature's d= domain does. Relaxed alignment is used, the DMARC default, so mail.example.com aligns with example.com. The sending server's IP is taken from Received-SPF's client-ip if present, and otherwise from the first public IP address at a hop where the message crossed from one organization into another. The live check uses that IP and the envelope domain to run a full SPF evaluation against current DNS (the same RFC 7208 engine as the SPF Checker), fetches the DMARC record (the RFC 9989 engine of the DMARC Checker) and looks up each DKIM key named in a DKIM-Signature header.
| Finding | What it means | How serious |
|---|---|---|
| DMARC fail | Neither SPF nor DKIM produced a result aligned with the From domain: the message could not be tied to that domain | High: the classic sign of spoofing |
| Display-name spoof | The name shown in your inbox contains an email address that differs from the real sender address | High: a common phishing trick |
| Reply-To on another domain | Replies go to a different domain than the sender | Medium: normal for some services, typical in invoice and CEO fraud |
| SPF fail or softfail | The sending server is not listed in the envelope domain's SPF record | Medium: can also be caused by forwarding |
| Not aligned | Authentication passed, but for a different domain than the one in From | Low to medium: often a misconfigured third-party sender |
| Slow hop | More than five minutes between two servers | Informational: queuing, greylisting or spam scanning |
Anything the sender controls can be forged, and that includes most of the header block. A spammer can write fake Received lines, a fake Authentication-Results saying everything passed and any From address they like. What a sender cannot forge is what happened after the message reached your provider: the topmost Received lines and the Authentication-Results your own mail server added on arrival. That is why the analyzer reads the first Authentication-Results header and builds the path from the top, and why headers should be copied from the original message in your mailbox. A forwarded copy carries the forwarder's headers instead, and if a colleague forwards you a suspicious email, the original headers are usually gone. Ask them to send it as an attachment, or use your organization's "report phishing" button, which keeps them.
SPF checks the server that connected to your provider, so when a message is forwarded (by a mailing list, a university alias or an automatic forward to Gmail) the forwarding server becomes the connecting one, and it is not in the original sender's SPF record. SPF then fails even though the email is real. DKIM usually survives forwarding, because the signature travels with the message, which is why DMARC passes if either one passes and aligns. Mailing lists that change the subject or add a footer break DKIM too. ARC (RFC 8617) was designed for this case: the forwarding server records the results it saw in ARC headers, and a receiver that trusts the forwarder can use them. If you see SPF fail, DKIM pass and DMARC pass, the message was most likely forwarded and is fine.
Load the "Phishing email" sample to see the pattern most real attacks follow. The display name is security@examplebank.example, so most mail apps show that, but the actual address is at examp1ebank-support.example, a lookalike domain with the digit 1 in place of the letter l. The receiving server recorded spf=softfail, dkim=none and dmarc=none: the lookalike domain has no DMARC record, which is typical, because attackers register such domains days before a campaign. The Reply-To sends answers to a free mail account. Notice that DMARC did not fail here: it protects the bank's real domain, which is exactly why attackers switch to lookalikes, and why the display-name check matters. Each sign alone has innocent explanations; together, and on a message asking you to act urgently, they are conclusive. The legitimate sample shows the opposite: DMARC passes, the DKIM d= domain matches the From domain, every hop is encrypted, and the List-Unsubscribe-Post header shows one-click unsubscribe, which Gmail and Yahoo have required from bulk senders since February 2024.
In Gmail, open the message, click the three-dot menu and choose "Show original", then copy everything. In Outlook on the web, open the message, click the three dots, then View > View message source. In Outlook for desktop, open the message and choose File > Properties, then copy the "Internet headers" box. Copy from the message in your own inbox, not a forwarded copy, because forwarding replaces the original headers.
Look at the receiving server's Authentication-Results: a DMARC "fail" means the message could not be confirmed as coming from the domain shown in From. Other signs are a display name that contains a different email address than the real sender, a Reply-To on an unrelated domain, and SPF failing for the server that sent it. The analyzer flags each of these. No single sign is proof, but a DMARC failure on a brand you know is a strong one.
No. Parsing and analysis run entirely in your browser. Only if you click "Check the sender live" does the page look up the sender's public DNS records (SPF, DMARC, DKIM keys), and those lookups contain only the domain name, never your headers.
Each server stamps the time it received the message using its own clock. Large gaps usually mean queuing or spam scanning at that hop; small negative gaps mean one server's clock is slightly wrong, so treat per-hop delays as approximate.