How to Read an Email Header

The name in the inbox list, the address behind it, the subject, and where a reply would go. This is your subscriber's entire first impression, and none of it is verified by anything. The sender typed all four. Anyone can put any name and any address in a From line.

Standards people call this one the header From, or RFC5322.From if you ever end up reading the DMARC spec. Worth knowing, because there is a second From address in every email that your subscriber never sees, and the two are checked by completely different things. That's the next line.

Before a single line of the message is transmitted, the sending server opens the SMTP conversation with a command: MAIL FROM. The address it gives there is the envelope sender. When the receiving server finally delivers the message, it writes that value into the header as Return-Path.

You will see the same thing called the envelope from, the bounce address, the return-path address, and RFC5321.MailFrom. One address, five names, depending who you're talking to.

It exists so failures have somewhere to go, which is why it reads like a reference number rather than a mailbox: this platform has encoded an identifier into it so a bounce can be matched back to a specific send. Common, but a choice rather than a rule.

And here is the part worth carrying around for the rest of your career: SPF checks this address, not the one in the From line. A sender can pass SPF perfectly while showing your subscriber a completely unrelated name. The third example on this page does exactly that.

The receiving server's record of what it was able to verify. Three checks, and the thing to memorize is which address each one covers.

So SPF and DKIM each prove a domain that doesn't have to be the one in the From line, and DMARC is the check that ties the visible domain to one of them. Here everything lines up: the envelope is on b.e.verityart.example, the signature on e.verityart.example, the visible sender on e.verityart.example. Different subdomains, one organizational domain, which is what relaxed alignment allows. Domains that don't match aren't automatically a problem.

Results are not just pass and fail, either. You'll meet none, neutral, softfail, temperror and permerror, and they mean different things.

One warning before you rely on any of it: only the topmost Authentication-Results, written by your own provider, counts. Everything below it arrived with the message, and anything that arrived with the message could have been typed by whoever sent it. The third example abuses exactly that.

Each server that handles the message adds a Received: line at the top, so the stack runs newest-first and you read it upwards to follow the message forwards in time.

Not all the way to the bottom, though. Only the lines your own provider and the servers it trusts wrote are evidence. Below the point where that chain started, the lines arrived with the message and the sender could have invented them, which the third example on this page did. Start at the oldest hop inside the run you trust, not the oldest line on screen.

This route is about as short as bulk mail gets: the platform's outbound server handed straight to Google, one hop, over TLS 1.3. Check the timestamps against the Date line and the whole trip took a second. A gap of hours between two lines means the message sat somewhere, which is worth knowing before you go hunting for a content problem.

One identifier for this exact message, everywhere it went. Quote it to your platform's support team and they can pull that single send out of their logs, which beats describing it. You need a copy of the message to read it here, so in practice it comes off your own seed address, or off a copy a subscriber pasted back to you.

It gives something away for free, too. The domain on the end belongs to the sending platform, not the brand. That's usually how you can tell who a company sends through by opening one of their emails.

Two lines that work as a pair. List-Unsubscribe offers a way out; List-Unsubscribe-Post marks it as one-click, so the mailbox provider can act on it without the reader ever loading your page.

The detail almost everyone misses is sitting in the DKIM signatures above. For one-click to be trusted, the signature's h= list has to cover both headers; otherwise the request can't be tied to the message and it gets ignored. Both signatures here list them.

Whether Gmail then shows its own unsubscribe control is a separate question. The header makes it possible, not certain; reputation is part of that decision too.

Scroll further down the panel and there's a second Authentication-Results, written by Microsoft when the message first arrived there: spf=pass, dkim=pass twice, dmarc=pass, compauth=pass.

Same message. Both verdicts are accurate. The sender did nothing wrong; forwarding broke the chain afterwards. Read only the lower block and you'd call this sender healthy. Read only the upper one and you'd call them spoofed. Neither is the story.

So a failure here is a statement about the last hop, not an accusation about the sender. Before you escalate a spf=fail, check whether the mail was forwarded.

Further down, this message carries a second Delivered-To, a Received line with no receiving server and no timestamp, a Message-Id ending in @mx.google.com, and (the good one) X-Google-Sender-Delegation: dana@example.com Trusted Sender.

Google wrote none of it. A header is just text until a server you trust adds it, and every one of these was typed by the sender to survive a skim. This is the concrete version of the warning from line 02: read the topmost Authentication-Results, confirm your own provider's name is on it, and treat everything underneath as the sender's claim rather than the receiver's finding.

One practical note while you're here. The List-Unsubscribe on this message points at plain HTTP on a throwaway domain, with no List-Unsubscribe-Post beside it. On mail like this, unsubscribing is how you confirm the address is real. Don't.