Understanding Email Headers


Do you understand what your email headers are trying to tell you?
As providers of hosted email solutions we’re often sent support requests for issues that can be outside our control and where an understanding of what a particular emails’ headers mean would help establish the nature any problems.

With this in mind we’ve put together a short tutorial on how to find your headers (if you’re not sure where to find them) and then how to interpret them.

Here is a brief description of email headers in a received email; in his case it’s fred@bloggs.com who’s sending an email to mike@verygoodemail.com.

A email header is read from the body of the email (i.e. the main content) and upwards to the Return-Path.

In this example the email flow is as follows:

zimbra003.verygoodemail.com (email client) -> smtp002.apm-internet.net (the sending Mail Transfer Agent (MTA)) -> relay001.apm-internet.net (the receiving MTA) -> as001.apm-internet.net (an anti-spam server) -> mail004.apm-internet.net (the mail storage server).

So let’s have a closer look at the header…

Return-Path: <fred@bloggs.com>

The “Return-Path:” above shows where to send the email if replied to.

* If someone is sending ‘on behalf of’ the email header might also contain a “Reply-To:” entry in the client part of the header that is different from the Return-Path.

* A bounce message would have a empty “Return-Path:” entry.

Received: (qmail 25563 invoked from network); 5 Aug 2013 09:41:47 -0000
Received: from as001.apm-internet.net (
by mail004.apm-internet.net with SMTP; 5 Aug 2013 09:41:47 -0000
Received: (qmail 46287 invoked from network); 5 Aug 2013 09:41:44 -0000

The above shows the message flow and illustrates that the email has gone from anti-spam server as001.apm-internet.net to mail storage server mail004.apm-internet.net.

X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on
X-Spam-Score: -30.0
*  -30 APM_SMTP_SERVER Local APM SMTP Server
X-Spam-Relay-Country: GB GB GB XXIf you have anti-spam enabled, your email header will contain the outcome of the Spam-Assassin test(s).

The X-Spam-Score is the result of all overall tests.  In this case the message was sent using our servers so it scored very low and was not flagged as spam.

If a message is flagged as spam it will contain a flag saying  “X-Spam: Yes”

It also mentions that the Mail Transfer Agent (MTA server) origin of the email (X-Spam-Relay-Country:) was in the UK. In addition, as it was a “sane/clean” email no other tests were triggered.

Received: from relay001.apm-internet.net (
by as001.apm-internet.net with SMTP; 5 Aug 2013 09:41:44 -0000
Received: (qmail 23379 invoked from network); 5 Aug 2013 09:41:43 -0000
Received: from smtp002-out.apm-internet.net (HELO smtp002.apm-internet.net) (
by relay001.apm-internet.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 5 Aug 2013 09:41:44 -0000
Received-SPF: none (relay001.apm-internet.net: domain at bloggs.com does not designate permitted sender hosts)
Received: (qmail 81965 invoked from network); 5 Aug 2013 09:41:42 -0000
X-AV-Scan: clean
Received: from unknown (HELO zimbra003.verygoodemail.com) (
by smtp002.apm-internet.net with SMTP; 5 Aug 2013 09:41:42 -0000

This section above shows how the email travelled from zimbra003.verygoodemail.com to as001.apm-internet.net

Worth noticing is the entry that says:

Received-SPF: none (relay001.apm-internet.net: domain at bloggs.com does not designate permitted sender hosts)

Which means that the Sender Policy Framework (SPF) record for bloggs.com does not allow to send through the servers used – hence the test failed.

Using SPF records is one method to protect your domain from unauthorised usage (i.e. if someone sends spam pretending to be from yourself).

Now to the client generated part of the header:

Date: Mon, 5 Aug 2013 10:41:42 +0100 (BST)
From: Fred Bloggs <fred@bloggs.com>
To: mike@verygoodemail.com
Message-ID: <1787290557.4335337.1375695702973.JavaMail.root@bloggs.com>
Subject: A test email!
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
X-Mailer: Zimbra 8.0.2_GA_5569 (ZimbraWebClient – FF22 (Mac)/8.0.2_GA_5569)

Usually the email client generated part of header is correct and reflects the from/to addresses an email was sent. But that’s not always the case.: a common method used by spammers, for instance, is to fake both sender/recipient and other entries.

Further entries are email client that was used (X-Mailer) and an interesting detail a lot clients/MTA’s add. The X-Originating-IP: [] which shows where the sending client was connecting from.

Further info on Sender Policy Framework (SPF) can be found at http://www.openspf.org/

That’s about it when it comes to headers. If you’re having problems with your email service – we can help!