A header is evidence from a route, not a public diagnostic code
Message headers are the structured notes added by senders and relays as mail travels. They can contain the visible From address, envelope-derived return path, DKIM signature, message identifier, timestamps, routing hosts and authentication results. The body may be separate, but a copied ‘original’ often includes both.
The useful reframe is to treat a header like an incident record. Preserve a private original so context is not lost, then work from a redacted copy. Publishing the whole block for convenience can disclose correspondents, internal infrastructure, time patterns and provider account identifiers. Replacing every value before analysis can be just as harmful because it removes the relationship you need to trace.
RFC 8601 defines the Authentication-Results field used to convey receiver-side authentication outcomes. RFC 8601 It also explains a crucial trust boundary: results have meaning within the administrative domain that produced them. A header line supplied by an untrusted sender is not proof merely because its name looks official. Start with the copy obtained from the receiving mailbox you control.
Obtain the original from the receiving service
In Gmail, open the message, use the message options and choose ‘Show original’. Google documents this route and provides an option to copy the full text. Google: trace an email with its full header In Outlook, the interface varies by product, but Microsoft’s support page describes how to view internet message headers in supported Outlook versions. Microsoft: view internet message headers
Use the receiving copy, not the sender’s composition window. The delivered version contains fields added during transport and the receiver’s evaluation. Save it as plain text in a restricted case folder with the mailbox, UTC collection time and reason. Do not rename the original values inside that master copy.
If the message never arrived, obtain the full bounce or delivery event instead. Ask the sending provider for the event’s envelope sender, connecting IP, signing domain, selector and receiver response. If you cannot lawfully access the mailbox or incident record, stop. Ask the mailbox owner or authorised administrator to collect it rather than requesting credentials or remote access that exceeds your role.
bounce code troubleshootingMake a working copy with stable placeholders
Duplicate the private original. In the working copy, replace personal mailbox addresses with consistent labels such as sender-address-A and recipient-address-B. Keep the domain only when it is needed to assess alignment, and document that decision. Replace unrelated message identifiers, IP addresses, internal hostnames and tracking tokens with stable placeholders.
Consistency matters. If the same host appears in three Received fields, give it the same label every time. That preserves the route relationship without publishing the host. Keep public provider names and standards fields where they are relevant. Remove the body, attachment names, subject and quoted conversation unless the fault concerns content modification and an authorised expert needs them.
Do not use a public ‘header analyser’ until you have read its privacy terms and approved the disclosure. A header can be personal data and can contain confidential operational information. Local text search is usually enough. If an external supplier needs evidence, send the minimum redacted extract through the contracted support channel, record what was shared and apply your retention policy afterward.
Keep a mapping from placeholders to originals only in the restricted case folder. Never place that mapping beside a public ticket.
Read routing lines from the receiving edge backwards
Received fields are normally added as a message passes through relays. The newest field is usually nearest the top, so reading down often moves backwards in time. Start with the topmost line added by the receiving service, note its timestamp and trace older lines until you reach the earliest credible hand-off.
Do not assume the bottom line is true. Earlier fields may have been supplied before the message entered a trusted provider, and attackers can insert header-like text. Look for continuity: the ‘from’ host in one trusted hand-off should relate sensibly to the preceding ‘by’ host and timestamps should progress. Clock differences and queue delays can complicate timing, so record anomalies rather than rewriting them.
Identify the boundary where mail entered the receiver or your organisation. Authentication results produced there usually carry more diagnostic weight than similarly named fields below it. RFC 8601 discusses adding and removing authentication-result fields so consumers can distinguish results within a trusted administrative domain. Authentication-Results trust model
If the route contains unfamiliar gateways, forwarding services or security appliances, check your mail-flow documentation before declaring them hostile. Stop if ownership is unclear and ask the receiving administrator which header fields its system generates and trusts.
sender inventory templateSeparate the identities that look like one sender
Copy the visible From domain, the Return-Path domain and each DKIM d= domain into separate lines. Also copy the DKIM s= selector when troubleshooting a key. These values can differ legitimately because the visible author, bounce-handling domain and signing service have different jobs.
Do not infer the envelope sender from the visible From address. Return-Path is derived from the SMTP reverse path after delivery, while DKIM names a signing domain. A forwarding service may change the route without changing the visible From address. A marketing platform may use its own return path while signing with a customer-controlled domain.
Write the receiver’s reported SPF, DKIM and DMARC outcomes beside the exact identities it evaluated. Preserve qualifiers such as header.d, smtp.mailfrom and header.from. The result ‘SPF pass’ is incomplete without its authenticated domain, just as ‘DKIM pass’ is incomplete without the signer.
This small identity table prevents a common privacy mistake: sharing the entire header to show three values. It also prevents a technical mistake: treating every domain visible in the message as interchangeable.
For a definition of each identity and result field, keep the email authentication glossary beside the copied header.
Interpret authentication results inside their trust boundary
Locate the Authentication-Results field associated with the receiving service. It begins with an authentication service identifier, followed by methods and results. RFC 8601 standardises this format so filters and people can carry results forward. RFC 8601 field definition
Record pass, fail, none, neutral, policy or temporary-error text exactly. Do not turn ‘none’ into ‘fail’. None can mean the mechanism was not present or not evaluated. Retain any reason supplied because a DKIM missing-key failure differs from a body-hash mismatch, and an SPF permanent error differs from an unauthorised IP.
Multiple result fields may appear because a gateway, forwarder and final mailbox each evaluated the message. Compare their service identifiers and placement in the route. A result from your inbound gateway may explain what it saw before an internal forwarding rule; the final receiver may show what survived afterward. That difference can be the mechanism behind the incident.
The trade-off is detail versus confidence. A compact result field is easy to share but can hide routing context. A full header supplies context but increases privacy exposure. Keep the full version privately and disclose a focused extract containing the trusted result, necessary identity values and relevant hand-offs.
Authentication results describe one message on one route, and they only carry meaning inside the system that produced them. A sender passing its own records, or a pass that comes from a domain that is not the one the recipient saw as From, can still leave a message filtered. The header gives you the mechanism; deciding whether that matters still needs the receiver's actual outcome, which is why the header is a starting point rather than a verdict.
To understand what the authentication results in a header mean for your policy, read how DMARC ties SPF and DKIM to your From domain.
Turn the header into a controlled comparison
Write a short route record: sending feature, visible From domain, return-path domain, DKIM signer and selector, receiver, collection time, result field and trusted hand-off labels. Note what is observed and what is still an inference. Do not claim that a header identifies the human who clicked Send; it identifies systems and asserted message fields.
Choose one hypothesis. For example, a supplier may be signing with an unrelated domain, a gateway may be modifying signed content, or a different application may be using an unauthorised IP. Make one owned, reversible correction. Then send a plain non-sensitive message through the same feature to a mailbox you control.
Collect the new original using the same receiver instructions. Gmail original-message instructionsOutlook header instructions Compare the same fields, not merely whether the message appeared in the inbox. Exact verification means the intended identity now passes, the route is the expected one and the business function still works. Record the before and after evidence with UTC times.
Share less, retain deliberately and escalate with precision
A useful supplier extract contains the incident time and timezone, message or event reference, redacted From domain where necessary, receiver, trusted authentication-result lines, required d= and s= values, and the few routing lines that cross the supplier boundary. Explain your placeholders. Do not include unrelated recipients, the message body, authentication tokens or the full internal route.
After resolution, retain the private original only as long as your security, legal and operational policies require. Delete convenience copies from downloads, chat systems and desktops. If the message concerns HR, health, legal or customer data, involve the appropriate information-governance owner before sharing it outside the organisation.
Stop and escalate if you cannot identify the trusted receiver boundary, if headers conflict with provider logs, if a suspected compromise is involved, or if redaction would remove the evidence the specialist needs. Preserve the original without editing it. Ask the mail administrator or incident-response owner to review it under controlled access.
A header has done its job when it narrows the route, identity and result enough to support one testable change. It is not safe simply because it looks technical, and it is not proof simply because a line says pass.
Sources and further reading
- Google: Trace an email with its full header
- Microsoft: View internet message headers in Outlook
- RFC 8601: Message Header Field for Indicating Message Authentication Status