Email Header: Data Point Intelligence Guide

The body of an email is what the sender wanted you to read. The headers are what the infrastructure recorded regardless of intent.

Understanding the Email Header as an intelligence artifact

An email header is the metadata block preceding a message body: From, To, Subject, Date and Message-ID, plus a stack of Received lines added by each relay in transit and the authentication results for SPF, DKIM and DMARC. Read from the bottom upwards, the Received chain reconstructs the path from originating client to final delivery, with hostnames, addresses and timestamps at each hop. Further headers expose the sending software, mailing platform, campaign identifiers and, in phishing, the inconsistencies between envelope and display addresses.

Analytically important variants include the envelope sender in Return-Path versus the display From address, legacy originating-address headers, mailer identification fields, list management headers from bulk platforms, and DKIM signature headers naming the signing domain and selector. Message-ID format is frequently unique to the generating software. Authentication-Results is written by the receiving system and is only trustworthy for hops occurring after your own trust boundary.

Why it matters

Headers convert a suspicious message into infrastructure. They yield sending addresses, hosting providers, mail platforms and signing domains that pivot to passive DNS, related campaigns and hosting abuse action. They establish whether a message genuinely originated from a claimed domain, which is the central question in business email compromise and invoice redirection fraud. Message-ID format and DKIM selector frequently cluster campaigns that otherwise vary lure, subject and sender across thousands of messages.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

• Originating address from the earliest trusted Received hop, pivoting to hosting provider, autonomous system and geography.
• Discrepancy between the Return-Path envelope sender and the display From address, a core spoofing indicator.
• SPF, DKIM and DMARC outcomes showing whether the sending host was authorised by the claimed domain owner.
• Mailer identification and Message-ID format that fingerprint the sending toolkit, whether a bulk platform or a bespoke script.
• Timezone offsets in the Date and Received lines, which suggest sender working hours and locale.
• Unusual relay hop counts and internal hostnames revealing compromised legitimate mail servers used as relays.
• DKIM signing domain and selector, which cluster superficially unrelated messages into a single campaign.
• Reply-To pointing at a lookalike domain, the classic pattern in invoice and payroll redirection fraud.

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

• Google Admin Toolbox Messageheader — Free header parsing with hop-by-hop delay analysis and an authentication summary.
• MXToolbox header analyser — Parses Received chains, authentication results and reputation status for the sending address.
• dig and DNS policy lookups — Retrieves SPF, DKIM and DMARC records that determine whether the sending host was authorised.
• Team Cymru IP-to-ASN and RIR whois — Maps the originating address to network owner, autonomous system and abuse contact for reporting.
• URLScan.io — Safely resolves embedded links, capturing landing pages, redirect chains and page resources.
• VirusTotal — Reputation and prior sightings for sender domains, addresses, URLs and attachment hashes.
• PhishTank and APWG — Community phishing reports and a submission channel for confirmed phishing URLs.
• MISP — Structured sharing of extracted email indicators with partner organisations and sector groups.

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

1. Preserve the original message — Export the raw message file rather than a forwarded copy, because forwarding rewrites headers and destroys the Received chain.
2. Parse the Received chain — Read from the bottom upwards, mark your own trust boundary, and treat only hops beyond it as attacker-influenced and informative.
3. Verify authentication — Check SPF, DKIM and DMARC outcomes against the current published DNS policy for the claimed sending domain.
4. Enrich the origin — Resolve sending addresses to autonomous system, hosting provider and abuse contact, then check passive DNS for co-hosted infrastructure.
5. Handle payloads safely — Hash attachments and submit URLs to a sandbox or scanner, never opening them on a production endpoint or with a corporate identity.
6. Cluster the campaign — Search the mail gateway for the Message-ID pattern, DKIM selector, subject template and sender infrastructure across the whole estate.
7. Report and block — Push indicators to gateway blocklists, notify the abused domain owner and hosting abuse contacts, and share through MISP.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Pivots to these data points

• Messaging Handle — An identity on a messaging platform (Telegram, Signal, Discord) used for coordination and sales.

Inside the platform: where Email Header lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

• datapoint.php?dp=dp_email_header — Data point hub
• search.php — Advanced search, filter and pivot
• correlate.php — Correlation graph
• cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

• Enrichment Runner
• Enrichment → Local
• Correlate Infrastructure
• Summarise (Copilot)
• Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

1. Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Preserve the original message is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
2. Building the picture. A single indicator is rarely the story. Verify authentication turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
3. Producing something actionable. Analysis that ends in a document nobody can use is wasted. Report and block feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses Email Header

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Defence CERT and network defence teams use header analysis to attribute phishing against military networks and contractors, and to feed force protection advisories where personnel are targeted directly. Headers yield sending infrastructure, hosting providers and authentication outcomes that pivot into passive DNS and campaign clustering, supporting cyber threat picture updates and indicator sharing with coalition partners. Spear-phishing against named personnel is also a counter-intelligence indicator worth reporting separately from the technical detection. Constraints: message content may be classified or privileged, mailbox exports require authority and access control, and active probing of sender infrastructure is an operation requiring separate authorisation rather than an analyst's initiative.

🕵 National intelligence

National intelligence uses headers as a fusion point between technical infrastructure and targeting intent. Recipient selection in a spear-phishing set is itself a requirement-relevant signal about what an adversary wants. Sending infrastructure, mailer fingerprints and DKIM selectors cluster campaigns across victims and over time, which supports attribution assessments built from many weak indicators rather than one strong one. Handle carefully: message bodies contain personal data and often privileged material, so share indicators rather than content when disseminating, and mark derived products with the origin of the underlying reporting. Confidence language should distinguish infrastructure clustering from actor attribution, which headers alone rarely establish.

👮 Law enforcement

For investigators the header is the routing record and must be preserved as the original message file, not a forwarded copy, because forwarding rewrites headers and destroys the Received chain. Export in a defensible format with a hash and a documented method. Originating addresses and provider identities determine which lawful process is needed: a preservation request followed by a production order or warrant to the mail provider or hosting company, and mutual legal assistance where they are foreign. Subscriber records behind an originating account are what convert infrastructure into a person. Header analysis supports charging in business email compromise and invoice fraud by evidencing the spoof and the redirection.

🔍 Private investigation and corporate security

Corporate security uses headers for business email compromise response, invoice fraud recovery and internal misconduct enquiries where message provenance is disputed. In litigation support, the Received chain and authentication results are often the deciding evidence on whether a message is genuine or fabricated. A private actor may only analyse mail their organisation lawfully holds or that was reported to them, must respect employee monitoring rules and works council requirements, and may not access third-party mailboxes, pretext a provider for subscriber data, or probe sender infrastructure. Preserve originals early, because mail retention policies commonly delete the evidence before the fraud is discovered.

📰 Journalism and OSINT media

Journalists rely on headers to verify that a leaked or supplied email is genuine, which is the single most common authentication question in document-based reporting. DKIM signatures are the strongest available check: a valid signature over the body and key headers, verified against the current published key, is hard to forge. Verify before publishing, and say in the piece how verification was done. Protect sources by stripping recipient identifiers and any headers that identify the mailbox that supplied the material, and by handling the original in an offline environment. Give the named sender an opportunity to respond, including to the authenticity question itself.

🌍 NGO, humanitarian and human rights

Human rights organisations analyse headers in two contexts: defending staff and partners against targeted phishing, and documenting state-linked targeting of activists for accountability. Both require care with the personal data of recipients, who may be at risk if their targeting becomes public. Obtain informed consent before publishing anything that identifies a targeted individual, and consider whether disclosure exposes them to reprisal. Share indicators with civil society defence networks rather than raw messages. Duty of care extends to staff, who need clear reporting routes and no blame for clicking. Where evidence supports a pattern of state-linked targeting, preserve it to accountability standards rather than treating it as routine security noise.

🎓 University and research

Researchers studying phishing, spam economics and authentication adoption need ethics approval because message content and recipient addresses are personal data, and phishing corpora often contain credentials. Work from consented institutional feeds, honeypot collections or published corpora rather than scraped mailboxes, and document the collection frame, since gateway-filtered corpora systematically under-represent successful attacks. Reproducibility comes from releasing extraction code, feature definitions and aggregate statistics rather than raw messages. Report authentication measurement method precisely, because SPF, DKIM and DMARC results depend on evaluation time and DNS state. Cite datasets by version and retrieval date.

Playbook: working Email Header end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Preserve the original message

Obtain the raw message source in its original form, exported as an EML or MSG file or pulled from the mail store, rather than a forwarded copy. Forwarding rewrites headers, collapses the Received chain and destroys DKIM signature validity, which is precisely the evidence you need. Hash the file, record who exported it, from which mailbox and when, and store it read-only. Where the matter may become litigation or prosecution, issue a legal hold on the mailbox and request provider preservation immediately, because retention policies routinely delete the evidence within weeks.

Phase 2 — Establish your trust boundary

Identify which mail infrastructure you control and therefore which Received lines were written by systems you trust. Everything added before that boundary can be forged, and attackers routinely insert fabricated Received lines to imply a legitimate origin. Mark the boundary explicitly in your working notes. Only hops beyond it are attacker-influenced and analytically interesting; only hops within it can be relied on as fact. This single distinction prevents the most common analytical error in header work, which is treating the whole chain as a factual routing record.

Phase 3 — Parse the Received chain

Read from the bottom upward, recording for each hop the reporting host, the claimed connecting host and address, the protocol, the timestamp and any TLS detail. Compute inter-hop delays to spot queuing, relays and gaps. Note internal hostnames, which frequently reveal a compromised legitimate mail server being used as a relay. Record inconsistencies between forward and reverse DNS. The output is a hop table with a clear marker where trust begins, ready to be cited in an incident record without further interpretation.

Phase 4 — Evaluate authentication

Check SPF, DKIM and DMARC results against the currently published DNS policy for the claimed sending domain, and record the policy as it stood at evaluation time because it changes. Verify the DKIM signature independently rather than trusting the Authentication-Results header, which is only meaningful if written by a system you control. Note the signing domain and selector. Remember that a pass proves the sending host was authorised by some domain, not that the message is legitimate; display name spoofing and lookalike domains pass authentication routinely.

Phase 5 — Fingerprint the sending toolkit

Extract Message-ID format, mailer identification, MIME boundary patterns, header ordering and encoding choices. These are artefacts of the software that generated the message and are far more stable across a campaign than subject lines, sender addresses or lures. Record them as a structured fingerprint. A distinctive Message-ID pattern combined with a DKIM selector will often cluster messages that share nothing else visible, which is what turns a single reported phish into a campaign with a measurable footprint across the estate.

Phase 6 — Enrich the origin

Resolve the earliest untrusted originating address to autonomous system, network owner, geolocation and abuse contact. Query passive DNS for other names that resolved to the same address and for the sending domain's history, including registration date and nameserver changes. Newly registered domains and hosting on bulletproof or abused providers are strong prioritisation signals. Record everything with the query date, because passive DNS and whois results are time-sensitive and will not reproduce later.

Phase 7 — Handle payloads safely

Never open attachments or click links from a production endpoint or with a corporate identity. Hash attachments and submit them to a controlled analysis environment; submit URLs to a scanning service or detonate them in an isolated sandbox with an appropriate egress path. Capture redirect chains, landing pages and any credential harvesting form. Be aware that submission to public services discloses the sample, which may be inappropriate for a targeted attack against your organisation; use private analysis where confidentiality matters.

Phase 8 — Cluster across the estate

Search the mail gateway and message tracking logs for the fingerprint components: Message-ID pattern, DKIM selector, sending infrastructure, subject template, attachment hash and URL structure. Establish how many messages arrived, how many were delivered, how many were opened and how many recipients interacted. This converts a single report into a scoped incident with a defensible impact statement. Stop when the search space is exhausted rather than when the first cluster looks convincing.

Phase 9 — Assess targeting

Examine who received the messages. Broad untargeted distribution and precise selection of finance staff, executives or a named project team are different incidents with different implications. Check whether the recipient list correlates with a public source such as a conference attendee list, a leaked address set or a website staff directory, since that tells you how the targeting was built and what to remediate. Targeted selection of specific personnel should be escalated separately from the technical detection.

Phase 10 — Remediate and notify

Block confirmed indicators at the gateway and proxy, remove delivered copies from mailboxes, force credential resets where a harvesting page was reached, and check for mailbox rule creation, forwarding rules and OAuth grants that indicate successful compromise. Notify affected users with clear instructions and no blame. Where a partner or customer domain was abused, notify their security contact. Assess regulatory notification duties where personal data was reachable. Record the remediation timeline as part of the incident file.

Phase 11 — Report and share

Report the abused infrastructure to hosting and mail provider abuse contacts, and submit confirmed phishing URLs to anti-phishing bodies. Share extracted indicators through your sector information sharing community or MISP instance, distributing indicators rather than message bodies and redacting recipient identities. Provide enough context for a partner to act, including the fingerprint components rather than only atomic indicators. Track whether shared indicators later produced detections elsewhere, which is the measure of whether sharing is worth the effort.

Phase 12 — Close the loop on controls

Feed findings back into configuration: tighten DMARC policy on your own domains toward enforcement, add lookalike domain monitoring, tune gateway rules against the observed fingerprint rather than atomic indicators, and review whether external sender warnings and finance verification procedures would have interrupted the attack. Measure the change rather than asserting it. Schedule a review of preserved evidence retention so message files with personal data are not held indefinitely once the incident is closed.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
RFC 5322 Internet Message Format	Open	Defines the syntax of message headers including From, Date, Message-ID and trace fields.	Authoritative reference for what each header means and what is syntactically valid.
RFC 5321 Simple Mail Transfer Protocol	Open	Specifies SMTP transport, the envelope, and how Received trace fields are constructed by relays.	Explains the distinction between envelope sender and header From that underpins spoofing analysis.
IETF Datatracker	Open	Repository of internet standards and drafts including SPF, DKIM, DMARC, ARC and BIMI specifications.	Canonical definitions for each authentication mechanism and its evaluation semantics.
DMARC.org	Open	Reference material on DMARC policy, alignment, reporting and deployment practice.	Interprets policy records and aggregate reports when assessing whether a domain was genuinely abused.
M3AAWG best practice documents	Open	Industry guidance on messaging abuse, authentication deployment and abuse handling from major providers.	Sets expectations for what mailbox providers and hosts will act on when you report abuse.
Google Admin Toolbox Messageheader	Open	Free header parser producing a hop table with delays and an authentication summary.	Fast first-pass parsing of a Received chain and authentication outcome during triage.
MXToolbox	Open	Header analysis plus DNS, blocklist and mail server diagnostics for sending domains and addresses.	Checks sending infrastructure reputation and confirms published SPF, DKIM and DMARC records.
URLScan.io	Registration	Sandboxed URL analysis capturing redirect chains, page resources, screenshots and DOM content.	Safely resolves embedded links and captures the credential harvesting page for evidence.
VirusTotal	Registration	Multi-engine reputation and relationship data for files, URLs, domains and addresses.	Checks prior sightings of attachment hashes and sender infrastructure across the community.
APWG	Registration	Anti-Phishing Working Group, an industry body operating phishing data exchange and reporting channels.	Formal route for submitting confirmed phishing URLs and receiving cross-industry phishing data.
PhishTank	Open	Community-verified database of reported phishing URLs with an open API.	Checks whether a URL is already known and contributes newly confirmed phishing sites.
Team Cymru IP to ASN mapping service	Open	Free service mapping addresses to autonomous system, network name and country.	Resolves the originating address to a network owner and abuse contact for reporting.
Regional internet registry whois services	Open	Authoritative allocation and contact records for address space held by RIPE, ARIN, APNIC, LACNIC and AFRINIC.	Identifies the responsible network and its abuse contact when reporting a sending host.
MISP threat intelligence sharing platform	Open	Open platform for structured storage and controlled sharing of indicators and events.	Distributes extracted header indicators and fingerprints to partners without sharing message bodies.
MITRE ATT&CK	Open	Knowledge base of adversary techniques including phishing, spearphishing attachment and link techniques.	Maps the observed delivery method to a technique for coverage tracking and reporting consistency.
National Cyber Security Centre guidance	Open	United Kingdom government guidance on email security, anti-spoofing controls and phishing response.	Reference standard for configuring DMARC enforcement and reporting suspicious mail.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against Email Header. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

• Google Admin Toolbox Messageheader — Quick hop table with delays and authentication summary. Limitation: pasting a header into a third-party service discloses recipient and infrastructure detail.
• MXToolbox header analyser — Header parsing plus live DNS and blocklist checks. Limitation: same disclosure concern, and results reflect current DNS rather than the state at delivery.
• Local header parsing scripts — Offline parsing keeps sensitive headers in your control and enables bulk processing. Limitation: requires maintenance as header conventions and platform behaviour change.
• DKIM verification tooling — Independently validates a signature against the published selector key. Limitation: fails legitimately when keys are rotated or the message was modified in transit.
• dig and DNS query tooling — Retrieves SPF, DKIM and DMARC records and their history via passive DNS. Limitation: policies change, so record the query time or the result is unreproducible.
• URLScan.io and sandbox detonation — Captures landing pages and redirect chains without touching a production endpoint. Limitation: public submission discloses the sample, which is unsafe for targeted attacks.
• Mail gateway and message tracking search — Scopes a campaign across the estate by fingerprint rather than single indicator. Limitation: retention windows are often short and truncate historical clustering.
• MISP — Structured indicator sharing with partner communities and taxonomies. Limitation: value depends entirely on partners reciprocating and on disciplined tagging.
• DMARC aggregate report processors — Turn XML feedback into visibility on who is sending as your domains. Limitation: aggregate reports show authentication outcomes, not message content or targeting.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

• Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
• Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
• Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
• Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
• Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

• Mark your trust boundary before reading anything. Received lines added before your own infrastructure are attacker-controlled text, and analysts who narrate the whole chain as fact are reading fiction the sender wrote for them.
• Fingerprint the toolkit, not the lure. Message-ID format, MIME boundary pattern and header ordering survive across a campaign while subject lines, sender addresses and attachment names change hourly.
• An SPF pass is a statement about a domain the attacker probably owns. Display name spoofing and lookalike domains authenticate perfectly, which is why authentication results prioritise rather than adjudicate.
• Verify DKIM yourself rather than trusting Authentication-Results. That header is written by whatever machine claims to have evaluated it, and outside your own boundary it is just another forgeable string.
• Forwarded copies are not evidence. The moment a user forwards a phish to the security team the Received chain is rewritten and the DKIM signature is invalidated, so build a report-as-attachment button before you need it.
• Timestamp differences across hops are usually clock drift and misconfigured time zones, not tradecraft. Treat sub-hour discrepancies as noise unless corroborated by something structural.
• Reply-To pointing at a lookalike domain, in a thread that otherwise authenticates, is the signature of invoice and payroll redirection. It is also the cheapest single rule most organisations have not written.
• Record the DNS policy as it stood at evaluation time. Attacker domains rotate records within hours, and an analysis that cannot be reproduced next week is weak evidence in any proceeding.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on Email Header is producing anything, and they are worth baselining before you change process or tooling.

• Median time from first user report to gateway block and mailbox removal of all delivered copies of a campaign.
• Proportion of reported phishing submitted as original message files rather than forwarded copies, which measures whether reporting tooling works.
• Campaign clustering yield: additional messages found across the estate per initial report, indicating whether fingerprinting is being used rather than atomic indicators.
• Percentage of owned domains at DMARC enforcement, and the count of unauthorised sending sources eliminated from aggregate reports.
• Rate of successful credential harvest per delivered phishing message, tracked over time as the outcome measure controls are meant to move.
• Share of indicators shared with partners that later produced a detection elsewhere, measuring the real value of sharing.
• Time from incident closure to deletion of retained message files containing personal data, against the documented retention schedule.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

• Any header added before your own trust boundary can be forged, and attackers routinely insert fake Received lines to mislead analysts.
• Display name spoofing works without touching the domain, so a passing SPF check never means a message is legitimate.
• Forwarding and mailing lists break SPF and rewrite headers, producing authentication failures on entirely genuine mail.
• Legacy originating-address headers are absent or fabricated in most modern clients and must not be treated as authoritative.
• Shared sending platforms mean one address serves thousands of unrelated customers, making address-level blocking disproportionate.
• Timestamps come from relay clocks that drift and may be set to the wrong timezone, so treat small differences with caution.

Legal and ethical considerations

Email content is personal data and is often privileged. Restrict analysis to messages your organisation lawfully holds or that were reported to you, and apply access controls to mailbox exports. Preserve the original message file with a hash where the incident may lead to litigation or prosecution. Share indicators rather than message bodies when distributing to partners, and redact recipient identities. Reporting to abuse contacts and anti-phishing bodies is legitimate; active probing of sender infrastructure beyond passive lookups is not.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for Email Header, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 1 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

SPF and DKIM both passed. Is the message safe?

No. Authentication tells you the sending host was authorised by the domain that signed or published the policy, and attackers register and configure their own domains properly precisely so this happens. A message from a lookalike domain, or one using a genuine display name over an unrelated address, authenticates cleanly. What authentication does establish is whether a claimed brand domain actually sent the message, which is decisive when someone forwards an apparent invoice from a supplier. Use authentication to prioritise and to disprove claimed origin, never as a standalone verdict on legitimacy.

The user forwarded the phish. Can I still analyse it?

Partially. Forwarding rewrites the Received chain, usually invalidates DKIM and often re-encodes attachments, so origin and authentication analysis are compromised. You can still extract URLs, attachment hashes and body text for blocking and clustering. The fix is procedural: deploy a report button that submits the original message, or instruct users to attach the message rather than forward it. For anything heading toward litigation or prosecution, retrieve the original from the mail store or from the provider under legal process rather than relying on the forwarded copy at all.

How far back can I trust the Received chain?

Only as far as your own infrastructure. Every relay prepends its own Received line, so the top lines were written by systems you control and the lower ones by whatever the sender chose to claim. Attackers routinely insert fabricated Received headers implying an origin at a reputable provider. The last hop written by a machine you trust records the address that actually connected to you, and that is the highest-value single fact in the header. Everything below it is a lead requiring corroboration from passive DNS, hosting records or provider cooperation.

Should I report to the provider or block quietly?

Do both, in that order of urgency. Block and remediate first, because your users are the exposure. Then report to the hosting abuse contact, the mail provider and anti-phishing bodies, and notify the owner of any abused legitimate domain, who frequently does not know their server is relaying. Reporting removes infrastructure that would otherwise be reused against others and often produces faster takedowns than expected. What you should not do is probe the sender's infrastructure beyond passive lookups, which is unauthorised access and can also alert the operator.

Can header analysis attribute an attack to an actor?

It can cluster campaigns reliably and attribute to a toolkit or infrastructure set with reasonable confidence. Attribution to a named group or a state sponsor needs much more: overlapping infrastructure across time, code and tooling similarities, victimology consistent with known targeting, and usually non-public sources. Headers are strong evidence for infrastructure relationships and weak evidence for identity, since infrastructure is rented, shared and resold. Express this in your product with explicit confidence language, and keep infrastructure clustering conclusions separate from actor attribution conclusions.

What do I preserve if this becomes a legal matter?

The original message file with full headers, a hash of it, and a record of who exported it, from which mailbox, by what method and when. Also preserve mail gateway and message tracking logs covering the campaign window, any sandbox output, and DNS records as they stood at evaluation time with the query timestamp. Issue a legal hold on the affected mailboxes and send preservation requests to any external provider immediately, because both internal retention policies and provider retention windows will otherwise destroy the record within weeks.

How do we handle privileged or personal content in reported mail?

Restrict access to the security team members handling the incident, log access, and store exports encrypted with a defined retention period rather than in a shared mailbox. When sharing externally, distribute indicators and fingerprints rather than message bodies, and redact recipient identities. Legal privilege travels with the content, so involve counsel before circulating anything from a mailbox belonging to legal or executive functions. Delete retained message files once the incident is closed unless a legal hold applies, and record the deletion against the retention schedule.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

• RFC 5322 and RFC 5321, defining message header syntax, SMTP transport and the construction of trace fields.
• SPF, DKIM and DMARC specifications, which define how a domain authorises senders, signs messages and publishes handling policy.
• ARC and BIMI specifications, which address authentication survival across forwarding and brand indicator display respectively.
• M3AAWG best common practices for messaging abuse handling, sender authentication deployment and abuse reporting.
• ISO/IEC 27037 on identification, collection and preservation of digital evidence, applied to original message files and logs.
• UK GDPR and EU GDPR, which govern lawful basis, access control and retention for mailbox exports containing personal data.
• Computer misuse legislation, which prohibits active probing of sender infrastructure and any access to mailboxes you are not authorised to hold.
• NIST Special Publication 800-61 on computer security incident handling, which frames the containment, eradication and recovery cycle.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

1. RFC 5322 Internet Message Format — Internet Engineering Task Force. Canonical specification of email header fields and syntax.
2. IETF Datatracker — Internet Engineering Task Force. Repository of SPF, DKIM, DMARC and ARC specifications and their revisions.
3. DMARC.org — DMARC.org. Reference material on domain-based message authentication policy and reporting.
4. M3AAWG published documents — Messaging, Malware and Mobile Anti-Abuse Working Group. Industry best practice for authentication deployment and abuse handling.
5. APWG — Anti-Phishing Working Group. Industry association operating phishing reporting and data exchange.
6. MITRE ATT&CK phishing techniques — MITRE. Technique definitions for phishing delivery used for coverage mapping.
7. NIST Computer Security Incident Handling Guide — National Institute of Standards and Technology. Framework for incident response phases applied to email-borne intrusions.
8. NCSC email security and anti-spoofing guidance — National Cyber Security Centre, United Kingdom. Government guidance on DMARC enforcement and phishing defence.
9. MISP threat sharing platform — MISP Project. Open platform for structured indicator sharing between organisations.
10. URLScan.io — urlscan GmbH. Sandboxed URL analysis service capturing redirect chains and landing pages.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: parses headers at scale to extract sending infrastructure, authentication outcomes and cross-campaign clusters. Explore the platform, or browse the rest of the library by following any tag above.