Can an email header prove who sent a message?

No. Headers provide useful routing and authentication evidence, but individual fields can be forged and a compromised authenticated account can still send harmful mail.

Which Received header should I read first?

Read the Received chain from the bottom upward to follow the message from earlier hops toward the final receiving system.

How to Analyze an Email Header Step by Step

Email header analysis examines the metadata added as a message moves from the sender to the receiving mailbox. RFC 5322 defines the Internet message format and header-field syntax; RFC 5321 defines SMTP transport. Headers help explain routing, authentication, dates, and identifiers, but they must be interpreted together rather than treating one line as definitive proof.

1. Preserve the raw source

Use the mailbox provider's “show original” or “view source” feature. Forwarding a message can add or alter headers. If the message was received by GetOpenInbox, open it and use the raw source view.

2. Compare visible and technical identities

Check the visible From address, the Return-Path, and domains referenced by DKIM and DMARC. Differences can be legitimate—for example, when a delivery provider sends on behalf of a company—but unexplained mismatches deserve attention.

3. Trace the Received chain

Mail servers prepend Received fields, so the newest hop is normally at the top. Read from the bottom upward. Look for unexpected delays, unfamiliar infrastructure, malformed hostnames, and time-zone inconsistencies. Remember that earlier fields supplied before a trusted receiver handled the message may be forged.

4. Read authentication results

Locate Authentication-Results added by the receiving system. Its registered format is defined by RFC 8601. Review SPF, DKIM, and DMARC outcomes and the domains each check evaluated. A pass means a specific technical check succeeded; it does not guarantee good intent. See How to Read SPF, DKIM, and DMARC Results.

5. Inspect links and attachments

Compare link destinations with the organization the message claims to represent. Be cautious with URL shorteners, IP-address links, Punycode domains, unexpected archives, and executable attachment names. Do not open suspicious content just to investigate it.

6. Form a bounded conclusion

State what the evidence supports: for example, “DKIM passed for the provider domain, but the visible sender domain did not align.” Avoid conclusions such as “safe” or “definitely forged” unless independent evidence justifies them. Use the online email header analyzer as a starting point, not as a substitute for incident-response tooling.

References

RFC 5321: Simple Mail Transfer Protocol — SMTP transport and trace information.
RFC 5322: Internet Message Format — message structure and header-field definitions.
RFC 8601: Authentication-Results — standardized syntax for recording message-authentication results.
CISA Secure Our World — official guidance on recognizing phishing and handling suspicious messages.