scan.now
Premium Scan a site

Analyse an Email Header for Phishing

Paste the raw header from “Show original” or “View source.” Scan.now explains who sent the message, the sending IP and service, its route, and whether SPF, DKIM and DMARC passed, in language you can act on.

0 / 12,000 header characters · anonymous limit

No links are opened, no sender is contacted and the raw paste is never stored. Authentication results are interpreted from the header you provide; they are not independently re-run. Where to find the header

How to copy an email header

Use the original-source view, not Forward or Copy message. A forwarded email usually removes the evidence this analyzer needs.

Gmail

Open the message, choose the three-dot menu beside Reply, then Show original. Copy the original message. If the body is included, Scan.now removes it locally.

Outlook

Open the message, choose View or More actions, then View message details or View source. Copy the internet headers.

Apple Mail and others

Look for Raw source, All headers, Internet headers or View source. The paste should contain Received and Authentication-Results lines.

What this result can and cannot prove

SPF checks the server that sent the envelope, DKIM checks a cryptographic signature, and DMARC checks whether one of those identities lines up with the address visible in From. A DMARC pass is strong evidence that the sending domain authorised the message. It does not prove the human or company behind that domain is honest, and it cannot make a dangerous attachment safe.

The Received chain shows which mail systems say they handled the message. The newest entries are added by your provider and are normally the most trustworthy. Older entries can be supplied by the sender, so Scan.now labels the earliest public IP as “shown,” not as a proven physical origin.

How it works

  1. Copy the original header

    Use Show original, View source or Internet headers so the receiving server's evidence is preserved.

  2. We separate identity from routing

    The visible sender, Reply-To, Return-Path, Received chain and sending service are explained separately.

  3. Read a careful phishing verdict

    SPF, DKIM and DMARC results and identity mismatches are weighed without treating any single signal as proof.

What an email header reveals about a message

Raw headers preserve the identities, authentication verdicts and delivery hops that are hidden by the normal inbox view.

The visible From address is only one identity. Mail delivery also uses an envelope sender, DKIM signing domain, Reply-To address and a chain of servers recorded in Received fields. Phishing analysis depends on whether those identities agree and which entries were added by systems the recipient trusts.

Scan.now parses the header text you paste, removes an accidentally included message body in the browser and explains SPF, DKIM and DMARC results already recorded by the receiving provider. It separates display identity from routing evidence and labels uncertain self-reported fields instead of presenting them as verified origin data.

Preserve the originalPaste the raw source so authentication and Received fields remain intact.
Separate identitiesCompare From, Reply-To, Return-Path, DKIM and routing domains.
Explain the riskWeigh authentication, alignment, route and mismatch evidence together.

Put this result in context

This scanner answers one part of the review. Continue with Phishing URL Checker for lookalike domains and hidden redirects, then Password & Breach Check for breach lookup and strength analysis. These are separate checks because a strong result here does not prove that the adjacent surface is healthy.

For the background behind these signals, read How to Spot Phishing: URLs, Lookalike Domains, Urgency and the Checks That Work and SPF, DKIM and DMARC Explained: Stopping Email Spoofing of Your Domain.

Important email-header fields

The strongest conclusions come from fields added by the receiving provider and aligned authentication identities.

Header evidenceWhat it describesImportant caution
From and Reply-ToThe identity shown to the recipient and the address that receives a reply.A mismatch can be legitimate, but it is common in impersonation attempts.
Return-Path and SPFThe envelope domain and whether the sending IP was authorised for it.SPF can pass for a domain unrelated to the visible From address.
DKIMA cryptographic signature and the domain taking responsibility for it.A valid signature matters most when its domain aligns with From.
DMARCWhether SPF or DKIM passed with aligned identity under the sender domain's policy.A pass proves domain authorisation, not that the message content is harmless.
Received chainMail servers that say they handled the message, newest hop first.Older lines can be supplied by the sender and are less trustworthy.

How to interpret the phishing-risk verdict

Authentication, identity and message context must agree before a sensitive request should be trusted.

Aligned authentication

DMARC passes and the visible, reply and signing identities are consistent with the expected sender. Still inspect links, attachments and the request itself.

Identity conflict

Authentication failure, misalignment or an unexplained Reply-To mismatch can indicate spoofing or a compromised sending workflow.

Incomplete evidence

Forwarding, mailing lists or copied headers can remove or alter evidence. The report identifies what cannot be concluded.

Verify a suspicious email

  • Confirm urgent payment, password or account requests through a known phone number or independently opened service.
  • Inspect the actual link destination and scan unexpected attachments before opening them.
  • Give the complete original header to your mail administrator when reporting spoofing or delivery problems.
  • Preserve the message rather than forwarding it inline, which can remove the original authentication evidence.

What this result does not prove

  • The analyzer interprets recorded authentication results; it does not rerun SPF, DKIM or DMARC against the historical send.
  • A legitimate authenticated account or marketing platform can still send a malicious or compromised message.
  • Headers cannot prove who physically operated a sending account or whether a link or attachment is safe.

Related tools

Continue the review with four checks that cover adjacent parts of the same attack surface.

All tools
Privacy Phishing URL Checker

Lookalike domains and hidden redirects
Privacy Password Strength & Breach Checker

Breach lookup and strength analysis
Browsers Browser Security & Privacy Check

Fingerprint, leaks, version, policies
Files File Malware Scanner

Malware in documents and archives

Guides for this tool

Background reading written to go with these results.

8 min read · Updated Sep 13, 2026 How to Spot Phishing: URLs, Lookalike Domains, Urgency and the Checks That Work

Phishing succeeds by looking legitimate at a glance. This guide teaches the checks that hold up: Reading a URL from the right end,...

Read the guide
9 min read · Updated Sep 10, 2026 SPF, DKIM and DMARC Explained: Stopping Email Spoofing of Your Domain

Without SPF, DKIM and DMARC anyone can send email that appears to come from your domain. What each record does, how to write them, how...

Read the guide
8 min read · Updated Sep 12, 2026 Two-Factor Authentication: SMS vs Authenticator Apps vs Passkeys and Security Keys

A second factor stops most password-based takeovers, but the methods differ enormously in strength. This guide ranks SMS codes,...

Read the guide

Frequently asked questions

Does a DMARC pass mean the email is safe?

No. It means the receiving provider found an authenticated identity aligned with the visible From domain. A legitimate account can be compromised, a legitimate service can send a harmful request, and links or attachments still need their own checks.

Do you contact the sender or open links?

No. The analysis is performed only on the text in the pasted header. No address is contacted, no link is opened and no attachment is downloaded.

Do you store the email?

The raw header and message body are not stored. The 30-day report contains only the derived explanation, sender domains, routing hosts and IP addresses so you can keep or share the result.

Why can the earliest IP be uncertain?

Your mail provider adds the newest Received lines and those are normally trustworthy. Older lines can have been supplied by the sender, so the analyzer reports the earliest public address shown without claiming it is a verified physical origin.

What if I paste the entire Gmail original?

The browser detects the first blank line, keeps the header above it and removes the message body before sending the analysis request.