How to Analyze Suspicious Email Headers

To analyze a suspicious email's headers, first establish who added each piece of information. An executive's display name in From, an spf=pass result, or a long relay chain means little without that attribution. Ask a specific question: which trusted gateway observed which identity, through which connection?

This method supports the triage of a received message. It complements the SPF, DKIM, and DMARC authentication guide by focusing on the evidence to preserve and the decisions available when results appear contradictory.

Preserve the original message

Export the message in your mail client's supported format, including its full headers. Ordinary forwarding can replace transport information with details of the new delivery. A screenshot preserves the visible lure, but cannot reconstruct how the original arrived.

Keep an untouched copy and a working copy. Record the affected mailbox, reception time, time zone, and case identifier. If a gateway has already classified the message, preserve its trace identifier. That lets you retrieve the actual decision without relying on a partial copy of the headers.

Do not paste the whole message into a public analysis service. Headers can contain personal addresses and infrastructure details; the body may include documents or individualized links. For an external reputation check, start with the indicator you need, such as a link's domain.

Find the trusted entry point

SMTP relays prepend their Received headers, so the top of the message describes the most recent steps. RFC 5321, section 4.4 defines this trace mechanism. It does not guarantee that every header was authentic before the message reached your infrastructure.

Identify your organization's relays and those of its mail provider. Work down to the header describing reception from the Internet. Compare its IP address and timestamp with gateway logs. Beyond that boundary, statements made by earlier relays need corroboration.

This approach avoids a common mistake: treating the oldest header as the message's proven origin. A sender can prepare false headers before transmission. Even a plausible relay chain cannot identify the author's endpoint without additional evidence.

Read an example with three different identities

The following is a simplified fictional excerpt. Its .example domains and documentation IP address do not represent a real sender.

From: Purchasing team <achats@entreprise.example>
Reply-To: factures@paiement.example
Return-Path: <rebond@routeur.example>
Authentication-Results: mx.destinataire.example;
    spf=pass smtp.mailfrom=routeur.example;
    dkim=pass header.d=routeur.example;
    dmarc=fail header.from=entreprise.example
Received: from sortie.routeur.example (192.0.2.40)
    by mx.destinataire.example with ESMTPS;
    Tue, 29 Sep 2026 08:15:00 +0000

Assume mx.destinataire.example is your recognized gateway and its logs confirm reception. Keep three questions separate: where a reader's reply would go, which identity was checked during transport, and which identity appears in the visible sender field.

Reply-To directs replies elsewhere. That difference needs a business explanation, but support tools and other platforms use it legitimately. Record “replies directed to another domain,” then check whether this was expected. Calling it “the attacker's address” would go beyond the evidence.

Here, the SPF and DKIM results concern routeur.example, while DMARC fails for entreprise.example. These results are not contradictory: the checks do not all evaluate the same identity. DMARC connects the visible domain to aligned authentication, as described in RFC 9989.

In this scenario, ask the sending service's owner whether that mailer is authorized and correctly configured. An integration error and impersonation can leave similar traces. The message's content, logs, and business confirmation help distinguish them.

Use results from the right gateway

A message can contain several Authentication-Results headers. Identify the service that wrote each one and establish whether your architecture trusts it. RFC 8601 addresses this boundary and the handling of headers added outside it.

Your server's name appearing in a header is not sufficient evidence. Check the message trace and the header-sanitization configuration if there is doubt. A result copied into the body, placed in an attached message, or retained from a different route may not describe the reception you are investigating.

Next, compare the checks with the route the message actually took. Forwarding or a mailing list can alter what the final receiver observes. Where such a route exists, request the intermediate traces before concluding that a header was forged. Record missing evidence instead of treating incomplete results as certainty.

Examine the request after authentication

Once the identities are clear, return to the requested action: sending a document, entering a password, approving a login, or changing bank details. A correctly authenticated message can still be fraudulent if a legitimate account was compromised or the domain belongs to a malicious sender.

Extract link domains without opening them in a work session. Distinguish the displayed text from the actual destination, and preserve the relevant path in the case record. The guide to checking phishing domains covers this part of the investigation. Confirm unusual requests through an established channel, independently of the contact details supplied in the message.

If the user clicked, expand the investigation. Headers explain reception, not what the browser did afterward. Look for associated connections, downloads, or authentications. The guide to correlating IOCs, DNS, and processes describes that next step.

Write a conclusion that supports action

A useful conclusion separates observations, interpretation, and action. For example: “gateway confirmed; aligned authentication failed; mailer unrecognized; payment request unverified; message remains quarantined while the business owner is contacted.” This identifies the missing evidence and avoids closing the case based on one status indicator.

If the message is legitimate, document the responsible service and the required correction before granting an exception. If it is fraudulent, retain identifiers that let you search for other recipients. To enrich extracted domains and IP addresses, open an IsMalicious report, then attach the dated result to the reception evidence. Reputation adds context; the message traces establish what happened.