How to read email headers to spot phishing

What email headers are

Every email starts with a block of header lines that the mail app hides. Some are written by the sender and can say anything: From, To, Subject, Date, Reply-To. Others are written by the servers that handled the email: each adds a Received line, and the server at your end usually adds an Authentication-Results line with the SPF, DKIM and DMARC results. Those are the lines you can trust.

One limit up front: an email that never left your organisation often has no authentication results at all. That is not suspicious in itself.

Where to find the headers

In Outlook

• Classic Outlook for Windows. Open the email in its own window and choose File → Properties. The headers are in the Internet headers box.
• New Outlook for Windows. Open the email, click More actions (the three dots) and choose View → View message details (Microsoft: View internet message headers in Outlook).
• Outlook on the web. Open the email, click the three dots in the reading pane and choose View → View message details.
• Outlook for Mac. Control-click the email in the list and choose View Source.

In a saved .eml or .msg file

Reported emails often arrive as a file, because the reporter forwarded the email as an attachment. An .eml file is plain text: open it in Notepad or TextEdit and the headers are the first lines, down to the first empty line. A .msg file is Outlook’s binary format: open it in Outlook for Windows and use File → Properties. A .msg only carries internet headers if the email came in over the internet (see Outlook .msg vs .eml). On a Mac without Outlook, see how to open a .msg file on a Mac.

A header analyser such as Microsoft’s Message Header Analyzer or MxToolbox lays the block out as a table, with the hops in order. These tools run on their makers’ servers, so do not paste headers from an email you may not share.

Five things to check

1. Authentication-Results. Look for spf=, dkim= and dmarc=. pass means the sending server was allowed to send for that domain and the message was not changed on the way. fail is a strong warning. none means the domain publishes no policy, which is common for small senders and says little on its own. Only the line added by your mail server counts; a forwarded email can carry results from the reporter’s server too.
2. From versus Return-Path. From is what the reader sees. Return-Path is where bounces go, and the address SPF was checked against. A newsletter service legitimately uses a different one. A bank sending from a random domain does not.
3. Reply-To. If it points to a different domain than From, replies go somewhere else than the reader thinks. Invoice fraud relies on this.
4. The Received lines. Read them from the bottom up: the lowest line is the first server that handled the email, the top line is your own. A mail from “your IT department” that entered through a consumer mail provider abroad deserves a second look. The very first hop can be forged; the lines your own servers added cannot.
5. The sender domain. Look for lookalike letters and domains starting with xn--, an international domain name that can hide accented or Cyrillic letters. A typo in plain letters, such as a 1 for an l, you have to spot by eye.

Then look at the body the same way: links whose text names one domain while the address goes to another, attachments that can run code (.exe, .js, .html, .svg, archives with such files inside), and urgency.

Where this falls short

Headers tell you whether the email came from where it claims. They do not tell you whether a genuine but compromised mailbox sent it: phishing from a hacked supplier passes SPF, DKIM and DMARC. Reading headers also takes time and the wrong tool. A service desk agent working from a Jira work item has to download the .msg, open Outlook, find Properties and paste into an analyser, for every report. On a Mac or a phone, a .msg does not even open.

On a Jira work item

Full disclosure: Dortus makes MailView for Jira. It shows a .msg or .eml attachment as a readable email on the work item, including a forwarded email that arrived without a file name. Its Details tab lists every header, the SPF, DKIM and DMARC results recorded by the receiving mail server, and the address behind every link (short links and redirects are not followed). Above that sits a verdict, Looks OK, Be careful, Likely phishing or Not enough to judge, with the reasons. Copy findings puts a defanged summary in the clipboard for the ticket comment. Scripts, forms and remote images are removed before anything is shown.

The verdict is an aid for the person triaging, not a security control, and it can miss things. MailView runs on Atlassian Forge, reads the attachment with your own permissions, renders it in your browser and keeps no copy. Want to try the check without Jira? The free email check runs the same checks on a .msg or .eml file in your browser and uploads nothing.

FAQ

Questions

Spotted something wrong on this page, or a way we missed? Email support@dortus.com.

See also: Handling phishing reports in Jira Service Management, How to open .msg and .eml attachments in Jira and See the original email behind a Jira Service Management request