A suspicious email has landed in your inbox and you want to figure out where it really came from. You open the header and are faced with a jumbled wall of Received, Authentication-Results, and Return-Path — none of which match the From. The real question is: which field can you trust, and which one can any sender write however they like?
The short answer: from the SMTP protocol's point of view, almost no field in the header is "signed." Anything the sender adds themselves can be forged. The only thing with evidentiary value is the Received chain that intermediate servers append, plus the authentication result written by your receiving server.
An email header consists of two completely different families
Header fields are defined in RFC 5322, but in practical terms they fall into two categories that you should never mix up.
- Trace fields:
Received,Return-Path,Authentication-Results. These are written by servers, and their order is meaningful. - Message fields:
From,To,Subject,Reply-To,Date,Message-ID. These are written by the sender and carry no guarantees.
A common mistake I see every week: someone sees From: support@bank-x.ir and concludes the email came from the bank. This field is just a text string. Even Reply-To can point to a completely unrelated domain, sending your reply straight to the attacker.
Read the Received chain from bottom to top
Every server that accepts the message adds a Received line to the top of the header. That means the last line (bottom-most) belongs to the origin, and the first line (top-most) belongs to your own server. If you read from top to bottom, you're traversing the path backwards and will get lost.
Received: from mail.example.com (mail.example.com [203.0.113.45])
by mx.servernet.cloud (Postfix) with ESMTPS id 4A2B1C3D
for <you@yourdomain.ir>; Tue, 14 Jan 2025 09:12:44 +0330Check three things in each line: the claimed hostname, the IP inside the brackets, and whether the two match. If the hostname doesn't match the IP, the receiving server usually records unknown or an empty helo=. This is the only place where you can compare the sender's claim against network reality.
A point many people miss: Received lines that are above your last trusted server are fully forgeable. An attacker can add several fabricated lines to the header to make the path look longer and more innocent. The trust boundary is exactly the line your own server wrote.
Authentication-Results is the only field you should trust
This header is added by the receiving server, not the sender. If the message came from Gmail, you'll see a line like this:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.i=@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comThree values matter, and their order of importance is exactly this: dmarc, then dkim, then spf. The reason is simple. SPF only checks the sender's IP and has nothing to do with the message content; if an attacker sends from your authorized server, SPF passes. DKIM is a cryptographic signature over the header and body, so it catches content tampering. DMARC ties these two to the domain shown in From, and that's what prevents domain-name spoofing.
If you see dmarc=fail but spf=pass, it means someone used your authorized infrastructure but with a different domain. This is the classic pattern of a forwarded message, not necessarily an attack. Compare the difference against header.from.
This is where people go wrong
The most common error: relying on Return-Path to identify the real sender. Return-Path is the same as MAIL FROM in the SMTP envelope and can be set completely independently of From. The telltale sign is that in spam reports you see Return-Path pointing to an unrelated domain while From shows your brand name, and the user thinks the email is from you. Return-Path is only useful for bounces and DMARC reporting, not for identity.
The second mistake, which costs dearly: reading headers with clients that don't properly unfold folded lines. Long headers are broken onto the next line with a space or tab. If your tool ignores this, it reads the DKIM signature incompletely and reaches the wrong conclusion.
Which fields you should never trust
| Field | Who writes it | Forgeable? |
|---|---|---|
From | Sender | Yes, unless DMARC passes |
Reply-To | Sender | Yes, completely |
Return-Path | Origin server | Yes |
Message-ID | Sender | Yes, carries no authority |
Date | Sender | Yes, can be years off |
Received | Any intermediate server | Only lines above the trust boundary |
Authentication-Results | Receiving server | No, if it's from your own server |
One important exception: Authentication-Results is also forgeable if it sits above your trust boundary. An attacker can add a fabricated dkim=pass line. Always verify that this header was written by the same server that recorded the last Received.
What to do for a practical investigation
Get the raw header from the client, not from the preview. In Gmail, use the three-dot menu and "Show original"; in Thunderbird, press Ctrl+U. Then follow the path from bottom to top until you reach the first server outside your control.
If you want to know whether the sender's domain even has proper email infrastructure, first check its MX records; an MX record lookup is the fastest way to see whether there's a real server behind the domain or just a ceremonial record. For messages that land in spam and you can't see the reason in the header, the spam troubleshooting guide explains common patterns with header examples.
If you run your own mail server and want your outgoing headers to be clean, transactional email setup explains why bulk sending from shared hosting hits a dead end and what the right alternative is. For servers that come up on Linux hosting, these same Postfix and OpenDKIM settings can be applied directly.
And if your message volume is high and you want to automate header analysis, the documentation and knowledge base has examples of parsing headers with command-line tools.
Frequently asked questions
Can the From field in an email header be forged?
Yes, completely. From is just a text string the sender writes in the message, and SMTP has no mechanism to verify it. The only thing that prevents this forgery is the DMARC policy on the destination domain. If a domain doesn't have DMARC with p=reject, anyone can send email using its name and your server will deliver it.
What's the difference between Return-Path and From?
Return-Path is built from the MAIL FROM command in the SMTP envelope and is the return address for bounces. From is what the user sees in the client. These two can point to two completely different domains, and in legitimate sending this is often the case. To determine the sender's identity, compare From against the DMARC result, not against Return-Path.
Why is the Received header repeated several times?
Every server the message passes through adds a Received line to the top of the header. The number of these lines equals the number of hops the message made. If there are an unusually large number of them, or their timestamps don't line up, tampering is likely. Your trust boundary is the last line written by your own server.
How can I tell whether an email really came from the domain it claims?
Look at the Authentication-Results line and check the dmarc value. If it's dmarc=pass and header.from is the domain you expect, the message came from that domain's authorized infrastructure. If it's dmarc=fail or none, there's no guarantee, and you should verify the message's authenticity through another channel.