Technology in terms you understand. Sign up for the Confident Computing newsletter for weekly solutions to make your life easier. Click here and get The Ask Leo! Guide to Staying Safe on the Internet — FREE Edition as my thank you for subscribing!

Email Headers Revealed and How They Might Help You

I often refer to the “headers you don’t normally see” when talking about email, how your email gets routed to your email account, how it lands or doesn’t land in spam filters, and how it ultimately makes its way to you.

I think you’d be surprised at how much information accompanies each email message to accomplish those tasks.

I can’t explain them all, but I think it’ll be helpful to review where to find them and what the most useful ones might mean – particularly when it comes to trying to diagnose spam, or understand unexpected delays.

I will warn you: this isn’t for the faint of heart. Email headers are both complex and geeky.

Become a Patron of Ask Leo! and go ad-free!


So-called “email headers” included (but typically not displayed) in email messages contain additional information about the message’s source, validity, and path from sender to recipient. Most email programs have a mechanism to view the original message source to expose all headers. “Received:” headers are often of greatest interest, as they show the servers handling the message along its way.

An example message

An example email in
An example email in (Click for larger image.)

Let’s examine this example message in more detail.

It’s a simple two-line message with an attachment sent from a Gmail account ( directly to a Hotmail account (, and viewed in the web interface.

It seems simple — on the outside, anyway.

The headers you see

First, let’s address the information you can see without any additional steps. Even though isn’t displaying them in “header format” (which I’ll explain later), I’ll list them here that way exactly as they appear in the email message source, which we’ll view in a moment.

Immediately visible are:

  • From: AskLeo Test <>

In the message list in the top pane, shows us only the “display name”, which is “AskLeo Test”. In the message preview pane below, however, both display name and email address are displayed.

  • Subject: A test message for us to use

The subject appears in both the message list (followed by the first part of the message body) and the header to the message preview pane.

  • Date: Mon, 14 Sep 2020 13:19:29 -0700

As we’ll see shortly, the date can be represented several ways. displays it in your local format in both the message list and preview pane.

  • To:

I find it a little funny that is not displaying the email address the message was sent to, other than to say “you” in the preview pane. It assumes you know who “you” is, and what your own email address is.

Not present in this example is the “Cc:” header listing additional recipients to the email. (The “Bcc:” header is not included when email is sent.)

Viewing the hidden headers

In order to view all the geeky details of a message, we need to examine the original source of the message. (and most email programs) show us a sanitized, easy-to-consume version of the header information. There’s much, much more.

In, right-click the message in the message list in the top pane, and click on View message source.

View message source option
“View message source” option. (Click for larger image.)

This will bring up a small window containing the actual source of the email message as received by your email service.

Message Source
Message source. (Click for larger image.)
Full Message Source (Image)
Full message source. (Click for larger image.)

It’s much longer than the box displays and includes a scrollbar to the right. You may prefer to select the message and copy/paste it to a text editing program like Notepad that you can resize to be larger. As you can see by the extremely reduced image to the right, the actual source of our “simple” message is quite large: 798 lines, in fact. Click here to view or download the example message as a txt file.

I’ve used as the example here, but most — though not all — email programs and interfaces have some kind of “view source” or “view original” functionality. Gmail, for example, has “Show original”. The Mail program with Windows 10, on the other hand, does not appear to have the ability to view the original message.1

Once you have the entire message in some comfortable viewer, we can start to examine some of the specifics.

Header format

In order to understand where headers begin and end, and how multiple lines can combine to form a single email header, we need to understand the formatting rules.

Everything in the email source up to the first blank line is an email header.

Each header begins with some text followed by a colon and a space. For example, “From:<space>” begins a header.

Any line without space, or in which a space happens without a colon in front of it is a continuation of the preceding line. So:

From: AskLeo Test

Would be considered one header, and would be treated just like:

From: AskLeo Test <>

Each header ends when the next header is identified, or by a blank line, which signals the beginning of the message body.

A word about “multipart”

Somewhere in most messages (line 55 in our example) there may be a line similar to this:

Content-Type: multipart/mixed; boundary=”00000000000014489905af4bc141″

This is an example of a hidden header.

“Content-Type:” indicates a header with information about the type of content the message contains. In our example, it has multiple parts (“multipart”), and they are of “mixed” types. The boundary between the types is that long random-looking string: “00000000000014489905af4bc141”. (While a message need not be multipart, most are these days.)

If you search for that random-looking string, you’ll find it occurs a couple of times later:


Starting with a two hyphens, this indicates a boundary between parts.

At the very end of the message you’ll find:


Starting and ending with two hyphens this indicates the end of all parts.

Our message contains two parts:


The message body, which itself is another multi-part message with its own internal Content-Type: header and boundaries (note that the random-looking string is different). Its two parts are a plain text and HTML versions of the message text.


The attachment, a PNG file.


This indicates there are no more parts.

It’s the attachment which makes up most of the 798 lines in the message. The email protocol was never designed to handle binary data directly, so attachments (including in-line images) are encoded as text and included as one of the multiple parts of the message.

The headers we know

With that out of the way, use the search function in whatever you’re using to view the message source to search for “From: “. Near the “From:” header you’ll also find headers we’ve already discussed — Date:, Subject:, To:, and Content-Type: — plus one more:

From: AskLeo Test <>
Date: Mon, 14 Sep 2020 13:19:29 -0700
Message-ID: <>
Subject: A test message for us to use
Content-Type: multipart/mixed; boundary=”00000000000014489905af4bc141″

“Message-ID:” is some kind of ID string that uniquely identifies this message to the sending mail service (in this case,

You’ll see, though, these headers — which from our perspective are the most important headers, since they define sender, recipient, and subject — are buried in the middle of a bunch of other gobbledygook.

They’re buried in all the other hidden-to-us headers.

And now you can see why all the gobbledygook is hidden. Smile

Headers we’ll (mostly) ignore

Headers beginning with “X-” are generally extensions to the standard headers we’ll talk about below. If you review the headers in our example, you’ll see many that are clearly unique to Google or Microsoft, apparently used for their internal tracking. Others are an informal industry standard, but are not necessarily required. They may contain interesting information, or they may contain something completely unintelligible to you and me.

For the most part, we’ll ignore X- headers, with two exceptions. I want to address this because it’s often why people go digging into headers in the first place.


This is the IP address of the sending server. In this case, the IP address maps to one of Google’s mail servers: Not surprising, since the message was sent using Gmail.


When present, this is the IP address of the computer that originated the message. You’ll see it’s not present in our message. In fact, the IP address of the location from which I sent this message, is not present at all. This is common, and most frustrating for people trying to find the IP address of the person, not the server, who sent them a message. That information is rarely available.

Routing headers

The “Received:” headers document the server-to-server path the email message took on its way from sender to recipient. Each server adds a “Received:” header to the top of the message with various pieces of information (some of which are optional).

  • The name and/or IP address of the mail server or program sending the message
  • The name and/or IP address of the mail server receiving the message
  • The email address of the message’s destination
  • The date and time
  • Additional encoding and transport information

As you view a messages’ source, starting at the From: line and working upwards, you’ll find one or more “Received:” headers. Returning to our example:

  • Received: by with SMTP id x23so1225329wmi.3 for <>; Mon, 14 Sep 2020 13:19:43 -0700 (PDT)

This line indicates the message was received first by Google’s server for, at 1:19:43 PM Pacific Daylight Time on September 14, 2020. This is the first server in the chain, and where the message began, presumably receiving the message from the Gmail web interface.

  • Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16 via Frontend Transport; Mon, 14 Sep 2020 20:19:43 +0000

The message was then received by Microsoft’s server ( from Google’s server ( at 8:19:43 PM UTC on September 14, 2020. This represents the hop from Google’s server to Microsoft’s. Note the time notation has switched from local time (Pacific Daylight Time or “-7 hours”) to UTC (aka Greenwich time). It doesn’t matter which is used, as long as the time zone indicator (-0700 or +0000 in this example) is present.

  • Received: from (2a01:111:e400:fc11::40) by  (2a01:111:e400:fc11::293) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Mon, 14 Sep 2020 20:19:43 +0000

The message then went on to be received by Microsoft’s from Microsoft’s at 8:19:43 PM UTC on September 14, 2020.

  • Received: from (2603:10b6:300:103::20) by with HTTPS via MWHPR12CA0058.NAMPRD12.PROD.OUTLOOK.COM; Mon, 14 Sep 2020 20:19:44 +0000

The message was finally received by Microsoft’s from at 8:19:44 PM UTC on September 14, 2020.

It’s not at all uncommon for a message to be passed along several servers, even within the same organization, as it makes its way from sender to recipient.

Routing headers can be used in a several interesting ways:

  • Ensuring email came from where it claims to have. For example, if an email “From:” a Gmail address never touched a Google server, that’s suspicious.
  • Ensuring the chain of servers is complete. If a server magically appears mid-list sending a message it technically never received, that’s suspicious.
  • Diagnosing delays. Our message took a second or two to hop from server to server to server. If there’s a delay, however, you’ll see where in the chain that delay may have happened.

Headers and spam

Diagnosing the chain of servers handling the mail is certainly one interesting tidbit of data that spam filters can use, but much more information has been added in recent years to aid in its detection and prevention.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025;

This is an example of a DKIM (Domain Keys Identified Mail) header. DKIM uses a cryptographic signature to confirm email claiming to have been send by a specific domain — in our example for — has actually been sent by that domain.

Received-SPF: Pass ( domain of designates as permitted sender);

This is information relating to SPF (Sender Policy Framework). SPF uses entries in the DNS system (the same system that maps domain names like to IP addresses) to indicate which servers are authorized to send email for specific domains. In the example above, the server at is officially specified as being allowed to send email on behalf of

Exactly how the information provided by DKIM and SPF is used is ultimately up to the receiving email system. They can be ignored, treated as “advisory”, or taken as absolute indications of a message’s validity. Unfortunately, the latter is difficult at best, because of slow or inconsistent adoption. Most systems at least treat the information as an advisory data point when considering whether or not a message should be considered spam.

So. Much. More.

You can see from the number of headers in our “simple” email that we’ve only touched the tip of the iceberg. Not only may vender-specific entries be present, but mailing list software, remailers, and just about any software interested in sending email can add their own headers to carry along otherwise hidden information.

Hopefully, the information above will help explain the most common and the most useful.

Do this

Subscribe to Confident Computing! Less frustration and more confidence, solutions, answers, and tips in your inbox every week.

I'll see you there!

Podcast audio


Footnotes & References

1: It was my hope to use it in this article, but not being able to show the source is why I ended up using instead.

6 comments on “Email Headers Revealed and How They Might Help You”

  1. I get almost no email in my Gmail with spam label. Is that because Google is so sure that an email is spam, it discards it without adding it to my received emails? Could this have something to do with using the DKIM and SPF header information to identify spam?

    • So you’re saying your spam folder is mostly empty? Mine’s mostly full. :-)

      While I’m sure that DKIM and SPF help, I wouldn’t cite that as the major cause. For whatever reason you probably just get less spam.

  2. Wow. That is, by far and away, the L-O-N-G-E-S-T set of mail headers I have EVER se een!!! Yeesh!

    I’m a hobbyist who occasionally goes online with a Commodore-128 computer (in “64” mode) , and for that purpose I have an ISP which provides me with a Unix shell account with Unix Alpine v2.11 as the mail program. Not only does Alpine allow me to read full E-Mail headers, it actually allows me to invent my own!

    For example, anyone viewing the full headers on such an E-Mail would see (among others):

    X-Computer: “Commodore 64 BASIC v2 : 64K RAM System : 38911 BASIC Bytes Free”

    …which any C64 user will recognize immediately as the C64’s startup message.

    It’s only too bad that so few peop!e view full headers, LOL! :)

  3. Thanks for a terrific article.

    For years I have occasionally used email headers/full text to validate or reject questionable messages. And, I’ve grown frustrated as the size of the headers has grown exponentially. You manage to cut through the fog, and do so in clear, readable prose. And you have a fine sense of when to give people a top level sense of what an item is, without being drawn into the muck (for example DKIM.)

    This article is now in my ‘keep handy as you will be using it soon” folder.

    (And you probably get so much spam as there are miscreants out there that would find you a personal challenge.)


Leave a reply:

Before commenting please:

  • Read the article.
  • Comment on the article.
  • No personal information.
  • No spam.

Comments violating those rules will be removed. Comments that don't add value will be removed, including off-topic or content-free comments, or comments that look even a little bit like spam. All comments containing links and certain keywords will be moderated before publication.

I want comments to be valuable for everyone, including those who come later and take the time to read.