Mail headersReading E-Mail Headers

How to find out the true sender

If you receive a spam e-mail or a virus, the "From:" line often does not display the true sender. However, most e-mail programs allow to display the raw mail header which discloses valuable information in such cases. In Outlook, for instance, right-click the e-mail in the list and choose Options. At the bottom of the Message Options window you will be able to view the Internet headers. In Outlook Express, open the e-mail you wish to view the header for, select File and click properties. Then click the Details tab to view the header. In Shamrock NetMail, simply open the e-mail you wish to check and click Header. Here is an explanation what all these lines can tell you.

Sample: A phishing mail

The sample below shows a very typical mail header. In this case it is even a so-called phishing e-mail, offering a link to a faked website which looks like the one of a bank, but then captures (fishes) your log-in data to use it for fraud. We have changed the recipient's address to for privacy reasons. Let's look at the header lines one by one.

Return-Path: <>
Received: from []
 by with smtp (NetMail-SMTP 1.16);
 Sun, 10 Oct 2004 03:40:32 +0200 (CEST)
Date: Sun, 10 Oct 2004 05:39:35 +0300
From: CitiBank <>
MIME-Version: 1.0
A typical header from a phishing e-mail with direct delivery.

Return-Path: This line is not created by the sender but inserted by the receiving e-mail server using the address behind MAIL FROM in the SMTP dialogue. It is not verified. In most cases (but not all) it is the same as in the From: header line which your e-mail client displays as the sender's address. Since there is only one MAIL FROM during the SMTP dialogue, there should be only one Return-Path line. An empty address like <> is allowed if the mail is from a Mailer-Daemon or a similar automated sender which cannot receive answers.

Envelope-To: For routing the received e-mail to the intended recipient(s), many e-mail systems insert this line using the address(es) from RCPT TO in the SMTP dialogue. While this is not really necessary for mails where all recipients are behind To: or Cc:, it allows the correct routing even for a Bcc: addressed e-mail. Unfortunately, the syntax is not standardized. "X-Envelope-To:", "Delivered-To:" or "X-Pop3-Rcpt:" are some alternative forms. Angle brackets around each address are optional.

[Connected from]
250 Welcome 84-120-132-215...
250 Sender ok
250 Recipient ok
354 OK End with <CRLF>.<CRLF>
(Now the e-mail is sent with header+body)

250 Accepted for delivery
421 Goodbye
SMTP dialogue for the same e-mail with client entries in red.

Received: While our example shows only one Received line, two or more of them are typical for most e-mails. Each mail server the e-mail passes on its way from the sender to the recipient inserts its own. The topmost is the newest, created by the server nearest to you, and you should rely on this one only, since all following lines may be faked. If there is only one Received line in the header, the sender did not deliver it via the SMTP smarthost of his local provider, but sent it directly to your server or your provider, which is very typical for spam and viruses. The format of Received lines is not always exactly the same, but in most cases it consists of this information:

Only the lines below the last (oldest) Received line are created by the client program of the sender or his local e-mail server.

Date: The date and time when this e-mail was created. It is not necessarily the time when the message was actually sent to the Internet. The format is the same as the one used in Received: lines described above. Since it depends on the client's system clock, it may be more inaccurate than the times in the Received lines created by well-adjusted servers.

From: The alleged sender of this e-mail. If an answer is requested to a different address than the one behind From:, a Reply-To: line is added with the address where an answer should go to. Both may be completely faked. It is crystal-clear that would never send their mails over a cable access of in Spain. -- For most normal mails, the From: line shows the same address as the Return-Path information in the header, but this is not required. Typical From lines are (comments added in brackets):
From: CitiBank <> (as in sample above)
From: "CitiBank" <> (quoted real name)
From: (no real name given)
The From: address in the sample above is faked, of course: The word "antifraud" and the name of the bank are simply intended to confuse the recipient.

To:, Cc: Displays the recipients except the ones sent as Bcc. Some badly implemented clients even send a Bcc line, but this does not conform to the standard since Bcc addresses should not be visible to other recipients. When sending an e-mail, the SMTP dialogue uses RCPT TO for all destination addresses, so the things behind To and Cc (just as all the other content of the message header and body) are completely irrelevant and may be even faked. The possible address formats are the same as for From (see above), multiple addresses can be separated by commas.

Subject: The subject of the e-mail. It is interesting that it is uppercase-only in this sample; this fact could add some percent to a probability value that an e-mail is unwanted spam.

The document RFC 2076, "Common Internet Message Headers", describes even more types of header lines, but we intentionally selected the most typical ones only and concentrated on how to find details about routing information and sender identity.

Many people can write, but few can read.
It is a pity: Valuable information in bounce mails is never read. Many people delete all e-mails from a "Mailer-Daemon" without looking at the content. Or they believe that all errors are caused by the recipient's mail server instead of themselves. Error texts like "User unknown" or "Mail exceeds size limit" are ignored. Instead, the same e-mail is sent again and again - unsuccessfully, of course. - If you receive an information from a Mailer-Daemon, read it carefully! It may be an informational mail about a delayed delivery, or even a positive delivery confirmation. If it contains an error message, correct your error before resending the original mail.

Be extremely careful when a header line seems to indicate that the mail is virus-free. Many trojans insert something like "X-Antivirus: No virus" to confuse the recipient. Some people call this "social engineering". Thousands of users do not hesitate to click on such e-mails, not anticipating that mail headers can be faked, and become sources of viruses and trojan-relayed spam themselves without even knowing that they are no longer the primary users of their own PCs.

The order of header lines is variable, but the Return-Path line is typically the first one since it is inserted by the receiving SMTP system before copying the rest of the mail. Upper or lower case is irrelevant for the keywords left of the colons, and the same is true for domain names (however, some mail systems actually are case-sensitive when dealing with usernames in e-mail addresses left of @). Domain names must only contain alphanumeric characters, dots the minus symbol, all others like the underscore or national 8-bit characters like are forbidden. Long header lines can be "folded," i.e. they can be split into several lines with one or more spaces or tab characters at the beginning of each new one.

Pointless bounces

Unfortunately, many mail servers equipped with a virus scanner are configured to create bounce e-mails if they detect that a received mail contains a malware program. But when it is sure that an e-mail actually is a virus, it can be safely assumed that the sender in the From field is faked, since all current viruses behave this way. So why irritate non-involved third parties with bounces for e-mails they never have sent? It is really advisable to disable these virus bounce mails.

For spam e-mails, the situation is a bit more complicated. No spam filter is perfect. So it may be a good idea to send a bounce if you are not 100 % sure that the e-mail actually is spam - it might be a false positive. If it is obvious, however, that it is spam, and we do know that the sender is often faked, then it is pointless to send a return mail. (Shamrock NetMail, for instance, uses an algorithm calculating the spam probability and does not send a bounce if the percentage is above a threshold value.)

KeyboardReporting spam

Most Internet Service Providers (ISP) have an abuse desk. In many cases, its e-mail address is abuse@<ISP domain>. Others require a web form to be filled out for abuse reports. Unfortunately they are often overloaded with unqualified reports from users who do not understand that their ISP cannot help in most cases. If you receive spam with a From: line indicating that it comes from, this does not automatically mean that is the address where to report it, since the From: address may be (and often is) completely faked.

Instead, have a look at the Received: lines. In most cases, the topmost is the one created by your server or provider showing the true IP address of the sender. In Unix/Linux there is the hosts command to do a reverse DNS lookup for a given IP address. In Windows 2000 and XP, you can use the nslookup tool at the command prompt to find out which name is associated with an address. For instance, enter
to see who that is, and you will see the name "". So the correct address for sending an abuse report, stripping of the subdomain parts, would be It may also be helpful to visit their website, which obviously is in this example.

If you send an e-mail to an abuse desk, never simply forward a spam mail to them since this would create entirely new headers, and the original ones are lost. Instead, copy and paste the spam header and body into a new mail. Make sure that you send this as a plain-text e-mail, not as HTML (many providers and users block HTML mails due to security considerations).

Unfortunately all this will not help much for the sample situation above. The dial-up provider would have to block the SMTP port 25 completely for all his customers to any destinations except his own SMTP server, blocking any direct mail deliveries. While this could be a good solution for stopping spam and viruses, there are some legal issues hindering ISPs to do so as long as they do not include this restriction in their customer contracts. So if you ever get a response from the abuse desk, it will probably state that this e-mail did not go through the ISP's SMTP server, and therefore the provider cannot do (or is not willing to do) anything. They also will not disclose who was using that specific dynamic IP address at the time given: Even though they could look it up easily in their log files, a lawsuit is required to get this information: Privacy protects everyone, even spammers.

So the only situation when it really makes sense to contact an abuse desk is when the IP address of the first relevant Received: line belongs to an SMTP server of this ISP. In all other cases it is left to you to filter spam.

1/2009 Herwig Feichtinger, Shamrock Software GmbH