Spotting forwards and spoofs in email authentication headers
Emails from a mate in Melbourne or a colleague in Brisbane might have travelled a long way before reaching your inbox. Australian households and small businesses are regularly targeted by phishing scams impersonating the ATO, MyGov, or major banks, which is why reading hidden headers has become a real-world skill. The trick is knowing whether an unusual message is a benign forward from your cousin or something nastier.
Authentication headers are short lines added by mail servers that tell receiving inboxes whether a sender is who they claim to be. They record results from SPF, DKIM, and DMARC checks, and trace every hop the message made. Once you know how to read them, you can tell a forwarded email from a spoofed one.
The core difference is intent. A forward is a deliberate action by a real recipient sharing a message they received legitimately. A spoof is an attacker forging a sender identity to trick you into clicking, replying, or handing over credentials. Authentication headers expose both, but the signals look different.
This is where a free checking platform like Trusted Sender Score helps. By combining header analysis with domain reputation data, it lets you verify whether the path an email travelled matches the path it claims.
Understanding the Authentication-Results header
The Authentication-Results header is stamped onto a message by the receiving mail server after it runs SPF, DKIM, and DMARC checks. You will usually see it near the top of the raw header block, listing results in a structured format like "spf=pass", "dkim=pass", and "dmarc=pass". Each result belongs to the last server that processed the message, not to the original sender in the case of forwarding.
When a message is forwarded, the Authentication-Results header from the original recipient often survives the journey as a copy. You might see something like "spf=pass (mail.iinet.net.au)" alongside the new server's own results. This layered record is a strong sign you are looking at a forwarded email rather than a freshly spoofed one.
Reading SPF, DKIM, and DMARC results
A clean pass across all three is a good sign but never proof of safety. SPF verifies the sending IP is authorised by the domain's DNS record. DKIM confirms message content was not tampered with by checking a cryptographic signature. DMARC ties the two together and tells receivers what to do when they fail.
Forwarded mail from your mate's Telstra address will usually show "softfail" or "none" on DMARC because the forward happened outside the signing chain. A spoof pretending to be from the same organisation will often show "fail" on SPF or DKIM before DMARC ever runs, which is a much louder warning.
The received chain and what it tells you
Every mail server that handles your message adds a Received header, stacking them like footprints from your inbox back to the origin. Reading them bottom to top traces the journey in reverse. Each entry includes a timestamp, the sending server's hostname, its IP address, and sometimes the protocol used.
Forwarded messages typically show a clean chain ending at a familiar consumer ISP such as Bigpond, Optus, or Gmail. A spoof often ends at an unfamiliar host in an unrelated region. If you spot a high volume of DMARC failures clustering around a single IP, that's worth investigating through a resource on DMARC failure analysis.
How forwards rewrite the trail
When someone forwards a message, the mail client creates a new envelope. The original sender's address is preserved in headers like From or Reply-To, but the Return-Path and sending IP now belong to the forwarder's mail server. This is why forwarded messages from overseas friends often arrive with an Australian server listed as the origin in the top Received header.
Spoofers try to fake this pattern but usually get small details wrong. The Return-Path might point to a domain with no link to the claimed sender, or the Message-ID might follow a format that doesn't match the organisation's usual pattern. These tiny inconsistencies separate a genuine forward from a carefully crafted impersonation.
ARC seals and forwarded chains
ARC, or Authenticated Received Chain, was designed to preserve authentication results across forwarding services like mailing lists and email aliases. Each intermediary adds its own ARC seal so the final receiver can verify that the original signatures were intact when the forwarder received the message.
An email with a valid ARC-Authentication-Results seal showing pass results is far more likely to be a legitimate forward. A spoof will lack ARC seals entirely or include seals with broken signatures, since attackers cannot forge cryptographic chains they don't control.
Spotting mismatched identities
The most reliable giveaway is a mismatch between the visible From address and the domain that actually signed the message. In a forward, the From header looks normal but the DKIM signature belongs to the forwarder's domain. In a spoof, attackers try to align these values, but a quick look at the From, Return-Path, and signing domain will reveal whether they actually match.
When in doubt, the frequently asked questions section covers common patterns seen across Australian mail flows, including how Telstra, Optus, and smaller providers handle authentication on behalf of their customers.
Putting it all together
Combined, the header signals reveal a pattern that is hard for spoofer campaigns to fake. A genuine forward looks messy from a strict DMARC perspective but consistent from a Received chain perspective, while a spoof reveals itself in the cryptographic details.
Run through the table below as a quick checklist the next time you receive something unexpected, whether it's a "shared invoice" from a supplier in Sydney or a parcel redelivery notice that arrived at 2am your time.
| Signal | Forwarded Email | Spoofed Email |
|---|---|---|
| SPF result | Often softfail or none | Often fail or softfail |
| DKIM signature | Belongs to forwarder's domain | Missing, broken, or foreign |
| DMARC result | Typically none or pass | Typically fail |
| Return-Path | Points to forwarder's domain | Mismatched or unrelated |
| Received chain | Ends at familiar consumer ISP | Ends at unusual or unrelated host |
| ARC seals | Present and valid | Missing or broken |