SPAMmers often forge the EMail headers that you have just learned about.
One Received: header is always prepended by each host in the delivery chain as it receives the EMail message. Normally no other headers are added or modified by the intermediate hosts.
However if the message is missing a Message-id:, Date:, From: or To: header (ie. forged) it will often be generated and prepended automatically, occasionally special X-? and Resent-? headers are prepended to log unusual operations that have occurred and the final recipient site may prepend a Status:, From (Note, no ':'), Return-path: or Delivered-To: header.
If a Received: header is after any header except these headers, it is probably forged and it and the headers after it can not be trusted.
However, no matter what the SPAMmer does, at some stage the SPAMmer has to pass the forged EMail message on to a responsible host Post Office. That host's Received: header is the one you should be using to determine the identity of the sender of a forged EMail message.
Recalling Example 1 of a valid header, Received: from brow529 (slip-32-100-191-102.ca.us.ibm.net [126.96.36.199]), the from brow529 is usually forged by most SPAMmers. The (slip-32-100-191-102.ca.us.ibm.net [188.8.131.52]) is the verification address where it was really received from that the receiving site (in this case out5.ibm.net) added to the header. Thus, (slip-32-100-191-102.ca.us.ibm.net [184.108.40.206]) is the most reliable portion of this header.
Another check is that the Message-ID: <34EFCDE8.7BB9@ibm.net> must exist and contain the doamin of the sender. In this case, ibm.net.
You can often tell when forged Received: headers have been added because the information they provide on the routing of the message is inconsistent or totally wrong: