Email Headers: How to read and use message headers
This blogpost will explain how to read and understand the ’email header’ which travels with every email. It contains details about the sender, taken route and the receiver. Use this information to avoid unwanted emails or to recognize a scam or malware delivered by email.
How to access the Email Header
In Mailfence web interface, go to your mailbox, right-click on the email, select ‘View source’.
Most mail clients allow access to the message header. The following list contains a few popular email and webmail clients. Please refer to the manual of your email client if it is not listed here.
View the Email Header in Google Mail (Gmail) Webmail:
Login to your account via the web-interface and open the message (click on it). Click on the ‘down-arrow’ on the top-right of the message and select ‘Show Original’.
View the Email Header in Yahoo Mail Webmail:
Login to your account via the web interface and open the message (click on it). Click on ‘Actions’ and select ‘View Full Header’.
View the Email Header in Hotmail Webmail:
Login to your account via the web interface and go to the message list. Right-click on the message and select ‘View Message Source’.
View the Internet Headers in MS Outlook:
Open the message in MS Outlook. Now go to ‘View’ and select ‘Message Options’ – or ‘File’ -> ‘Info’ -> ‘Properties’. Check ‘Internet Headers’.
View the Email Header in Thunderbird:
Open the message, then click on ‘View’ and select ‘Message Source’.
View the Email Header in MS Windows Mail (and MS Outlook Express):
Select the message in the list, right-click on it and select ‘Properties’ and go to ‘Details’.
Note: instructions mentioned above may vary depending on the version of the email client that you are using.
How to use Email Header Fields
We will use the following sample message header. The font in blue will describe what each of the common fields in an email header represent, and how this information can be used in a useful manner.
Standard Email Header Fields
Received: from sender_mail_server ([bbb.bbb.bbb.bbb]) by recipient_mail_exchanger (envelope-from <email@example.com>) with ESMTPS
The message was received by the recipient_mail_exchanger from sender_mail_server with an IP address bbb.bbb.bbb.bbb over STARTTLS (‘S’ in the ESMTP tag means secure).
for <firstname.lastname@example.org> ; Wed, 7 Sep 2018 12:35:32 +0200 (CEST) Return-Path: email@example.com
The mail server sends a notification email to the address specified here, when the message bounces or cannot be delivered. This address is commonly referred to as ‘reply to’ address and could be different from the sender email address.
Received: by xyz.google.com with SMTP id abc.xyz for <firstname.lastname@example.org>; Wed, 07 Sep 2018 03:35:32 -0700 (PDT)
The message travels through all of these (usually 1-3) mail servers (or MTA’s) from sender_mail_server to the recipient_mail_exchanger.
Received: from ‘Sender_display_name’ ([aaa.aaa.aaa.aaa])
The message was sent from the sender’s device with the IP address aaa.aaa.aaa.aaa. It can also be found in the X-Originating-IP header field. This IP address is mostly removed by privacy respecting email clients, as it could reveal details about the sender’s location.
by sender_server_domain_name with ESMTPSA id abc_xyz_123 for <email@example.com> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 Sep 2018 03:35:31 -0700 (PDT)
The sender_server_domain_name mail server after receiving a message from the sender’s device with IP address ‘aaa.aaa.aaa.aaa‘, transfers the message over STARTTLS (in the ESMTP tag, ‘S’ means secure and ‘A’ means authenticated). Information also includes the TLS version and cipher-suite that was used by the STARTTLS protocol.
Some might try to fake the routing information, and your mail server is supposed to give you a warning that something was not correct during the transfer from sender_server_domain_name to the recipient_mail_exchanger.
Message sender address.
This could easily be faked, or could be made like firstname.lastname@example.org OR email@example.com (‘1’ and ‘l’ being very similar).
Check our phishing and social engineering blogposts for more details.
Message receiver address.
Subject: Leaving Gmail!
Date: Wed, 7 Sep 2018 12:35:29 +0200 Message-ID: firstname.lastname@example.org
Date and Message ID.
If the date mentioned here differs from the date mentioned in the last received header (top one), then it could indicate possible message delivery issues OR an MITM attack. It is advised to pay caution in such cases.
MIME-Version: 1.0 Content-Type: multipart/alternative;
MIME Version and Type.
X-Mailer: Microsoft Outlook 16.0
The email client (or MUA) that was used to send this message. This line is mostly removed by privacy respecting email clients.
Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a multi-part message in MIME (Multipurpose Internet Mail Extensions) format. It is an Internet standard that extends the format of email messages to support rich text, files and other active content.
Hello, Enough of privacy violations and shady business practices by Gmail! This is my last email from Gmail, as I finally decided to join Mailfence! Regards, Privacy conscious user! ------=_NextPart_000_0007_01D44514.EEC24AC0...------=_NextPart_000_0007_01D44514.EEC24AC0-- ...
Sender Policy Framework (SPF)
SPF is a framework to prevent sender address forgery. It is used to describe which mail server is allowed to send messages for a given (sender) domain. SPF thus helps to avoid fake sender email addresses. The result (Received-SPF) can be neutral, pass or fail.
From the sample message above:
Validation results is ‘pass’ since sender_server_domain_name IP address is permitted to send emails for ‘gmail.com’ domain.
If the validation result is ‘fail’, then it is highly likely that someone tried to spoof the sender’s email address and/or content.
Domain Keys Identified Mail (DKIM)
DKIM is a method to associate a domain name to an email, thereby allowing an organization to check the (cryptographic) signature to ensure that the message was sent by its claimed owner and was not modified during the transit.
From the sample message above:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=fZjxO4TdlsVYWA6YIXoMF8AS+FOsm2lV1tfhDvYZNQo=; b=cMSUNWMGENp4jXuFTInBnZi6Sq2ZcjhBNA0ht8rSEt1SR8b0gGmiiZZ4l52lGSCum5 lRtmPPtt/tgnqubiLBBW2fatlarhjo6qRp7FRE9IsE6XBIl6muTGS/kUDwEm9NGXjQRp nxmHp4/JKDKrYHg8cKsm+yr3k17hNXHITIrb9VAh2CtEKpAxSYN3MsC4QplXdnLArQju U3jAnJf0lLZwZcygBbZSY7ENEAtHSbHpt6LLeQKlzosYARoakAH3j8EaAAAu1TfyAYE4 +u7ENqUzddifO6Qty3E2I4Soq00SbOO+e64WIUZ0gxoARQqeuAN7H/jaOkC4t5mhWmkb aEFA==
The message contains a valid DKIM signature (formatted as per the standard).
Validation results is ‘pass’.
If the validation result is ‘fail’, then it is highly likely that the message was spoofed or modified during transit and/or that the message is spam.
Commonly used spam detection programs (e.g., SpamAssassin) installed on the mail servers provides a detailed report for each message. They do this by adding lines and a summary in the message header.
Spam detection result.
X-Spam-Status: No hits=-1.2 required=4.7
Spam detection result along with the score. A score less than 5 means (on most systems) not spam, between 5 and 15 probably spam, and more than 15 definitely spam.
Spam detection programs do not only check the message sender, but also check message format and the content of the message in order to derive their final spam score. E.g., message structure, SPF+DKIM, DNSBL, custom rules…
If the overall spam score is between 5 and 15 or more than 15, then it is highly likely that the message is suspicious or a spam. However, the final decision is always made by the recipient_mail_exchanger.
Other email header fields
There could be many other standard/approved message header fields as well as non-standard/custom message header fields. Both of them can also be found in email headers. Some examples are:
- Authentication-Results – summary of sender_server_domain_name authenticity (based on SPF, DKIM and other results).
- List-ID – an email mailing list reference
- List-Unsubscribe – a direct reference that can be used to unsubscribe from a mailing list.
- Auto-Submitted – indication that a message was auto-generated by a system (e.g., notification messages, …)
Email Header Fields and End-to-end encrypted messages
Email message header fields are mostly read independently of the message body which is end-to-end encrypted and is meant to be read by the client (e.g., who holds the private key in a Public key crypto-system). However, following are some of the common message header fields that can indicate an encrypted and/or signed message.
From the sample message above:
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature" .... Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature Content-Disposition: attachment
Indicates a MIME type ‘multipart/signed’ for OpenPGP signed message which is sent as an attachment. OpenPGP signatures can also be sent inline (not as an attachment).
Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; ... Content-Type: application/octet-stream; name=encrypted.asc Content-Transfer-Encoding: ... (base64, 7bit, ...) Content-Description: OpenPGP encrypted message Content-Disposition: inline; filename=...
Indicates a MIME type ‘multipart/encrypted‘ for OpenPGP encrypted message which is sent as an attachment. OpenPGP encrypted messages can also be sent inline (not as an attachment).
-----BEGIN PGP SIGNATURE----- ... -----END PGP SIGNATURE-----
Indicates the beginning and end of an OpenPGP signature.
-----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE-----
Indicates the beginning and end of an OpenPGP encrypted message.
Protecting email headers from end-to-end encryption
Use end-to-end encryption and digital signatures to further check the legitimacy of message headers.
Mailfence includes the From, To and Time-stamp fields in the message body before signing and/or encrypting it. This provides a way for the recipient to check:
Sep 7, 2018 12:35:29
- If message From and To addresses do match with the sender and recipient addresses included in the signed and/or encrypted message body. This helps in detecting any possible spoofing of sender/recipient address.
- If the message sending date matches (or is significantly close) with the time-stamp included in the signed and/or encrypted message body. This helps in detecting a possible message replay attack.
Including the actual message header fields inside an encrypted message body can also help in preventing meta-data leaks (e.g., Protected email headers).
Many third party message header analyzer tools (https://testconnectivity.microsoft.com/, https://toolbox.googleapps.com/apps/messageheader/, https://mxtoolbox.com/EmailHeaders.aspx, …) produce an easy to read report from that message header data. However, please be noted that you will have to share your message header with these services…
– Mailfence team