How to read an Email Header
1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 5.00 out of 5)
Loading...

How to read an Email Header

Not sure if an email is legitimate? Check the email header!

Hey friends! There is some unfinished business in my blog series about email security and verification. This topic was considered during that timeframe but seemed to be too technical. However, in recent times, there has been some need to review and explain what and why to some co-workers, so I figure I’ll write an article that all my co-workers will read with vigor and retain the information I’m trying to convey.

The topic? Email headers. The reason? Further identification of spam and phishing attacks. It also is extremely important for one recommendation that I have mentioned on a few different occasions: Scrutinize. Always report. Jump through the hoops. Stop the bad guys. Slay the dragon. Profit (Queue Steve Nash).

Email headers are sort of the paper trail (and more) that is attached to each email and shows the actual source, hops and how it ended. It also has certain things such as ‘Return Path’, Spam Score, DKIM Public signature, and various other tidbits. We’ll go over most of it, but the takeaway should be to have further confidence if email is spam or legitimate and the path it took to get to you. Let us hash this particular topic out.

Components of Email Headers

Email headers contain a lot of information and not just necessarily the logistical audit of who and how the email made it to the end user. Although, that information is very useful and provides insight into origin, path and potential security processes.

Some of the other things one may see in an email header:

  • Spam identification scores and thresholds to flag emails as spam which allow client spam filters to easily sort bad emails out of users’ inboxes.
  • There are fields that indicate a ‘Return Path’ which is essentially a bounce back address. Often, the return path is the sender’s email but it might make sense to have an email that will collect bounces and do something if there is high volume.
  • DKIM public key and results are also found right in the email headers which indicate if there was a pass/fail. What happens to a failed (or soft fail) message depends on the policy action set in the DNS record (See previous post about DKIM).
  • Some common information can also be found such as date/timestamps, MIME types, version, email format (HTML, plaintext), etc.

Dissecting a (Phishing) Email Header

Now that we have an idea of what an email header may or may not contain, let us now look at a bad email header and some of the flags that indicate it is, uh, bad.

So, this phishing email was found in my email client’s junk folder as it should be. I have moved it to my inbox to show what it would like in an inbox. By default, any email in my junk box is converted to plain text, so, I wanted to show the ripped off graphic that can be seen with HTML.

I’d also like to point out that not all mail comes from a Microsoft Exchange Server/Environment. Many do and while some of the stuff we’ll look at will be specific, other indicators and header information might come through regardless of the mail processing platform.

Suspicious from the get-go. I didn’t even have to look at the email headers to determine (obviously, because the email got flagged and the spam filter moved it out). But, let’s take a look at the email headers and see what makes this email so bad:

One thing to point out immediately is that we kinda need to read the header information upside down. That is, you start on the upsidedown (shout out to Stranger Things) and work your way to the top.

Much of what we’ll see is mail exchanges (relays) that simply help pass the message along but does no real scrutinization.

Look. The next few pages are arduous. This is kind of the last exit warning sign before a long bridge. But, instead of turning back, you can move forward, skip these next few pages and there is a good summary of which lines of the header to look at that will almost always help you scrutinize accurately.

Each line is numbered for easier reference.

  • Line 61: The value for ‘AuthAs’ is listed as ‘Anonymous’. Right here, this is a flag. We should be looking out for a value as ‘Internal’, ‘External’ or ‘Partner’. According to Microsoft, “If X-MS-Exchange-Organization-AuthAs is listed as “anonymous” or if it’s missing, this indicates an incorrect configuration or an incorrect mail route.”
  • Line 60: ‘AuthSource’ is the server that checked the authentication of the email for the email domain.  I happen to know that domain = ‘mlsrvr.com’ is of RackSpace which is an email service provider.
  • Line 59: ‘Organization-SCL’ is the Spam Confidence Level (hence, SCL) is how that ‘AuthSource’ grades the message as spam. The scale is 0, which is clean, and 9, which is bad. Basically, this is a very computer-y way of saying 1-10. The value here is ‘5’.  Doing the math, er, basic counting, this errs to the side of bad. It is certainly not absolute or nearing absolute, but it is certainly leaning to bad. In my mind, this is a flag. Note: a value of -1 means that it was not analyzed here because the value of ‘AuthAs’ was ‘Internal’. This could certainly be considered a flaw that would be very difficult to exploit.
  • Line 57 – 58: This is a combo line that just states the method of the AV scanning on the server side. Standard and nothing indicative here.
  • Line 56: The ‘Network-Message-ID’ is a unique hash that sort of serializes the message. Standard and nothing indicative here.
  • Line 55: Here’s a flag, alright. Simply labeled ‘To’, the value here is ‘Undisclosed recipients:;’ That means the destination fields, ‘To’, ‘CC’, and ‘BCC’ have been gamed. For example, it can be done through GMail by typing ‘Undisclosed Recipients <emailaddress@emaildomain.com>’. The email was supposedly sent from Rackspace, a legitimate business, and they just don’t do that. This smells bad. If I didn’t already know better, I’m already questioning this.
  • Line 54: ‘X-Mailer’ is indicating what method was used to send the email. The value is listed as ‘Webmail/16.2.0-RC’. This is a little phishy in that RackSpace would likely not use WebMail to send the message as they are a mail service and have access to the “cleaner” backend of Exchange. Not a huge indicator typically but considering this is supposedly from RackSpace, it can be rightly scrutinized.
  • Line 53: ‘Message-ID’ is some unique hash from RackSpace. Nothing here.
  • Line 52: ‘Type’ is the format of the message. Most messages are HTML. This is fine.
  • Line 51: ‘Priority’ is just that: priority of message to be processed based on the mail service. Value of ‘3 (Normal)’ is, you guessed it, normal and standard. Nothing to see here. Moving along.
  • Line 50: ‘Importance’ is a flag set on the user end. It indicates if an email is of high or low importance. Nothing here detracts from the legitimacy of the message.
  • Line 48-49: ‘Content-Type’ specifies the kind of content that can be found in an email message. Many emails have the combination of HTML, Text, Image attachments, etc. Many emails have this combination of things so I would say that this is non-indicative.
  • Line 47: ‘MIME-Version’ has a value of ‘1.0’. Basically, indicates that the message was created in compliance with the standardized “email structure”. Also, clean.
  • Line 46: The value of the ‘From’ field here is quite indicative. The email address is listed as ‘noreply@mailbox-services.com’. A quick search on MXToolBox shows that RackSpace has no affiliation with that email domain. This is a red flag for me.
  • Line 45: ‘Subject’ can certainly be indicative. We’re looking for misspellings and bad grammar that most legitimate companies are very capable of keeping that clean. The subject here is a little wordy for a warning. I’m giving this verbiage, “We noticed an unusual sign in attempt from an unknown location”, a warning going on red flag.
  • Line 44: ‘Date’ and timestamp is pretty straightforward. Nothing here.
  • Line 43: ‘X-Auth-ID’ is a big one here. This field is stating the authentication ID for the email account. I almost always look for values like this (and/or ‘Return Path’ which is often the same address and/or ‘X-Sender-ID’ which is probably the most telling field) to tell me if this is a legitimate email. The value, ‘mbabauta@ibssguam.com’, screams fake. I took this a step further and looked up the domain of ‘ibssguam.com’. Just so you know, the site seems legit though it is literally a company based in Guam. This tells me that their account was hacked and is being used to send spam (poor Island Business Systems & Supplies of Guam….) In a real-world application, this ends my investigation. That’s about as much proof as I need. Reddest of red flags.
  • Line 40-42: ‘Received By’ is where the actual path starts being laid out. All the information before this is basically received/recorded/generated from this first ‘hop’. The value is ‘apps.rackspace.com’ which, as mentioned earlier, is Rackspace’s webmail address. The other values, on line 41, just reiterates the authenticated user and the from user. This also indicated a red flag, so it is telling.
  • Line 37-39: ‘Received From’ is kind of the extension of the previous line block. It also shows that ‘user from’ is of poor IBSSGuam email address. We know this is a red flag.
  • Line 34-36: ‘Received From’ here indicates a relay in the value field. This does not immediately jump out at me considering we are not sure of the path and it could potentially change depending on many factors of general internet routing.
  • Line 33: Much like line 43, this is what I am looking for. This is often the first thing I look for as this is all telling and basically seals the deal for me. The reason why this is more important is because this is the actual sending email address and not just the authentication that is seen on line 43. So, the display name for email might say ‘RackSpace Support’ but this field is hard (not impossible to spoof) and is not done often enough. For instance, it was not done here! Much like the value found in line 43, this is about as much proof as I need. Redder than the reddest of red flags (AKA bad).
  • Line 30 – 32: See info for line 34-36. This is for the outbound (SMTP), though. But the same principle can be applied. We don’t know the route. It can be traced but there is a lot of work that would have to go into that.
  • Line 27 – 29: See previous. Same thing (SMTP, too).
  • Line 23 – 26: See previous which makes you see previous heh. There is some added transport encryption information that doesn’t mean much to anyone at a glance.
  • Line 22: ‘Classification-ID’ is a random hash and this is another unsuspecting value. This does nothing for our scrutinization.
  • Line 21: ‘Suspicious-Flag’ is set to ‘No’ as the value. I am not sure what causes this flag to be set to ‘Yes’. But, I would have. With all its suspicion just suspicioning around….
  • Line 18 – 20: This is a very telling few lines right here. Welcome in our old friends SPF, DKIM, and DMARC. The MailFrom is still from our other friends selling printers in Guam. There are no DKIM signatures, no DMARC and the SPF is ‘Neutral’ which means there is referencing from the same domain as the receiver. In other words, the sending domain is in the same domain as the receiving domain (emailsrvr.com). My street smarts would tell me that if Rackspace were to send an email, they would pass SPF, DKIM and DMARC. Kinda important for them considering they do lots of email hosting. Red Flag.
  • Line 17: ‘Originating-IP’ can be telling if you do the research but at a glance, it doesn’t mean much. I’d be more interested in some of the other fields that were mentioned in the previous lines. At a glance, this is a fine. Note: For the record, this IP is from RackSpace so this would favor a “clean” message despite it being a, well, you know.
  • Line 16: ‘Orig-To’ is the destination email address. Nothing wrong here.
  • Line 15: ‘Virus-Scanned’ is referring to the email server scanning for a virus. The value of the filed is ‘OK’. There was no real virus on the email, per se, but I wouldn’t click on the link. That would seemingly be a digital petri dish of bad.
  • Line 14: ‘Spam-Flag’ is set to value ‘YES’. Boom. This field though makes a bit more sense by looking at the next few fields. Seemingly, this section would be best read in a different order. Red flag.
  • Line 13: ‘Precedence’ has value ‘junk’. It’s junk, aright. Right on the nose.
  • Line 12: ‘Spam-Score’ has a value of ‘100’. That is on a scale of 1 – 100. Guess which end is bad?
  • Line 11: ‘Spam-Threshold’ is basically the score that must be met in order for an email to be flagged as Spam. The value is set to ‘95’. I’m no mathematician but I’m 95% sure that 100 > 95. Threshold met. ‘Spam-Flag’ is set to ‘YES’.
  • Line 10: ‘Return-Path’ is a big one for me. Maybe one of the biggest flags, in my opinion. The ‘Return-Path’ is an email address that will is also called a ‘Bounce-Address.’ When an email address gets bounced, this is the email address that the bounce goes to. More often than not, this is the same address as the sender email address. So, here, we have that same sender address value which is mbabauta@ibssguam.com. This is telling to me.
  • Line 1 – 9: I’m condensing the last 9 lines into this last one which is basically 3 hops. Basically, from Rackspace and back to Rackspace. Nothing weird here.

ZZZZZZZZ…. Huh?! I’m Awake. I’m Awake….

Whew. We made it through. Look at all that red. A clean message will have very, very little if at all red. Let’s examine a clean message’s headers. Kidding.

The main point of this is that someone should be able to look at 1 or 2 things within an email’s headers and have a really good idea if there is shadiness surrounding an email.

The ‘Return-Path’, line 10, as mentioned, is a big one to me. Since it can be spoofed, it is not fool-proof. Often times, it is not spoofed so that is very indicative. In a sense, this can show the true originating email address. There are other fields that may indicate the true email address, such as the authentication, and that can appear different. Certainly, the display name can be spoofed so that should almost never be considered when starting the scrutinizing process.

Also, the results from things like SPF, DKIM and DMARC, line 18 – 20 is very telling. It all depends on the context. Seemingly, a legitimate entity will have their email security and verification processes tuned up so if there is failure or none at all, that is a red flag.

Finally, the spam flag and spam score, lines 14 and 12 respectively, is also a big indicator. This can and has produced false positives so I will often look at the other signs in order to determine an email’s legitimacy.

There a lot of other possible fields that one could find in an email header. So may be indicative and others may just be some metadata-ish type information that just help with organizing/tracing.

Finally, and as I have said over and over, and even wrote a post about it, use your best judgement. Understand your contacts, look for the obvious stuff, question any and all information that anyone is asking for. Businesses WILL NOT ask for certain sensitive information via email. Keep an eye out for other email header fields, try to understand the context and, of course, Happy Scrutinizing!

Email Security Best Practices - 2019 Edition

Don’t Get Phished.

Email is the most commonly exploited attack vector, costing organizations millions annually. And for SMBs, the damage can prove fatal: 60% fold within 6 months of falling victim to a cyber attack. Don’t be one of them.

4 comments
  • Ross.
    I started receiving lots of email that is spoofed with images having buried URLs waiting to be clicked on.
    All addressed to my gmail account which I no longer use for sending email but which forwards to my local ISP email account … to switch over to another email address at this point will be a lot of work since I have thousands of IDs set up in various personal accounts using gmail. Seems gmail email is out there on the dark web.
    I use MS Outlook as my mail system on my PC… so for me accessing/copying the email header is simple 1-2-3 as right clicking on the email sender in the inbox without having to open the email itself.
    The spoofed emails began several years ago all spoofed with images/ URLs. Sometimes laughable they are so obviously phony.
    A lot of the spoofed emails are duplicates … but coming from different origination points. The same email image sometimes may come in multiple times and from vastly different IP:locations.
    Life Insurance
    Medicare – important information for your open enrollment
    Cannabis oil
    Auto insurance
    Home warranty
    Weight loss miracle
    A few others.
    These “look” like innocent advertising but I doubt it. I can receive multiple emails with the exact same content / image but coming from wildly different source locations. So I wonder if the emails are somehow not revealing the original sources and are somehow being redirected / bounced all around the globe? Is that possible.
    I early on figured out how to read the header key information myself but now am using an automated website that analyzes the header and comes back with highlighting of the key information on sender, receiver, host provider and IP addresses. https://whatismyipaddress.com/trace-email If you are interested. And then optionally provide details on the IP address including an Geo locator showing exact location of the IP: address, including showing a geo map..
    It would be nice if software existed to do this analysis allowing one to totally filter out this junk mail based on the sending IP address.
    Also you mention “The ‘Return-Path’, line 10, as mentioned, is a big one to me. Since it can be spoofed, it is not fool-proof.” This may related to my question on somehow the true sender “redirecting” the email and not truly revealing their true IP address…. can you explain that a little more (or you may prefer not … since it might be teaching anybody reading the comments how to fake the system (if so please send comment privately to me alone.
    Thanks – love / appreciate your blog and the great insights and hints.

    • Hey Danley,
      So, the header will show the “hops” that an email has taken. It should show origin and then the path it took to get there with the added header information slapped on to it. Looking at the bottom should show the origins of the message.
      What we have been seeing on some of our most recent phishing challenges is a user receiving an email from “themselves” saying that they have been hacked and the camera caught them on some naughty website. The user and return path are from something else entirely, in the article’s case, some shop in Guam, that was likely hacked and is now a Spam bot (account from service or their own server). So, just because they have an email address doesnt mean they have access to the email through and through.
      It would be possible to have sort of a proxy email server that would receive the email and then create a new email with the same contents and forward on from there. That would help further conceal the true origin. That seems like a lot of trouble but it is not unpossible (sic).
      There are also a few websites that can be used to send anonymous and/or modified emails where certain header information can be set. Shady things can happen with that kind of stuff.
      You are smart to use the service that will decode a header as that does outline some of the more interesting parts. It’s just that, to me, seeing 1 or 2 red flags in the header can instantly delegitimize an email. Ultimately, doing this long enough, I think you can get an eye for it but I would always recommend due diligence for stuff like this, especially when business and reputation is at stake. The phishing game really depends on the user and that is why a lot of these offenders pose as legitimate and reputable businesses to try and get people to bite. Just be aware for what is being asked of you and if it has major (or some) security flaws. These companies are thinking about this, too, and would not likely send legit stuff that may bring themselves into question. You should still question, though, if it smells funny.

  • Good day Ross,

    We know how can create for Inbound disclaimer transport rule what I don’t know is if we can make the disclaimer show info from the header of the email. Please advise!

  • Hey Hameed, I guess it depends on what Email client you are using (Outlook 365, Outlook 2016, GMail, etc) but I would think that you could get that information as a JSON and then just pull the values you need from the appropriate keys and insert those calls in your disclaimer.
    I believe Office JS API has a few options to do as such and I believe it can be done with GMail using something called GSON. Im sure it could certainly be done with AWS, too, and probably Azure.

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha *

Author

Ross Thomas

Ross Thomas is The SSL Store’s IT Manager, he is a regular contributor at Hashed Out.