Sometimes you need to check to see where a message really came from. The 'From:' email address is easily forged, so that cannot be relied upon.

The first thing you have to do is to get the full message headers. These may look daunting, but are very useful for problem diagnosis.

The most important headers are those beginning with Received. Each mail server which handles the message will add its own Received trace header to the start of the message. So, to see the passage of the message through time you have to find the lowest Received line in the headers, and work upwards.

This is an example of some full headers

Return-Path: <a.user@example.com>
Received: from mail.example.com ([127.221.14.44]) by lmail.pscs.co.uk ([217.155.61.13] running VPOP3) with ESMTP for <support@pscs.co.uk>; Thu, 20 Oct 2011 09:36:35 +0100
Received: by example.com (Postfix) for support@pscs.co.uk; Thu, 20 Oct 2011 04:36:27 -0400
Received: from [192.168.1.101] ([127.31.11.95]) by example.com (Postfix) with ESMTP id 891688127.17872.3016; Thu, 20 Oct 2011 04:36:25 -0400
Message-ID: <4E9FDD90.3080001@example.com>
Date: Thu, 20 Oct 2011 04:36:32 -0400
From: Alex User <a.user@example.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Paul Smith <support@pscs.co.uk>
Subject: Re: This is a message
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-VPOP3-ORIGRCPT: paul@pscs.co.uk

This has three Received lines. In order of occurring they are:

1. Received: from [192.168.1.101] ([127.31.11.95]) by example.com (Postfix) with ESMTP id 891688127.17872.3016; Thu, 20 Oct 2011 04:36:25 -0400
2. Received: by example.com (Postfix) for support@pscs.co.uk; Thu, 20 Oct 2011 04:36:27 -0400
3. Received: from mail.example.com ([127.221.14.44]) by lmail.pscs.co.uk ([217.155.61.13] running VPOP3) with ESMTP for support@pscs.co.uk; Thu, 20 Oct 2011 09:36:35 +0100

In fact, the first two of these are probably together, so just one server at the sender's end. The last line is the local mail server receiving the message from the sender's server.

In this case, the only information we can totally trust is that added by the local server. The remote server may not be well behaved, and may have added misleading information. So, what we know for definite is that the message came from a server at '127.221.14.44' which was called 'mail.example.com'. It arrived at our server at 9:36:35 (in the GMT+1hr timezone - or BST in this case).

If we know the sender's server, or are in contact with them, the other Received lines may help there as well. So, from those lines we can tell that the message reached the sender's server at 4:36:25 (in the GMT-4hrs timezone) - this is just 10 seconds before it arrived at our local server. The 127.31.11.95 address in the first Received line is the IP address of the sender as the first mail server saw it. The 192.168.1.101 is what the sending software was calling itself.

See Section 4.4 of RFC 5321 for details on the Received header line format. Note that as this line is not intended to be parsed by a computer the recommended format is not always strictly used, so a bit of intelligence is required when reading it.

Note that the Received line times are based on the relevant server's computer clock, so may not be accurate, so don't panic if a message appears to time travel. However, most server clocks are accurate within a few seconds.

If the message came from your local VPOP3 and you use SMTP authentication, you can also check the X-Authenticated-Sender header line, which shows which user logged in to send the message. (Note that if the passwords are weak, someone may have guessed their password and be using their account without their knowledge)

If the message came from a remote server, there may be similar authentication header lines, but there is no standard for those, and they could have been forged or changed since the message was originally sent, so should not be trusted 100%.