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:
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
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):
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:
Messages that are actually filtered will also have these headers:
Messages sent to Mailstore accounts will have:
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.
The structure of a Received: header is
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 [184.108.40.206]) 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 [220.127.116.11]) 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 [18.104.22.168]) 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:
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:
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.
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.
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.
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:
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.
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.
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.
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:
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.
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.
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.
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 [22.214.171.124]) 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 [126.96.36.199]) 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.
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 [188.8.131.52]) 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.