What Is a Received Header? Reading an Email Delivery Path

The Received header is a mandatory trace field that every Mail Transfer Agent adds to a message when it accepts and forwards it. It appears in every email that crosses the internet — stacked, one per hop — and records where the message was at each stage of its journey. Most recipients never open their email headers. But every server that handled the message left its mark, and the collection of Received lines is the most complete evidence of how that email traveled from the sender's outgoing server to your inbox.

What is a received header in email, in plain terms? It is the trace line a mail server prepends to a message when it accepts and relays it, recording the sending hostname and IP, the receiving server, the protocol used, and the exact timestamp of that handoff. Because each server prepends its line to the top of the header block, the stack is assembled in reverse: the topmost Received header is the freshest, written by the last server before delivery. The bottommost is the oldest, written by the first server that took the message from the sender.

Knowing what each field means, and knowing to read the stack from bottom to top, is the whole skill. After that, you can trace any delivery path, find where a delay happened, flag unusual routing, and understand why spam filters care more about the originating IP than the name the sender typed in the From field.

How does a Received header work?#

When you send a message, your mail client hands it to your outgoing Mail Transfer Agent. That server looks up the recipient domain's MX records, connects to the next server in the chain, and transfers the message. The receiving server writes a Received header and prepends it to the top of the message's header block, then forwards the message toward its destination. Each subsequent server does the same, adding its own header on top. The result is a stack of Received lines in reverse chronological order — most recent at the top, original hop at the bottom.

Each Received line follows the standard format defined in RFC 5321. The example below breaks a typical Received header into its named parts so you can read any real header using the same map.

The timestamp on each Received header is the moment that particular server accepted the message. Comparing consecutive timestamps tells you exactly where time was spent — a five-minute gap between two adjacent headers points to a slow relay, a greylisting delay, or a queue backup at that hop. A legitimate transactional send typically clears all hops in under thirty seconds.

Why does one message have multiple Received headers?#

A message rarely travels directly from the sender's mail client to the recipient's mailbox in a single hop. A typical path goes: the sender's mail client submits the message to their outgoing SMTP server, which transfers it to a relay or filtering gateway, which passes it to the recipient domain's inbound MX server, which delivers it to the mailbox. That is three to four hops, each adding a Received header. A more elaborate path — one that routes through a third-party spam filter, an archiving gateway, or a forwarding alias — can add two or three more.

The number of Received headers in a message is a natural consequence of how that message was routed, not a sign of anything unusual. Two headers indicates a simple direct delivery. Four to six is common for enterprise mail with perimeter filtering. More than eight may indicate forwarding chains or unusual relay infrastructure, which is worth examining but is not inherently suspicious on its own.

Received header vs From and Return-Path#

The Received header is a trace field, not an addressing field. This makes it easy to confuse with the From header and the Return-Path, which serve different purposes and are written by different parties. The distinctions matter for understanding what each field can reliably tell you and what it cannot.

Tracing the delivery path bottom-to-top#

Reading the Received stack from bottom to top reconstructs the delivery path in the order events happened. The bottommost header identifies the originating server — the one that first saw the message after the sender's mail client submitted it. The IP address recorded there is the one spam filters query against SPF records and IP reputation databases, because it is the address the sending domain is responsible for. Working upward, each header shows the next server in the chain and the elapsed time between that hop and the previous one.

When an investigation is needed — a delivery delay, a phishing report, a compliance question about message provenance — the Received stack is the starting point. Every server's identity, the IP it connected from, and the exact time it handled the message are preserved in full.

Can Received headers be forged?#

Partially, and understanding which part is important for using the headers correctly. A sender can inject a fake Received header into a message before submitting it to their outgoing server — adding a line that claims the message passed through a trusted server when it did not. This works because nothing prevents a sender from pre-loading the message with arbitrary headers before transmission.

However, the header written by the first server that accepted the message on the recipient's side cannot be faked, because it is written by software the recipient's domain controls. Working down from the topmost Received header — the most recent, written by the server just before your mailbox — you can identify the point at which you leave authoritative territory. The headers written by servers in your own mail path are reliable; headers below the first server you trust were prepended by parties you did not observe.

This is why spam filters focus on the originating IP recorded at the border MTA, not on the hostname a sender claimed in a lower header. The IP is the evidence the receiving server observed directly. A hostname embedded in a sender-injected header is just text — useful context, but not independently verified by the server that received the connection.

How this shows up in AI Emaily#

The Received stack is one of the inputs a mail client can use to evaluate a message before you open it. AI Emaily's spam and phishing protection reads the Received chain as part of its inbound analysis — checking whether the originating IP aligns with the sending domain's SPF record, flagging mismatches between the announced hostname and the connecting IP, and identifying routing patterns that are characteristic of phishing and compromised-account attacks, such as a message that claims a major provider as origin but arrives through an unfamiliar relay. Because the analysis runs on the full header block rather than the visible From address alone, it catches spoofed messages that would pass a surface read. We build AI Emaily.