Received Header
What is Received Header?
The Received header is the trace field every SMTP server prepends to a message it accepts, recording the host it came from, the host that took it, the protocol and a timestamp, as RFC 5321 section 4.4 requires. AdminKit's email header analyzer reads the Received chain from pasted headers and computes the delay at each hop.
By AdminKit team, Netbase JSC · Updated
The Received header is a trace field that each SMTP server adds to a message as it accepts it. RFC 5321 section 4.4 requires a server receiving a message for delivery or further processing to insert this trace information at the beginning of the message content, and forbids any mail program from changing or deleting a Received line an earlier hop already added. The result is a stack of lines, newest on top, that records the path a message took. Each line normally names the host the message came FROM, the server it was received BY, the protocol WITH which it arrived (for example ESMTPS when STARTTLS was used), a queue ID, sometimes the recipient FOR whom it was accepted, and a timestamp after a semicolon. That queue ID is local to one server; the identifier for the message as a whole is the separate Message-ID header set by the system that created it. The field’s syntax is part of the trace fields in RFC 5322 section 3.6.7, and Received is listed in IANA’s Message Headers registry. RFC 5321’s IETF Datatracker entry lists RFC 7504 as an update to it; that update adds the 521 and 556 reply codes and does not change the trace rules.
Why do Received headers matter when investigating an email?
Comparing the timestamps of consecutive lines shows where a message was delayed, and the FROM clause of the lowest line your own servers added shows the real IP that handed the message to you, which is the address SPF is checked against. Everything below that point was written by systems outside your control and may be forged, so a Received chain is evidence to weigh, not proof. The receiving server’s verdicts on SPF, DKIM and DMARC are recorded separately, in the Authentication-Results header.
AdminKit’s email header analyzer parses the Received chain and computes hop delays in your browser. The Received header is part of AdminKit’s email authentication cluster; the full AdminKit glossary lists other related terms.
Frequently asked questions
In what order should Received headers be read?
Bottom to top. Each server adds its Received line at the beginning of the header section, so the lowest Received header is the earliest hop and the top one is the last server that handled the message.
Can a Received header be forged?
Yes, any line added before the message reached a server you trust can be invented by the sender. Only the Received lines added by servers inside your own mail system, at the top of the chain, can be relied on; lines further down are claims made by earlier hops.
What information does a typical Received header contain?
RFC 5321 describes FROM (the sending host), BY (the receiving host), VIA and WITH (the link and protocol used, such as ESMTPS), ID (the receiving server's queue identifier) and FOR (the recipient) clauses, followed by a semicolon and the date and time the message was received.
May a mail server remove or rewrite earlier Received headers?
No. RFC 5321 says an Internet mail program must not change or delete a Received line that was previously added to a message, so the chain is meant to accumulate one line per hop.