Email header analysis is one of the least glamorous skills in Australian IT security, and one of the most useful. When a phishing message lands in an inbox or an incident report flags a suspicious sender, the raw headers are the ground truth. They record every server the message touched, every authentication check it passed or failed, and the actual origin IP address. None of that is visible to a regular user. All of it matters to an investigator.
Spoofed email still reaches Australian inboxes every day despite SPF, DKIM, and DMARC being well established. The reason is simple: misconfiguration is widespread, and attackers know exactly which gaps to exploit. Understanding what the headers actually say, rather than what the "From" field displays, is where the analysis starts.
What email headers actually contain
Every email carries two sections: the body (what you read) and the headers (what the servers wrote). Most mail clients hide headers by default. In Outlook, you access them under File > Properties > Internet headers. In Gmail, open the message, click the three-dot menu, and select "Show original".
The headers are written in reverse chronological order. The bottom entries were added first (by the sending server), and each subsequent server prepends its own record as the message travels. That means you read from the bottom up to follow the actual journey.
Key fields to examine:
- Received: Added by each mail server the message passed through. Contains IP addresses, timestamps, and server hostnames.
- From: The display name and address the sender chose. This is trivially spoofable.
- Return-Path: Where bounce messages go. Often differs from the From address in spoofed mail.
- Message-ID: A unique identifier. The domain in the Message-ID should match the sending domain in legitimate mail.
- Authentication-Results: Added by the receiving server, summarising SPF, DKIM, and DMARC outcomes.
Reading the authentication results
The Authentication-Results header is where most investigations start. A clean result looks something like this:
Authentication-Results: mx.example.com;
spf=pass smtp.mailfrom=sender@legit.com;
dkim=pass header.d=legit.com;
dmarc=pass action=none header.from=legit.com
All three passing together is a strong signal. Any single failure warrants scrutiny. A DMARC fail with SPF pass sounds contradictory, but it happens when the domain in the SPF envelope differs from the visible From domain. That gap is exactly what display-name spoofing exploits. The SPF check passes on a domain the attacker controls, while the From field shows a trusted brand.
DKIM failures are more nuanced. A failed DKIM signature can mean the message was altered in transit (legitimate forwarding scenarios do this), or it can mean the signature was fabricated. Look at which domain the DKIM signature claims to be for: header.d= should match the From domain in a legitimate message. If it doesn't, treat it as a red flag.
Tracing the originating IP
Find the earliest (bottom-most) Received: entry that contains an external IP address. Internal relay hops between your own servers don't count. That external IP is where the message entered your mail environment.
Run that IP against a few sources. A reverse DNS lookup (using nslookup or dig -x) shows the hostname the IP resolves to. Does it match the claimed sending domain? It won't always, because many legitimate senders use third-party mail infrastructure, but a complete mismatch with a suspicious hostname is a concrete data point. Cross-reference the IP against the sending domain's SPF record using a tool like MXToolbox to confirm whether that server is authorised to send on behalf of the domain.
Geolocation adds context. If a finance team member's account "sent" a wire transfer request and the originating IP geolocates to Eastern Europe at 3am AEST, that's a useful fact for the incident record even if it's not conclusive on its own. This kind of analysis connects directly to business email compromise, where attackers mimic trusted senders to authorise fraudulent transactions.
Display name spoofing vs domain spoofing
These are different attacks. Domain spoofing means sending from a lookalike domain (paypa1.com instead of paypal.com) or from a domain that fails DMARC enforcement. Display name spoofing is subtler. The attacker sends from a completely unrelated domain they control (and which passes SPF and DKIM legitimately), but sets the From display name to something like "John Smith – Finance Director". Most users see the name, not the address.
Headers expose this immediately. The From: field will show the real sending address next to the fabricated display name:
From: "John Smith - Finance Director" <attacker@randomdomain.net>No authentication failure occurs here. SPF, DKIM, and DMARC all pass for randomdomain.net. The only defence is a mail filter that checks whether the From display name matches a known internal contact while the sending domain is external. Most organisations don't configure this. It's a gap worth closing.
Practical workflow for incident investigation
When a suspicious message is escalated, the analysis sequence is straightforward. First, retrieve the raw headers from the mail client or your email gateway's quarantine interface. Second, read the Authentication-Results to establish the SPF/DKIM/DMARC outcome. Third, trace the originating IP from the earliest external Received: entry. Fourth, check whether the Return-Path, Message-ID domain, and DKIM signing domain all align with the visible From domain.
Inconsistencies between those fields aren't proof of attack on their own, but each one narrows the field. Document what you find against a timeline. If the message is part of a social engineering campaign, header artefacts from multiple messages will often share infrastructure: the same originating IP range, the same mail server hostname, or the same DKIM signing domain across different spoofed senders.
Most Australian organisations have the logs. The gap is the habit of looking at them systematically before a breach, not only after one.
Automating header analysis at scale
Manual header reading works for individual incidents. At scale, security teams feed headers into their SIEM or email security gateway and write detection rules. A rule that fires on DMARC=fail combined with a From domain matching an internal executive's name catches a category of attacks that signature-based tools miss entirely. Pair that with careful SIEM tuning to avoid burying the signal in forwarding-related false positives.
MXToolbox's email header analyser is a quick free tool for ad-hoc investigation. For production environments, Microsoft 365 Defender and Google Workspace both expose header-level authentication data through their admin consoles and APIs, making it feasible to query at volume without pulling raw headers manually.
The headers have always been there. Most attacks leave clear traces in them. The question is whether someone on your team is in the habit of reading them.