How to Read Email Headers

1. The Basics
2. Master Class
3. Using Headers to Troubleshoot

1.1. What are email headers?

Email headers are structured information about your email message.  Basically, they're everything that isn't the message content or attachments.  Not every message will have the same headers, because anyone can add their own header to a message.  But, commonly, a message should always include:

  • From
  • To
  • Subject
  • Date
  • Message-ID
  • One or more Received headers

1.2. How can I see the headers of a message?

Full headers let you see the complete path that a message took to get to you. The full headers can be used to see why a message was delayed (or at least where it was delayed), and can provide details to solve many other problems.

Gmail: Click on the down arrow, next to the Reply button, at the top right corner of the message. Select "Show original". 

Hotmail: Click on the down arrow, next to the Reply button, at the top right corner of the message. Select "View Message Source".

Yahoo!: At the bottom right corner of the message, click the link for "Full Headers". 

Outlook 2010: Open the email in a separate window.  Click the "File" tab.  Select the Properties button.  They are in the Internet Headers box.

Outlook 2007: Click on the small arrow to the right of Options. They are in the Internet headers box.

Outlook 2003: Right clicking on the message from your mailbox and select Options. They are in the Internet Headers box.

Webmail: Open the message for the header you would like to view > Click the 'More' drop down box in the top right of the message > Click 'Show Raw Message'.  

Thunderbird: Click View > Message Source.

Mac Mail.app: Click View->Message->Full Headers, or Shift-Command-H.

Microsoft Exchange: Click on File->Properties->Internet.

Eudora Pro: Go to the toolbar just above the message, and click the button that reads "blah blah blah".

AOL Mail: Right click on the message, then select "View Message Source".

Mutt: Hit "h".

Pegasus E-mail: press Ctrl-H. 

For instructions on how to forward a message as an attachment please visit https://www.greennet.org.uk/support/how-forward-email-attachment to find instructios for your mail client.

Instructions for forwar mail as an attachment on more recent versions of Outlook, visit https://www.godaddy.com/help/outlook-2013-forward-email-messages-as-attachments-4822


1.3. What email headers does Pobox add?

Every server that handles your message adds some information to the message headers.  At a minimum, it will add a Received: header, which indicates when and how it handled the message.  But it can also add other information. 

At Pobox, we add several headers.  They show you the information we used to spam filter the message, indicate why we took an action on a message if we filtered it, and help us debug problems.  Every message Pobox handles will have the following headers added (in addition to the Received headers which show the servers that handled the message):

  • X-Pobox-Client-Address and X-Pobox-Client-Name: the IP address and the name of the server that sent us the message; this is what is checked by most of our spam filters
  • X-Pobox-Client-HELO: the name that the sending server claimed as its own, if any; used by a few spam filters
  • X-Pobox-Original-Sender: We change (SRS rewrite) the envelope sender of messages to comply with SPF and Domain Keys.  This is the envelope sender as it came in to us.

Messages that are sent from Trusted Senders will also have the following header:

X-Pobox-Pass: <email address> is whitelisted

Messages that are sent to Pobox Plus and Mailstore accounts with filters will also see the following headers:

X-Pobox-Filter-Version: 3.1

Messages that are actually filtered will also have these headers:

  • X-Pobox-Spam-To: <address that received the message>
  • X-Pobox-Spam-From: <envelope sender>
  • X-Pobox-Spam-Disposition: <what action did we take>
  • X-Pobox-Spam-Reason: <why did we take it>
  • X-Pobox-Filter-Match: <information about filter matches>

Messages sent to Mailstore accounts will have:

  • X-Icg-Account-ID: the account ID of the account that received the message

 

1.4. What are Received: headers?

Received: headers show the path that a message takes from the message sender to the final recipient. They are read in reverse order, so the Received: header at the top of the message is the one that delivered the message to you, and the last one shown should be the one where it left the sender.

Received headers must include at least one entry for every server that handled a message. However, spammers will also sometimes forge additional Received headers, before they send the message, to make it look like the message originated somewhere else.

 


2.1. The elements of a Received: header

The structure of a Received: header is

  • Received: from
  • the name the sending computer gave for itself (the name associated with that computer's IP address [its IP address])
  • by
  • the receiving computer's name (the software that computer uses) (usually Sendmail, qmail or Postfix)
  • with protocol (usually SMTP, ESMTP or ESMTPS)
  • id id assigned by local computer for logging;
  • timestamp (usually given in the computer's localtime; see below for how you can convert these all to your time)

The elements in bold are the literal words in the header.  Items in italics are the bits that change from header to header.  The underlined elements are the ones that can be manipulated by spammers and scammers.

Received: headers are recorded any time a message is handed between two computers. So, for any pair of Received headers, the sending computer of the first line should always match the receiving computer of the second line.  The newest Received: header is always added to the top of the headers, so reading headers from top to bottom traces the message from you back to the sender.

Let's look at an example.  Here's a message being sent from someone's iPhone, through their Gmail  account, to a Pobox Mailstore account.  (Note: Normal Received headers are not numbered.  I added those to help in tracing the message.)

    1. Received:     from maroon.pobox.com (maroon.pobox.com [208.72.237.40]) by mailstore.pobox.com 
(Postfix) with ESMTP id 847989746 for <address>; Wed, 15 Jun 2011 10:42:09 -0400 (EDT)
    2. Received:     from maroon.pobox.com (localhost [127.0.0.1]) by maroon.pobox.com (Postfix) with
ESMTP id EA14340A31F; Wed, 15 Jun 2011 10:42:35 -0400 (EDT)
    3. Received:     from mail-qw0-f46.google.com (mail-qw0-f46.google.com [209.85.216.46]) by
maroon.pobox.com (Postfix) with ESMTPS id 70BCC40A1DB for <address>; Wed, 15 Jun 2011
10:42:13 -0400 (EDT)
    4. Received:     by qwk3 with SMTP id 3so281681qwk.33 for <address>; Wed, 15 Jun 2011
07:42:11 -0700 (PDT)
    5. Received:     by 10.229.78.96 with SMTP id j32mr509819qck.121.1308148929825; Wed, 15
Jun 2011 07:42:09 -0700 (PDT)
    6. Received:     from [10.231.252.223] (79.sub-174-252-72.myvzw.com [174.252.72.79]) by
mx.google.com with ESMTPS id m16sm345129qck.28.2011.06.15.07.42.02
(version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Jun 2011 07:42:08 -0700 (PDT)

 Starting at the top:

  1. A Pobox mailserver (maroon.pobox.com) sent the message to mailstore.pobox.com, which is where I picked it up to read it.
  2. Pobox sent the message internally.  This is the step where message filtering happens.
  3. Google (mail-qw0-f46.google.com) sent the message to Pobox.
  4. Google handles the message internally.
  5. Google handles the message internally.
  6. A Verizon server (79.sub-174-252-72.myvzw.com) hands the message to Google.

So, the message starts at Verizon, proceeds through various internal processes at Google and Pobox, then ends up in my Inbox at mailstore!


A note about encryption and the protocols mentioned in the Received: header:

  • SMTP and ESMTP indicate the mail was sent unencrypted between the two servers mentioned. This may be across an internal or private network, but across the Internet it may be cause for concern.
  • ESMTPS indicates that the mail was sent after the two servers mentioned established an encrypted TLS link using the STARTTLS command. This can provide protection from tampering and eavesdropping of the mail.

Finally, Received: headers can themselves be tampered with so we can only be really certain of the protocol with which mails are delivered to Pobox, rather than its whole journey.

2.2. Why do so many headers start with X-?

Any computer that handles a message is allowed to append its own headers.  By convention, if a system wants to add its own custom header, it starts with X-.  This is so they can be sure their custom headers don't accidentally take the name of any defined header, current or future.

 

2.3. What is an envelope sender?

An email has two addresses associated with sending it: the envelope sender, and the From: address.  The envelope sender is where computers should respond (in the case of bounce messages or errors); the From: address is where people should respond.  In most cases, the envelope sender and the From: address match.  But they don't always, and they don't have to.

In terms of how it is sent, email is like a package.  On the box (that is, during the SMTP transaction), I specify where I want the package sent, and where it should be returned if it could not be delivered. 

If this were personal mail, these things would nearly always match -- if you got a package addressed to you, with your Aunt Martha's return address, the card inside the box is almost certainly going to addressed to you, from Aunt Martha.  In personal email, the envelope sender (the return address) nearly always matches the From: header.

Things are a little different from a corporation.  If you got a box from Amazon, it might be something you ordered. Amazon might have one return address that they use for packages that are undelivered (the return address on the outside of the box), but inside the box, they might ask you to make returns to a different address.  Or, it might be a gift that someone bought for you from Amazon.  Amazon shipped it, but the package is really from Aunt Martha.  With email, There are similar legitimate reasons why a envelope sender might not match the From: header, like a mailing list or a company that does automated bounce processing.

Unfortunately, this is a "feature" of email that spammers and scammers can and do abuse.  When you get a message picked up as spam that's "from" PayPal, or your bank, or another trusted institution, they've generally changed the From: address to be at a domain you recognize, while leaving the envelope sender as something they control.

2.4. What is SMTP?

SMTP stands for Simple Mail Transport Protocol.  It is the method that computers connected to the Internet use to send email.  (Your "Outgoing Mail" settings in your email program can also be referred to as your SMTP settings.)  It is also the method that servers use to transfer email between them.

SMTP transactions typically have 4 parts:

  • HELO, where the computers talking identify themselves
  • MAIL FROM, the envelope sender of the message is given
  • RCPT TO, the address or addresses that the message will be sent to 
  • DATA, the actual message (which also has all the message headers, including From: and To:)

 Many spam filters, including most of Pobox's, run after HELO, MAIL FROM and RCPT TO, but before DATA.  That's because, once you accept the DATA, you can no longer bounce the message.  That is why any filters that run on the message content, including filters you set up yourself, cannot bounce mail.

2.5. SPF, SRS rewriting and how it affects forwarding email

SPF stands for Sender Policy Framework.  It is an authentication check on the envelope sender.  That is: it asks, "Is this computer allowed to send mail from this address/domain?"  It is not a reputation check; it is just supposed to prevent or reduce the likelihood that a message is forged.

What does this mean for email forwarding?  Well, a lot, actually!  When Pobox forwards mail to your forwarding address, your ISP may do an SPF lookup.  If the domain that the message came from published an SPF record, our servers definitely wouldn't be in it!  So, if we forwarded the message using the original envelope sender, the mail we are forwarding to you could get rejected. 

Instead, we SRS rewrite the envelope sender, so that it will come from @pobox.com.  Basically, that means that we take the original sender address, and (with some modifications) make that the username portion of an email address @pobox.com.  That way, the SPF lookup your ISP will do is on @pobox.com, instead of the domain of the sender.   But, if your ISP rejects the message for another reason, like your account being over quota, we can still reverse the address, and send the bounce message back to the original message sender.

 

 

2.6. About forging Received: headers

If you've ever been phished, or "spammed yourself", you know how easily spammers can forge the From: headers.  If you've ever gotten a message "cc'ed to" a whole bunch of addresses, which doesn't include yours, you know that To: and CC: headers can be forged, or used to obscure who's actually getting the message.

Forging Received headers is a little different.  You see, From or To, you can totally obliterate where the message actually came from, or where it's actually going to.  With Received headers, you can't get rid of the real ones.  But you can add fake ones.  

Fake Received: headers must be the "oldest" Received headers -- on the message before any real Received: headers are added.  Since Received: headers are read from newest to oldest, with the newest at the top, that means fake headers are at the bottom.

So, how can you tell which Received: headers are real, and which are fake?  Generally speaking, they're always real.  But, Received: headers should  reflect a series of handoffs; if you see a mismatch, that can also be an indication of a forgery.  (See our page on the elements of a Received: header for more details.)  Or, if a header is from something a little too straightforward, like google.com, it could also raise suspicions.

 

2.7. How to read email timestamps (date and time entries)

Dates and times in message headers are, almost always, given in the localtime for the computer that wrote the header.  So, the Date header on a message will be the localtime where the message was sent, not where it was received.  Received: headers are timestamped local to the computer that handled them.  So, how can you tell when it was actually handled, in your own local time?

Email timestamps use the following format:

  • abbreviated day of the week,
  • day of the month
  • abbreviated month
  • year
  • hour (in 24 hour time)
  • minute
  • second
  • offset from Greenwich Mean Time
  • abbreviation for timezone

Here's a pair of timestamps from a message I got recently:

Thu,  9 Jun 2011 13:35:55 -0400 (EDT)
Thu, 9 Jun 2011 10:35:50 -0700 (PDT)

Without the last 2 elements, you might say, "What?! Why did this message take 3 hours to deliver?!?"  However, the last 2 elements indicate where the messages were when they got timestamped.  The first line was written in Philadelphia, during Eastern Daylight Time (EDT).  The second line was written in California, during Pacific Daylight Time (PDT). 

That might be enough information if you live in the United States, but if you don't, or the message was handled in a part of the world where you aren't familiar with their timezone abbreviations, what can you do?  That's where the offset from Greenwich Mean Time comes in!  Greenwich Mean Time (or GMT) is also known as UTC, or Coordinated Universal Time, and it is the Internet standard for time.  All timezones are also indicated in email as their offset from GMT.  

So, in the examples above, -0400 indicates 4 hours after GMT and -0700 indicates 7 hours after GMT.  If the message was sent from, say, New South Wales, the offset would be +1000, or 10 hours before GMT.   Using this structure, you could convert all the timestamps in a message to GMT, if you wanted to.  That would make the first timestamp 17:35:55 in GMT, and the second one .... 17:35:50!  So, that message actually took 5 seconds to process, not 3 hours and 5 seconds.

 

 


3.1. Why was this message held as spam?

All messages released from the Spam section will include a header, indicating why we held the message.  The information is in the X-Pobox-Antispam header.

A list of currently active reasons is:

country/XX returned deny (where XX is the two letter country code for the country that sent the message to us)

dnsbl/XX returned deny (where XX is the URL for the blacklist which contained the IP address that sent the message to us)

rhsbl/XX returned deny (where XX is the URL for the blacklist which contained the domain name that sent the message to us)

broadband/ returned deny (the IP that sent the mail looks like consumer broadband; these are primarily spambots running on compromised computers)

require_ptr/ returned deny (the sending IP address did not have a PTR record)

cloudmark/ returned deny (the message contained content currently found in the cloudmark spam filter)

fake_pobox_address/ returned deny (the message sender is an address that is not active in the Pobox system)

filter/ returned deny: user email filter (for messages discarded by your Email Filters)

check_infwds/ returned deny: you have told us you are forwarding mail from another domain; we checked the IP that sent the mail to that domain, instead of the IP that sent mail to us.

3.2. Why wasn't this message held as spam?

The most common reason that a message isn't held as spam is, spammers are constantly coming up with new and inventive ways to evade spam filters.  But, there are a couple of things you can check for in the headers.

1. Was the message sent to your Pobox address?  If it doesn't include an X-Pobox-Delivery-Id: or X-Icg-Account-Id: header, then we didn't handle it.  You'll need to talk you your ISP about why the message wasn't caught.

2. Was the message whitelisted?  Look for an X-Pobox-Pass: header, to see if the message's sender has somehow made it onto your Trusted Sender list.

Beyond that, we recommend checking your Spam settings.  Our recommended level of spam protection, if your account has been active for more than two weeks (and you've been actively reviewing your Spam section) is Aggressive.  Also, consider turning on by-country blacklists.  If you don't have any correspondents who live on a certain continent, you could take a bite out of your spam by blocking all mail from that contintent.

 

 

 

3.3. Why did this message take so long to arrive?

Received: headers are a great place to start to figure out why a message was delayed.  Only the computer that delayed it will have logs and information about the cause of the delay, but Received: headers can help you pinpoint which computer it is.

Let's look at an example, that took about 2 minutes and 20 seconds to deliver:


    1. Received:     by lab.pobox.com (Postfix, from userid 1004) id 820C52E7B3; Mon, 13 Jun 2011 08:15:57 -0400 (EDT)
    2. Received:     from a-icg-mx-sd.icgroup.com (a-icg-mx-sd.icgroup.com [64.74.157.117]) by lab.pobox.com (Postfix) with ESMTP id 8D5212E7B1 for <address>; Mon, 13 Jun 2011 08:15:56 -0400 (EDT)
    3. Received:     by a-icg-mx-sd.icgroup.com (Postfix) id 90A38381F; Mon, 13 Jun 2011 08:15:53 -0400 (EDT)
    4. Received:     from ironport01.ktbenefits.com (ironport.ktbenefits.com [71.244.104.36]) by a-icg-mx-sd.icgroup.com (Postfix) with ESMTP id 71E34381E for <address>; Mon, 13 Jun 2011 08:15:53 -0400 (EDT)
    5. Received:     from unknown (HELO mail.ktbenefits.com) ([172.19.1.1]) by ironport01.ktbenefits.com with ESMTP; 13 Jun 2011 08:13:42 -0400
    6. Received:     from ktb-berwyn02.ktb.local ([172.19.1.11]) by mail.ktbenefits.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jun 2011 08:13:42 -0400

Looking at the headers, the big delay is between 4 and 5 -- from 08:13:42 to 08:15:53, or the entire 2 minutes.  Once the message is handed off to icgroup.com, the rest of the delivery takes about 4 seconds.  So, if we were concerned about why this message took 2 minutes, we would have to contact ktbenefits.com, to have their administrator check the mail logs for the reason.  (Of course, keep in mind that for anything under 5 minutes, the "reason" is likely to be "sometimes it just takes a couple of minutes."  Most delays under 10 or 15 minutes do not have a logged cause.)

When reviewing Received: headers, don't forget that timestamps show the local time of the computer that handled it, not your local time.  So, if a message goes from the East Coast to the West Coast, or vice versa, you'll see a 3 hour difference in the logs. 

3.4. I'm getting 2 copies of every message. Who is duplicating it?

When you get multiple copies of an email message, the easiest way to find out who is duplicating it is to look for when the headers start to change.

If the two messages have different Message-ID headers, then the duplication is happening on the sender's computer.  It could be that they accidentally sent it twice, or that their computer lost its connection to the Internet while sending, and the program sent it twice on their behalf.

If the two messages have the same Message-ID header, though, then you should start looking at the Received: headers.  Specifically, start checking the logging ID.  For example, in the Received: header below, the logging ID is 8D5212E7B1.

    Received:     from a-icg-mx-sd.icgroup.com (a-icg-mx-sd.icgroup.com [64.74.157.117]) by lab.pobox.com 
(Postfix)with ESMTP id 8D5212E7B1 for <address>; Mon, 13 Jun 2011 08:15:26 -0400 (EDT)

 Every logging ID is unique for a message.  So, when reviewing Received: headers, if the logging ID matches, that means your two messages were one when they passed through that machine.  The first Received header:, as read from top to bottom, where the logging ID is same is the computer that caused the second copy.  They should also have logs that indicate why or how the message was duplicated.