Start with the received original and your receiver's trusted evidence, distinguish each field's role, and verify consequential instructions through an independently known channel.
Email headers help explain a message; they do not make its instructions trustworthy by themselves. A useful review separates the address the message presents, where a reply would go, and evidence your mail service can stand behind. Do not turn a technical-looking block into a reason to approve a payment or reset an account.
This guide follows two fictional situations: an expected workshop newsletter sent through an outside service, and an unexpected request apparently from a familiar colleague. No real messages were inspected. The aim is a clear investigation record, not a universal fraud detector or a replacement for the receiving provider’s incident process.
Begin with the received original
Use your own mail client’s supported option for viewing original message details. Do not follow a “verify this sender” link inside the questionable message to obtain its headers. Record the selected mailbox, subject reference and receipt time privately so you do not later compare the wrong item in a conversation.
Keep the original intact in its protected location. If an export is authorised, restrict access and retain an unmodified copy. A forwarded summary or screenshot can be useful context, but ask the support team which evidence format it needs before assuming it contains everything necessary.
Write the question first. For an expected newsletter: “Did this correspond to the workshop’s scheduled mailing?” For the unusual request: “Should anyone act on this instruction?” Those questions require different follow-up. A routing explanation may settle the first while leaving the second entirely unanswered.
Separate the visible identity and reply roles
RFC 5322 defines From as the declared author, Sender as the transmitting agent when applicable, and Reply-To as a suggested reply destination. Date gives the origination date, while Message-ID identifies a message for reference. These roles do not authenticate the named person. Record the actual addresses rather than relying only on a display name.
| Field to inspect | Question for the review | Do not infer |
|---|---|---|
| From | Which author does this item claim? | A known person approved the request |
| Sender | Is a separate transmitting agent declared? | A third-party service is necessarily suspicious |
| Reply-To | Where would this response be directed? | The destination is authorised for sensitive information |
| Date and Message-ID | Which item should support correlate? | A timestamp or identifier proves legitimacy |
In the fictional newsletter, the workshop expects readers to reply to its staffed contact address while a mailing service performs delivery. Ask the workshop’s authorised owner whether this is the intended arrangement. Difference alone is a question to reconcile, not a verdict of abuse.
For the unexpected colleague request, do not reply to test the address. Contact the colleague using a number or conversation route already known independently. Describe the request without forwarding confidential material into an unverified channel. Pause the consequential action while confirmation is missing.
Keep transport evidence in its own lane
RFC 5321 describes Received trace fields added by receiving SMTP systems and final Return-Path preservation of the reverse-path used for errors. That error destination can legitimately differ from the displayed author and reply address. Start with evidence your receiving service can explain; do not treat earlier supplied lines as automatically verified.
Ask support to identify the portion of the journey it can substantiate and which conclusions remain uncertain. Avoid a public IP lookup followed by a confident statement about who personally sent the message. Your question concerns accountable sending activity, not a location guessed from a network label.
If the complaint is lateness, build a comparison sheet with the claimed send event, the receiver’s recorded event and their time zones. Leave an empty cell where evidence is absent. Do not fill the gap with an assumed delay or accuse a provider because two displayed clock readings appear different.
Identify who produced authentication results
RFC 8601 makes Authentication-Results interpretation depend on a known administrative trust boundary. The presence of a field, or a word such as pass, does not establish that its producer is trusted. Ask the receiving provider which authentication-service identifiers and results it treats as its evidence. A reported result is not a certificate that the message is safe, wanted or authorised by a particular employee.
Keep an “observed” column separate from an “accepted evidence” column. Copy only the minimal result and producer reference needed for an approved support discussion. If you cannot determine which producer is relevant, record that as an open question rather than selecting the most reassuring line.
For the fictional newsletter, an administrator might reconcile a recognised service, the expected campaign and a permitted sample. For the suspicious request, even a meaningful domain-level authentication result would not answer whether the employee intended the instruction. Confirm that separately. Avoid making the technical review responsible for a business decision it cannot support.
Create a private investigation worksheet
Use a small record with a purpose and an owner. “Checking everything in the headers” encourages copying information without a decision. Instead, assign each uncertainty to someone who can supply the missing evidence and say what would resolve it.
- Item reference: a protected original location and a support correlation reference.
- Expected event: the newsletter, receipt or conversation the recipient was anticipating.
- Observed difference: the exact address, timing or result that triggered review.
- Evidence owner: the mailbox provider, sending-service owner or independently contacted person.
- Outcome: confirmed arrangement, confirmed incident, unresolved question or unrelated issue.
In the workshop case, the owner can compare the message with the scheduled campaign and approved reply workflow. Record the confirmation and its scope: this particular mailing, not every future message with a similar subject. Close the ticket only when the original question is answered.
In the colleague case, the known person denies the request. Stop the proposed action and follow the organisation’s incident route. The worksheet should capture the denial and preserve the original reference. It need not solve every unexplained header before the operational team takes the appropriate precaution.
Share enough evidence without publishing the message
Headers can reveal addresses, service names and operational identifiers. Do not paste a complete original into an unfamiliar online analyser or a public discussion. Prepare a redacted support copy when appropriate, with explicit notes about what was removed. Give the authorised investigator access to the untouched original through the agreed private route.
A heavily edited copy may no longer support the investigation. Ask which fields must remain intact, who will access them and when the support copy should be removed. Keep passwords, sign-in links and unrelated conversation content out of the ticket. No diagnostic convenience justifies broadly exposing the mailbox.
Close the right investigation
For many-message authentication patterns, use aggregate DMARC report review instead of generalising from one item. For a relay-related problem, consult forwarding and authentication. A returned delivery notice belongs in the bounce investigation. Finish with an answer bounded by the evidence, a responsible owner and a clear next action when uncertainty remains.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RFC 5322: Internet Message FormatChecked Originator, reply and message-identification fields.
Limits: Declared identity and identifiers are not personal authentication. - RFC 5321: SMTPChecked Received trace and final Return-Path roles.
Limits: Transport fields do not authenticate a person. - RFC 8601: Authentication-ResultsChecked Authentication-result interpretation within a known trust boundary.
Limits: An asserted pass alone establishes neither a trusted producer nor safe content.