← All cheat sheets

EMAIL HEADER ANALYSIS

Plain-text reference · 5 KB. Read it, search it (Ctrl-F) or print it.

Reading email headers for phishing triage. Headers are read BOTTOM-UP for the
Received chain (the first hop is at the bottom). Everything below the final
Received line can be forged; trust decreases as you move up toward the sender.

GETTING THE HEADERS#

Outlook:     Open message > File > Properties > "Internet headers".
             (or the classic "View Source"/message options)
Gmail:       Open message > three-dot menu > "Show original".
Apple Mail:  View > Message > All Headers (Shift-Cmd-H).
Always analyse the FULL raw headers, not the client's friendly display.

THE RECEIVED CHAIN (read bottom to top)#

Each relay prepends a "Received:" line. The LAST one (bottom) is the first
server that handled the message; the TOP one is your own gateway.

Received: from <claimed-name> (<reverse-DNS> [<real-IP>])
          by <receiving-host> with <protocol> id <id>; <date>

Checklist per hop:
- Does the "from" claimed hostname match the reverse-DNS and IP? Mismatch is
  common in spoofing (not proof alone).
- Is the originating IP in the sender domain's expected infrastructure/SPF?
- Do timestamps advance sensibly bottom-to-top? Big gaps/time travel = odd.
- Count the hops; an unusually long or geographically scattered chain is a
  flag. Note: internal hops below your trust boundary are forgeable.

AUTHENTICATION-RESULTS (the key verdict line)#

Added by the RECEIVING mail system (e.g. your gateway/Microsoft/Google).
Trust the one stamped by YOUR infrastructure, not any the sender supplies.

Authentication-Results: mx.example.com;
    spf=pass    (sender IP allowed)       smtp.mailfrom=sender.com
    dkim=pass   (signature valid)         header.d=sender.com
    dmarc=pass  (alignment + policy)      header.from=sender.com

Possible results: pass, fail, softfail, neutral, none, temperror, permerror.

SPF (Sender Policy Framework)#

- Validates the sending IP against the domain's published SPF (TXT) record,
  checked against the Return-Path / MAIL FROM (envelope), NOT the visible
  From header.
- pass      : IP authorized by MAIL FROM domain's SPF.
- fail (-all): IP not authorized -> hard fail.
- softfail (~all): not authorized but accepted.
- SPF alone does NOT protect the visible "From:" the user sees.

DKIM (DomainKeys Identified Mail)#

- Cryptographic signature (DKIM-Signature header) over selected headers +
  body, verified via the signing domain's public key in DNS (selector._
  domainkey.d=...).
- d= is the signing domain; s= is the selector.
- dkim=pass means the message was not altered in transit and the signing
  domain vouches for it. A valid DKIM from an UNRELATED domain still fails
  DMARC alignment.

DMARC (alignment + policy)#

- Ties SPF and/or DKIM back to the VISIBLE From: domain (alignment) and
  states a policy: p=none / p=quarantine / p=reject.
- DMARC passes if SPF OR DKIM passes AND is aligned with the From domain.
- dmarc=pass with p=reject is strong; dmarc=fail/none means the visible
  sender is not reliably authenticated.
- Alignment can be strict (exact domain) or relaxed (organizational domain).

FIELDS TO COMPARE (spoofing tells)#

From:          the display identity the user sees (easily spoofed text).
Return-Path:   envelope sender (where bounces go) -- often differs in phishing.
Reply-To:      where replies go -- attacker-controlled address here is a flag.
Message-ID:    domain in the ID vs the From domain -- mismatch is suspicious.
Sender:        if present, the actual submitting party.
X-Originating-IP / X-Sender-IP: origin hints (when present).

Classic phishing pattern:
  From:       "IT Helpdesk <helpdesk@yourcompany.com>"   (spoofed display)
  Return-Path: <bounce@random-marketing.ru>              (real envelope)
  Reply-To:    attacker@gmail.com                        (replies hijacked)
  dmarc=fail

PHISHING TRIAGE CHECKLIST#

[ ] Pull full raw headers (not client display).
[ ] Read Authentication-Results from YOUR gateway: SPF/DKIM/DMARC verdicts.
[ ] From vs Return-Path vs Reply-To: do they agree? Any free-mail Reply-To?
[ ] Originating IP (bottom Received): reputation, geo, owning ASN, in SPF?
[ ] Display name vs actual address (look-alike/cousin domain, homoglyphs).
[ ] Message-ID domain matches sending domain?
[ ] Subject/body: urgency, credential/MFA/payment lures, mismatched links.
[ ] Hover/extract URLs; defang before sharing (hxxp://, [.]). Check display
    text vs actual href. Expand any shorteners in a safe sandbox.
[ ] Attachments: type, hash (sha256), detonate in a sandbox -- never open
    directly on your workstation.
[ ] Correlate: did others receive it? Search the mail gateway for the
    sender/subject/URL. Scope the campaign.
[ ] Preserve the original (.eml / .msg) for evidence before any remediation.

RESPONSE ACTIONS (coordinate with IR process)#

- Quarantine/purge matching messages across mailboxes.
- Block sender domain/IP and the URLs/domains at mail gateway, proxy, DNS.
- Reset credentials / revoke tokens for any user who entered them.
- Report to the mailbox provider and, if relevant, an anti-phishing feed.

DMARC (RFC 7489).

Defensive reference on CyberRamen. Offensive / red-team sheets live on OffensiveRamen.com.