Email Header OSINT: Read Authentication and Routing Clues

Start with the original message, not a screenshot

A screenshot can show the display name and subject, but it removes most of the evidence you need. Keep the original message in the mailbox, note when and where it was received, and export or copy the full header without editing it. Gmail exposes this through More → Show original; Google’s current help page also explains where other common mail clients expose raw headers. See Google’s full-header instructions.

Headers can contain recipient addresses, internal hostnames, message identifiers and sometimes IP information. Treat the raw header as case material. Redact unnecessary personal data before sharing a teaching example, and do not paste a sensitive header into an unknown online parser. A local text viewer is enough for the first pass.

Separate four identities before deciding what matched

The internet message format defines structured header fields, but it does not make every field trustworthy. RFC 5322 describes fields such as From, Reply-To, Date and Message-ID. For investigation, group what you see into four layers:

Do not collapse these layers into one “sender domain.” A message may display one domain, use another for bounces, carry a signature from a service provider and direct replies somewhere else. The differences are often more useful than any single pass or fail label.

SPF, DKIM and DMARC answer different questions

SPF asks whether the connecting mail system was authorized to use a domain in the SMTP transaction. RFC 7208 explains that it authorizes hosts for domain use in the envelope; it does not authenticate the visible display name.

DKIM validates a cryptographic signature attached to selected headers and the message body. The signing domain appears in the signature’s d= value. A pass supports that the signed content survived validation under that domain’s key. It does not say that every unsigned header is reliable, and it does not identify the employee who pressed Send. The base specification is RFC 6376.

DMARC evaluates whether an authenticated SPF or DKIM identifier aligns with the author domain in the visible From field, then applies the domain owner’s published handling policy. The current IETF specification is RFC 9989, published in May 2026. A DMARC pass is valuable evidence that the visible domain aligns with at least one authenticated mechanism. It is still not approval for an invoice, password reset or payment change.

Write the results with their domains, not as three floating words:

SPF: pass — evaluated mail-from domain: ______
DKIM: pass — signing domain d=: ______
DMARC: pass — visible From domain: ______
Alignment observed through: SPF | DKIM | both | unclear
Reply-To domain: ______
Important mismatch or limit: ______

Read the relay path from the trusted edge inward

Mail systems usually add a new Received field above the fields already present. That means the oldest visible hop is often near the bottom and the newest near the top. Reading bottom-up helps reconstruct the claimed sequence, but trust does not increase simply because a line is older. A sender can manufacture early-looking lines before the message reaches the first system you trust.

1. Find the topmost Received line added by your receiving provider or organization.
2. Move downward one hop at a time and compare the receiving and sending hostnames, IPs, transport method and time zone.
3. Normalize every timestamp to one time zone before calculating delays.
4. Mark the boundary where the chain leaves infrastructure you can independently identify.
5. Treat everything below that boundary as a claim that needs another source.

Normal forwarding, mailing lists, help-desk platforms and cloud senders can create unfamiliar hops or break alignment. A mismatch is a question, not a fraud verdict. Ask whether the message’s legitimate workflow explains it.

Worked example: authentication passes, but the request still needs confirmation

This is a synthetic example. All domains use the reserved .example namespace and the IP comes from IANA’s documentation-only TEST-NET range. It is not a real message, customer case or OSINT Jet result.

From: "Cedar Accounts" <accounts@cedar-supply.example>
Reply-To: billing@cedar-payments.example
Return-Path: <bounce@mailer.cedar-supply.example>
Authentication-Results: mx.receiver.example;
 spf=pass smtp.mailfrom=mailer.cedar-supply.example;
 dkim=pass header.d=cedar-supply.example;
 dmarc=pass header.from=cedar-supply.example
Received: from mailer.cedar-supply.example (192.0.2.44)
 by mx.receiver.example with ESMTPS
Message-ID: <case-481@mailer.cedar-supply.example>

The header supports a narrow statement: the receiving system recorded SPF and DKIM passes, and DMARC aligned the visible author domain. It also exposes a separate observation: replies are directed to cedar-payments.example, a different domain. If the body requests new payment details, the authentication result does not settle whether that operational change is authorized.

The correct finding is not “the email is genuine” or “the email is fake.” It is: “Authentication supports use of the visible domain, while the different reply domain and high-impact request remain unresolved.” That sentence preserves both the useful evidence and its boundary.

Turn the header into a reviewable finding

Keep the message, header, related domain pages and independent confirmation as separate evidence items. For each one, record the source, retrieval time, exact observation and the inference you are testing. Link the final sentence back to those items instead of pasting a raw header into a report and expecting the reader to interpret it.

When a case also contains a website, company claim, phone number or prior invoice, OSINT Jet can help keep those supplied clues and public-source findings connected in one reviewable investigation. The useful value is organization: the authenticated domain, the reply-domain contradiction and the independent contact route stay visible together. It does not convert a pass result into proof of a person’s identity or authority.

Continue with the Email OSINT overview, use the investigation checklist, or record the result in the OSINT report template.

Organize the message, domains and contradictions in a case

Questions people usually ask

Does SPF pass prove the visible From address is real?

No. SPF evaluates authorization for an SMTP identity and connecting host. Read the evaluated domain and then check whether it aligns with the visible author domain.

Does DKIM pass prove nobody changed the email?

It supports integrity for the body and headers covered by the validated signature. Check the signing domain and remember that not every field must be signed.

Can an email header reveal the sender’s exact location?

Usually not. The visible IP may belong to a mail provider, gateway or relay. Use it as transport evidence only when the collection point and provider behavior are understood.

Should I upload a suspicious header to a public analyzer?

Only after considering the data it contains and the service’s terms. For a sensitive case, inspect locally or use a trusted organizational tool and share the minimum necessary excerpt.