What‘s in an Email Header and Why Should You Care?

As a software developer who works with email systems, I‘ve learned that there is a lot more to an email message than meets the eye. Every time you receive an email in your inbox, it comes with an additional payload of data that most users never see. This "behind the scenes" information is contained in the email headers.

Email headers are lines of metadata that sit at the top of every email message, above the "From", "To", "Subject" and message body that we‘re all familiar with. They contain details about the email‘s origin, the path it took from sender to recipient, what servers and services processed it along the way, and clues to help determine if it‘s legitimate or potentially malicious.

While headers are normally hidden by default in most email clients, knowing how to view and interpret them is a valuable skill for developers, IT professionals, and savvy email users who want to protect themselves from spam, phishing attempts, and other email-based threats. So let‘s dive in and take a closer look at the wealth of information contained in email headers and why it matters.

Anatomy of an Email Header

A typical email header contains dozens of fields, each providing a small piece of the bigger picture of the email‘s journey and contents. Here are some of the most important and commonly seen header fields:

From: The sender‘s name and email address, as specified by the sender. Keep in mind this can easily be faked/spoofed.

To: The email address(es) of the primary recipients. There may also be "Cc:" and "Bcc:" fields for carbon copy and blind carbon copy recipients.

Subject: The subject line of the email, also specified by the sender.

Date: The date and time the email was sent, in UTC time zone.

Message-ID: A unique identifier assigned to the email by the originating server. Helpful for tracking and identifying a specific email.

Received: Stamped by each server that accepts and forwards the email. There will be one Received header per hop the email makes on its way to the recipient. The first is the most recent and they go in reverse chronological order.

Return-Path: Contains the email address for bounced messages – i.e. where delivery failure notifications will be sent. Often the same as the "From" address but not always.

Authentication-Results: Shows the results of email authentication checks like SPF, DKIM, DMARC (more on these later).

MIME-Version and Content-Type: Indicates the structure and format of the email body, especially if it has both plain text and HTML versions or attachments.

User-Agent: Name and version of the sender‘s email client or device.

X- Headers: Optional, non-standard headers, often added by email services/gateways to provide extra information. Common ones include spam scores, malware scan results, authentication details, etc.

These are just some of the most notable headers you‘re likely to see – there can be many more! But this sample covers a lot of the key information that developers and email admins need to be aware of. Headers dealing with the routing, authentication, and structure of the email are particularly important.

How to View Full Email Headers

The exact steps to view full email headers varies between email clients and services, but it‘s usually not too hard to find. In general, look for an option like "View Original", "View Source", "Show Raw Message" or something similar.

For example, in Gmail, open the email and click the "More" button (three vertical dots), then "Show Original". In Outlook, double-click to open the email in a new window, then go to File > Properties > Internet Headers. On an iPhone, tap the email to open it, then tap the "From" field and select "View Full Header".

Most desktop and mobile email clients have a similar option tucked away somewhere in their menus or settings. If you can‘t find it, try searching the help documentation for that email service for "view headers" or "view source".

Once you‘ve clicked the right option, you‘ll see a wall of plain text that may look confusing at first glance. Don‘t worry, with a little practice, you‘ll soon be able to pick out the key information you need from the full header output.

Tracing an Email‘s Path with Headers

One of the most useful things email headers can tell you is the path an email took from the sender to your inbox. This information is recorded in the "Received" headers, of which there will be one for each server hop the email made.

Here‘s an example of what a series of Received headers might look like:

Received: from mailserver.company.com (192.168.1.10) by
 mailserver.company.com (192.168.1.10) with SMTP
 id 1234abcd.12345678; Fri, 18 Nov 2022 08:30:00 -0800
Received: from mail.sendingserver.net (mail.sendingserver.net [172.16.20.30])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384)
 by mailserver.company.com (192.168.1.10)
 with SMTP id 1234abcd.12345678; Fri, 18 Nov 2022 08:29:59 -0800
Received: from [10.54.40.30] (Unknown [10.54.40.30])
 by mail.sendingserver.net (Postfix) with ESMTPSA id 0987FDSA
 for <[email protected]>; Fri, 18 Nov 2022 08:29:30 -0800 (PST)

Reading from bottom to top, you can see that the email originated from an unknown server with IP 10.54.40.30, passed to mail.sendingserver.net, then to the company‘s mail server at 192.168.1.10 before being delivered.

The Received headers also include timestamps showing when each server accepted the message. This can help establish a timeline of the email‘s journey. Additional info like the email protocol used (e.g. SMTP, ESMTP) and any encryption (e.g. TLS with specific ciphers) is often recorded too.

All of this gives important clues as to the true origin of an email, which can be very useful when investigating suspicious or malicious emails. Of course, headers can potentially be spoofed by sophisticated senders, so they aren‘t totally foolproof. But they‘re a good starting point.

Detecting Forged Senders with SPF, DKIM, DMARC

Speaking of malicious emails, another key thing to look for in headers is the presence and results of email authentication methods like SPF, DKIM, and DMARC. These are methods that attempt to verify an email is really coming from who it claims to be from.

SPF (Sender Policy Framework) is a way for domain owners to specify which servers are allowed to send email on behalf of their domain. Receiving mail servers can check the SPF record and see if the "envelope from" domain matches the approved sending server IPs. The result is usually noted in the Authentication-Results header, or sometimes in a Received-SPF header.

DKIM (DomainKeys Identified Mail) uses public-key cryptography to sign certain headers of an email with a private key only the legitimate sender should possess. Recipients can validate the signature with the sender‘s public key published in their DNS records. A successful validation means the signed headers, including the From address, weren‘t forged. Look for a DKIM-Signature header and/or DKIM results in the Authentication-Results.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM. It allows domain owners to specify a policy telling receiving servers what to do if SPF or DKIM checks fail (e.g. reject the message, mark it as spam). It also enables reporting back to the sender domain about messages that fail these checks. The DMARC results are included in the Authentication-Results header.

Seeing "pass" results for these authentication checks is a good sign the email is legitimate. But it‘s not a guarantee, as not all legitimate senders use these protections, and a sophisticated attacker could potentially work around them. Still, failed SPF/DKIM/DMARC checks are a major red flag that warrants caution and further investigation.

Other Header Red Flags to Watch For

Along with authentication results, there are some other tells in email headers that can signal a questionable or dangerous email:

  • Mismatched "From" and "Return-Path" addresses, or a "From" that doesn‘t match the sending domain in the Received headers
  • Invalid or suspicious-looking Message-IDs
  • Receiving server IPs that trace to unexpected countries or organizations
  • Unusual X- headers that may indicate the email was marked as spam by a filter
  • HTML-only emails (no plain text version) with a high proportion of images or obfuscated links
  • Odd or missing MIME boundaries/encoding for attachments
  • Strings of random characters in the Subject or other fields that may be trying to evade filters

Again, no single one of these is proof of a malicious email, but they can certainly be hints that the email deserves a skeptical eye and a bit more digging before trusting it.

Analyzing Email Headers: Putting it All Together

As you can see, there is a wealth of information packed into email headers that can tell you a lot about where an email really came from, how it got to you, and how trustworthy it is (or isn‘t). By learning to find and interpret this info, you can gain valuable insight to help protect yourself and your users from email threats.

When in doubt about a particular email, I recommend copying the full headers and pasting them into an online header analysis tool like the ones at MxToolbox, Google Apps Toolbox, or WhatIsMyIP. These can help parse and explain the header fields, as well as do things like look up sending IP addresses and run them against blacklists.

You can also search for header terms and values to cross-reference them with known spam/phishing markers. And of course, inspect the body and any links or attachments carefully as well – headers are just one piece of the puzzle.

Additionally, one area we didn‘t touch on much here is email tracking via headers. Many marketing and newsletter emails will include tracking pixels and custom headers that can tell the sender if and when you‘ve opened an email, what device you used, and even your IP address. This is worth being aware of from a privacy perspective.

For developers and IT pros who manage email systems, understanding headers is crucial for troubleshooting email issues like delivery failures, routing loops, spam filter false positives, and the like. Being able to read headers is an essential skill for tracing and resolving email snafus.

Conclusion

We‘ve covered a lot of ground in this deep dive into email headers. Hopefully you now have a better appreciation for these unsung heroes of the email world and the vital role they play in securing and troubleshooting email.

While most email users will never need to dig into headers on a regular basis, they are absolutely invaluable when you need them. And for those of us who work with email systems, fluency in "headerese" is a must.

So the next time a questionable email lands in your inbox, take a moment to view the full headers and see what story they tell. You might be surprised at what you find lurking in those seemingly inscrutable lines of text. The headers will often reveal more truth than the facade of the email body.

Stay safe and happy header sleuthing!

Similar Posts