How to Read and Interpret Email Headers

Written by: Will Kruss on 02 March 2020 04:21 PM

Find source of an email, view the mail headers & interpret the information correctly. Read VPSBlocks to learn.

If you want to see where an email originated from, you need to view the mail headers and interpret the information correctly. This is helpful in debugging where SPAM came from, or why messages are not being delivered properly.

There is a great article at: http://www.arclab.com/en/amlc/how-to-read-and-analyze-the-email-header-fields-spf-dkim.html

In case the article is removed we have duplicated the content here:

How to access the Message Header

Most mail clients allow access to the message header. The following list contains a few popular mail and web mail clients.
Please refer to the manual of your mail client if your mail client is not included in this list.

View the Message Header in Google Mail (GMail) Webmail:
Login to your account on the webpage and open the message (click on it). Click on the "down-arrow" on the top-right of the message and select "Show Original". Now you will see the complete message source.
View the Message Header in Yahoo! Mail Webmail:
Login to your account on the webpage and open the message (click on it).
Click on "Actions" and select "View Full Header".
View the Message Header in Hotmail Webmail:
Login to your account on the webpage and go to the message list.
Right-click on the message and select "View Message Source".
View the Message Header in MS Outlook:
Open the message in MS Outlook. Now go to "View" and select "Message Options" - or "File" -> "Info" -> "Properties".
Look at "Intenet Headers".
View the Message Header in Thunderbird:
Open the message, then click on "View" and select "Message Source".
View the Message Header in MS Windows Mail (and MS Outlook Express):
Select the message in the list, right-click on it and select "Properties" and go to "Details.

Standard Message Header Fields

Sample Message Header:

Return-path: <sender@senderdomain.tld>
Delivery-date: Wed, 13 Apr 2011 00:31:13 +0200
(3)Received: from mailexchanger.recipientdomain.tld([ccc.ccc.ccc.ccc])
by mailserver.recipientdomain.tld running ExIM with esmtp
id xxxxxx-xxxxxx-xxx; Wed, 13 Apr 2011 01:39:23 +0200
(2)Received: from mailserver.senderdomain.tld ([bbb.bbb.bbb.bbb] helo=mailserver.senderdomain.tld)
by mailexchanger.recipientdomain.tld with esmtp id xxxxxx-xxxxxx-xx
for recipient@recipientdomain.tld; Wed, 13 Apr 2011 01:39:23 +0200
(1)Received: from senderhostname [aaa.aaa.aaa.aaa] (helo=[senderhostname])
by mailserver.senderdomain.tld with esmtpa (Exim x.xx)
(envelope-from <sender@senderdomain.tld) id xxxxx-xxxxxx-xxxx
for recipient@recipientdomain.tld; Tue, 12 Apr 2011 20:36:08 -0100
Message-ID: <xxxxxxxx.xxxxxxxx@senderdomain.tld>
Date: Tue, 12 Apr 2011 20:36:01 -0100
X-Mailer: Mail Client
From: Sender Name <sender@senderdomain.tld>
To: Recipient Name <recipient@recipientdomain.tld>
Subject: Message Subject

Return Path: The email address which should be used for bounces. The mailserver will send a message to the specified email address if the message cannot be delivered
Delivery-date: The data the message was delivered
Date: The date the message was sent
Message-ID: The ID of the message
X-Mailer: The mail client (mail program) used to send the message
From: The message sender in the format: "Friendly Name" <email@address.tld>
To: The message recipient in the format: "Friendly Name" <email@address.tld>
Subject: The message subject

The From: line, which contains the sender of the message could be faked easily, so you should not rely on this information.

The lines in green contain the routing information, from the senders computer to the recipients mailserver.

Lets take a closer look at these lines:

(3) Received: from senderhostname [aaa.aaa.aaa.aaa] (helo=[ senderhostname])
by mailserver.senderdomain.tld with esmtpa (Exim x.xx)
(envelope-from <sender@senderdomain.tld) id xxxxx-xxxxxx-xxxx
for recipient@recipientdomain.tld; Tue, 12 Apr 2011 20:36:08 -0100

(3) The message was sent from the senders computer with the IP address aaa.aaa.aaa.aaa to the mailserver of the sender. In many cases the sender IP aaa.aaa.aaa.aaa is a dynamic IP address, e.g. DSL. The IP address gives many informations about the sender, the location of the sender and the provider.

(2) Received: from mailserver.senderdomain.tld ([bbb.bbb.bbb.bbb] helo=mailserver.senderdomain.tld)
by mailexchanger.recipientdomain.tld with esmtp
id xxxxxx-xxxxxx-xx

(2) The message was transfered from the senders mailserver with the IP address bbb.bbb.bbb.bbb to the recipients mailexchanger. The mailexchanger is the mailserver, which accepts incoming messages for a domain.

(1) Received: from mailexchanger.recipientdomain.tld([ccc.ccc.ccc.ccc])
by mailserver.recipientdomain.tld running ExIM with esmtp
id xxxxxx-xxxxxx-xxx; Wed, 13 Apr 2011 01:39:23 +0200

(1) The message was finally received by the recipients mailserver from the the recipients mailexchanger ccc.ccc.ccc.ccc.

This is only a sample, which should show the principles. The message routing can contain much more steps, depending on the used mailprovider. It should always be possible to see the sender computer IP address aaa.aaa.aaa.aaa and the sender mailserver bbb.bbb.bbb.bbb if the message was sent from a mail client and a client computer. If the message was sent from a webmail client, then the real IP address of the sender is not included - in this case aaa.aaa.aaa.aaa (if any) will be the IP address of the webmail.

Some might try to fake the routing information, but your mailserver should give you a warning that something is not correct during the transfer from the sender mailserver bbb.bbb.bbb.bbb to the recipient mailexchanger ccc.ccc.ccc.ccc.

Sender Policy Framework (SPF)

The Sender Policy Framework SPF is a complex framework. In easy words (simplified):
"SPF is used to describe what mailserver is allowed to send messages for a domain".

Its used to avoid fake email addresses (as sender email address). The system can detect if the mailserver, which want to send a message to the recipients mailexchanger is valid for the senders email address.

The result can be:
Received-SPF: neutral
Received-SPF: pass

If it fails,
Received-SPF: fail
You should normally not receive the message at all, because the message should be rejected by the mailexchanger.

DomainKeys Identified Mail (DKIM)

"Domain Keys Identified Mail (DKIM) is a method for associating a domain name to an email, thereby allowing an organization to take responsibility for a message in a way that can be validated by a recipient." ... from Wikipedia.org

In other words (simplified):
"Some organization (domain) has signed the message and is responsible for it".

Its a good indicator, that the message is NOT a spam message. No spammer would "sign" a message.

SpamAssassin's Header Lines

SpamAssassin is a anti-spam software, which is installed on many mailservers. Its a great tool, which gives a detailed report for each message by adding lines and a summary to the message header.

Sample for a clean message:
X-Spam-Level: ---
X-Spam-Score: -3.5
X-Spam-Report: Content analysis details: (-3.5 points)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/,
low trust [xxx.xxx.xxx.xxx listed in list.dnswl.org]
-2.5 SPF_PASS SPF: sender matches SPF record
-0.0 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification
0.0 DKIM_SIGNED Domain Keys Identified Mail: message has a signature
0.0 RDNS_NONE Delivered to trusted network by a host with no rDNS

A X-Spam-Score <5 means (on most systems) no spam, >5 probably spam and >15 spam. Spam might get deleted immediatly or moved to the junk mail folder. Some systems add [SPAM] to the subject, so that these messages could be moved to the junk folder in the mail client using a rule.

This sample shows a clean message, with a negative spam rating! It includes a SPF-pass and the message is DKIM signed.

SpamAssasin does not only check the message sender, it also checks the format and the content of the message.

Here is a sample of a spam-message, which should illustrate it:
X-Spam-Level: ++++++++++++++++++++++++++++++++++
X-Spam-Score: 34.7
X-Spam-Report: Content analysis details: (34.7 points)
pts rule name description
---- ---------------------- --------------------------------------------------
2.9 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
0.5 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
...
1.6 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist
2.1 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
2.9 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
2.5 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist
0.9 URIBL_RHS_DOB Contains an URI of a new domain (Day Old Bread)
...
0.0 MISSING_DATE Missing Date: header
0.1 HTML_MESSAGE BODY: HTML included in message
2.4 HTML_IMAGE_ONLY_08 BODY: HTML: images with 400-800 bytes of words
0.7 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
1.1 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image
1.3 SUBJECT_NEEDS_ENCODING SUBJECT_NEEDS_ENCODING
...

This message has a horrible spam-rating of 34.7. Its definitly a spam message.

It was received via a relay (mailserver), which is listed on a blacklist.
It contains a URL in the message-body, which is listed in several blocklists
The message format has errors

As you can see, the rules have different scores (spam rating), e.g. HTML_MESSAGE has only 0.1, because any rich-text (html) message would match this rule. HTML_IMAGE_ONLY_08 has a higher score of 2.4, because it indicates an "image message", where the sender tries to avoid the content filter by using an image instead of text.