Email Intelligence (EMAILINT): Intelligence Discipline Guide

An email address is three things at once: an identifier, a routing instruction and a piece of infrastructure history. Email intelligence reads all three and knows which of them is evidence.

What Email Intelligence is as a discipline

Email intelligence is the analysis of email addresses, message headers and mail infrastructure: domain and mail exchanger configuration, SPF, DKIM and DMARC policy, transit path reconstruction from received headers, sending platform fingerprints, authentication results, and the public exposure of an address in listings and breach corpora. It supports phishing and business email compromise investigation, infrastructure attribution, sender verification, and corroboration in fraud and due diligence work where an address is one of the few durable identifiers available.

Sub-methods include header parsing and hop-by-hop timeline reconstruction, authentication result interpretation, mail server and transport security enumeration, domain provenance through registration and DNS history, and infrastructure clustering across separate campaigns. In the cycle it sits in processing: it turns an artefact you already lawfully hold, a message or an address, into pivots for domain, network and identity work rather than being a collection discipline in its own right.

Why it matters

Email intelligence answers whether a message truly originated where it claims, which servers actually handled it and when, and whether the sending domain was authorised to send at all. It links apparently separate incidents through shared infrastructure, and it establishes that the domain used in a six-figure payment diversion was registered eleven days before the invoice, which is the fact that changes how a fraud is understood.

What analysts actually look for

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

• Received header chains giving the true originating server, the intermediate hops and the timing gaps between them.
• SPF, DKIM and DMARC results showing whether the sending domain authorised and cryptographically signed the message.
• Envelope sender and reply-to values diverging from the display address, the classic payment diversion pattern.
• Mail platform fingerprints in message identifiers, MIME boundary strings and vendor-specific headers.
• Domain age, registrar and nameserver history placing a lookalike domain days before the fraudulent request.
• Shared mail exchangers, certificates or hosting clustering separate campaigns to a single operator.
• Breach corpus exposure indicating where an address has been used and whether credentials are circulating.
• Homoglyph, subdomain and display-name spoofing built to survive a quick visual check by a busy recipient.

Where the data comes from

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

• RDAP and WHOIS services — Domain registration dates, registrar, nameservers and status, with RDAP giving structured, current records
• Public DNS resolvers — Live MX, SPF, DKIM selector, DMARC and MTA-STS records that define who may send for a domain
• MXToolbox — Mail configuration, delivery path and blocklist checks without needing to send test traffic
• Have I Been Pwned — Whether an address appears in known breach corpora, and which services were involved
• Spamhaus and similar reputation lists — Whether sending infrastructure is listed, and the category of abuse recorded against it
• Message header analyser tools — Structured parsing of received chains and authentication results from a raw message you hold
• Certificate Transparency logs — Certificates issued for mail and webmail hostnames, revealing infrastructure and issuance timing
• Internet Archive Wayback Machine — Historic pages showing where an address was published and by which organisation

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 with full headers, hash it, and work only on copies so the evidential original stays untouched.
2. Parse headers and rebuild the path — Read the received chain from the bottom upward, reconstructing the hop timeline and noting clock skew between servers.
3. Evaluate authentication — Check SPF, DKIM and DMARC results against the claimed sending domain, and read the domain's published policy rather than assuming it.
4. Enumerate the infrastructure — Examine registration, DNS, mail exchanger and certificate data for the sending domain and its close variants.
5. Pivot to related activity — Cluster on shared infrastructure, registration patterns and platform fingerprints to find other messages from the same operator.
6. Check exposure passively — Review breach and reputation data without probing servers or sending mail that would alert the subject.
7. Document with raw evidence — Report findings with the raw headers attached, so a reviewer can verify every hop and result independently.

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.

Applied in these mission domains

• Fraud & Identity

Operates on these data points

• Email Address — Electronic mail address tied to an individual or organization.
• Phone Number — Telephone number for voice, SMS, or messaging identification.
• Person / Name — A named individual — the subject of identity resolution and profiling.
• Domain Name — Human-readable address that maps to IP infrastructure via DNS.
• URL — Uniform Resource Locator pointing to a web resource.
• Cryptocurrency Address — Blockchain wallet address for receiving or sending crypto assets.

Related disciplines

• Identity Intelligence — Resolving and Verifying Who Someone Is
• Telephony Intelligence — Phone Numbers, Networks, and Telephony Data

Inside the platform: where Email Intelligence 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:

• discipline.php?d=EMAILINT — Discipline hub
• source-catalog.php?disc=EMAILINT — Source catalogue filtered to this discipline
• email-profile.php — Email Address profile
• phone-profile.php — Phone Number profile
• search.php — Person / Name profile
• url-profile.php — Domain Name profile
• 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:

• Threat Hunt
• Auto-Collect Feeds
• Enrichment → Local
• 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. Evaluate 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. Document with raw evidence 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 Intelligence

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

Defensive cyber and counter-intelligence elements analyse phishing and spear-phishing directed at personnel and contractors, using headers and infrastructure indicators to attribute campaigns and to harden mail defences. It feeds indicator sharing with partner networks, supports insider threat and operational security assessment when service addresses appear in breach corpora, and informs training targeted at the lures actually being used. Constraints are absolute: analysis is limited to messages lawfully held by the organisation, mailbox access requires proper authority under the applicable regime, and any activity against external mail infrastructure beyond passive enumeration crosses into operations requiring entirely separate authorisation.

🕵 National intelligence

Agencies use email artefacts as attribution material within a broader technical picture: sender infrastructure, mail platform fingerprints, authentication configuration and domain provenance cluster campaigns and link them to known actors. The value is that infrastructure choices persist across campaigns even when lures and payloads change. Handling matters because message content held lawfully may contain personal data of uninvolved third parties, requiring minimisation, and because indicators shared with partners must be sanitised of victim-identifying detail. Reporting distinguishes infrastructure attribution, which is often solid, from actor attribution, which usually is not.

👮 Law enforcement

Investigators use email analysis in fraud, business email compromise, harassment and intrusion cases. Evidence must come from a lawful source: the victim's own mailbox with consent or authority, a production order to a provider, or seized devices under warrant. Preserve the original message with full headers in its native format, hash it, and document extraction. Header analysis supports the timeline and identifies the sending platform, but subscriber data, logs and content beyond what the complainant holds require legal process and often an MLAT. Interception of mail in transit requires a specific warrant and is otherwise criminal.

🔍 Private investigation and corporate security

Corporate investigators analyse phishing and business email compromise reported by their own organisation or client, verify sender legitimacy in due diligence, and use address artefacts as pivots in fraud work. The boundary is unambiguous: analyse only messages that you or your client lawfully hold. A private actor must never access a mailbox, credentials or traffic without authority, must not probe or test third-party mail servers beyond passively published DNS records, and should avoid verification techniques that alert the subject. Possession and querying of breach corpora is restricted in several jurisdictions depending on purpose.

📰 Journalism and OSINT media

Journalists use email artefacts to authenticate leaked material and to verify that correspondence is genuine. Header analysis, authentication results and infrastructure consistency can support or undermine a claim that a message is real, though headers can be fabricated and their absence in a forwarded copy proves nothing. Source protection is critical: forwarded messages carry the source's address and routing detail, so material must be handled and redacted before it goes anywhere near publication. Right of reply should go to the apparent sender, and publication of third-party addresses appearing in correspondence requires a public interest justification.

🌍 NGO, humanitarian and human rights

Human rights and civil society organisations are heavily targeted by phishing and are often the first to see novel campaigns against activists. Analysis of messages staff receive supports collective defence, feeds civil society threat-sharing communities and informs protective guidance. Do-no-harm requires care with messages that identify at-risk individuals, so indicators are shared while victim detail is stripped. Duty of care includes not blaming targeted staff, providing practical support after a compromise, and recognising that reporting a targeted campaign publicly can escalate risk for the people targeted.

🎓 University and research

Researchers study phishing, authentication deployment, spam infrastructure and email ecosystem measurement. Reproducibility requires publishing measurement methodology, collection dates and, where possible, anonymised datasets, since mail infrastructure changes rapidly. Ethics approval is required for work involving message content or identifiable addresses, and deceptive phishing studies on human subjects raise significant additional review requirements. Active measurement against third-party mail servers must respect acceptable use norms and opt-out conventions. Breach corpora present acute ethical and legal problems and are generally unsuitable for research without a specific approved framework.

Playbook: working Email Intelligence 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 — Confirm lawful possession

Before any analysis, establish that the message is lawfully held: reported by a recipient in your organisation, supplied by a client who received it, obtained under authority, or produced under legal process. Record the provenance and the authority. Analysis of material you do not lawfully hold is not a technical question but a criminal one in most jurisdictions. A good output is a provenance record for every message in the case. Stop and escalate if the source of the material cannot be established.

Phase 2 — Preserve the original

Capture the message in its native format with full headers intact, not as a screenshot or a copy pasted body. Export as .eml or .msg, hash it, and record who exported it, from where and when. Forwarding a message rewrites headers and destroys the evidence, so instruct reporters to attach rather than forward. A good output is a hashed original with an extraction note. Stop when the original is preserved in a way that can be handed to an evidential process later.

Phase 3 — Parse headers hop by hop

Read the Received headers from the bottom upward to reconstruct the transit path, noting each server, its claimed identity, the IP addresses and the timestamps with offsets. Look for inconsistent time sequencing, unexpected hops, mismatches between the claimed sending host and the connecting address, and headers inserted by intermediate security products. A good output is a hop-by-hop timeline with each claim labelled as asserted or verified. Stop when the path is reconstructed as far as your own trusted boundary, which is the last point you can rely on.

Phase 4 — Read authentication results

Interpret SPF, DKIM and DMARC results as recorded by the receiving system: whether the envelope sender aligned, whether a DKIM signature validated and over which headers and body, and what DMARC policy applied. Understand that a pass means the mechanism succeeded, not that the message is trustworthy, and that failures are frequently caused by forwarding and mailing lists. A good output is an authentication assessment stating what each result does and does not establish. Stop before treating an authentication pass as proof of legitimacy.

Phase 5 — Fingerprint the sending platform

Identify the mail user agent, message identifier format, boundary string patterns, header ordering and encoding choices, which together fingerprint the sending software or bulk platform. These artefacts are stable across a campaign even when lures change, and they cluster messages that otherwise look unrelated. A good output is a platform fingerprint recorded in a form that can be matched against future messages. Stop when the fingerprint is specific enough to be discriminating rather than generic to all mail.

Phase 6 — Enumerate published mail configuration

Query publicly published DNS records for the domains involved: MX records, SPF policy, DKIM selectors where discoverable, DMARC policy and reporting addresses, and MTA-STS or TLS reporting records where present. This is passive lookup of published data, not probing. Do not connect to third-party mail servers to test behaviour or verify addresses. A good output is a configuration profile per domain with the query date. Stop at published records; anything beyond that requires authority you do not have.

Phase 7 — Establish domain provenance

Check registration data through RDAP, the creation and expiry dates, the registrar, name server history and certificate transparency records for the domain. Recently created domains that closely resemble a legitimate brand, registered days before a campaign, are a strong signal. Record the date of every lookup because this data changes. A good output is a domain provenance note with dated evidence. Stop when the registration and infrastructure history is documented to the depth the case requires.

Phase 8 — Cluster the campaign

Compare the message against others held: shared infrastructure, reused sending platform fingerprints, similar lure structure, common link shorteners or hosting, identical attachment characteristics, and overlapping timing. Cluster on the durable technical artefacts rather than on the wording, which changes constantly. A good output is a defined cluster with the shared attributes evidenced per message. Stop before extending the cluster on similarity of theme alone, which is weak and produces false grouping.

Phase 9 — Assess the address as an identifier

Where the requirement is due diligence or fraud investigation rather than incident response, treat the address as one weak identifier among others: its domain provenance, its public appearance in filings, listings and advertisements, and its presence in breach notification services. Do not attempt mailbox verification techniques that connect to servers or alert the subject. A good output is an assessment of what the address corroborates and how weakly. Stop before asserting identity from an address alone.

Phase 10 — Pivot into other disciplines

Convert email artefacts into requirements elsewhere: domains into infrastructure analysis, hosting into network attribution, brand impersonation into a takedown request, addresses into corporate registry checks where they appear in filings. Email analysis is a processing discipline whose value is mostly in the pivots it generates. A good output is a set of specific, taskable follow-ups. Stop when the pivots are specific enough that another analyst could act on them without re-reading the message.

Phase 11 — Minimise and protect content

Messages contain personal data about senders, recipients and third parties who are not the subject of the investigation. Redact or restrict access to content not needed for the analysis, hold the material under access control, and set a retention period. When sharing indicators with partners or communities, strip victim-identifying detail and internal routing. A good output is a shareable indicator set that carries no unnecessary personal data. Stop when what is retained and what is shared are both proportionate to the purpose.

Phase 12 — Report and remediate

Report findings with the technical basis stated and the confidence bounded: infrastructure clustering is usually well supported, actor attribution usually is not. Feed indicators into mail filtering, awareness training based on the actual lures observed, and any authentication hardening the analysis showed to be missing. Where a crime is disclosed, follow the reporting route. A good output is a report that produces a defensive change rather than an archive entry. Stop when the remediation actions have owners and dates.

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
RDAP registration data services	Open	Structured domain registration data including registrar, creation and expiry dates, status codes and contacts where published.	Establishes domain age and registrar for sender and link domains, which is often the strongest single signal.
Certificate transparency logs	Open	Public append-only logs of issued TLS certificates including subject hostnames and issuance timestamps.	Reveals related hostnames and dates infrastructure was stood up, linking campaign domains that share provisioning patterns.
IANA registries for protocol parameters	Open	Authoritative registries for message header field names, media types, port assignments and other protocol parameters.	Reference for whether a header field is standard, provisional or non-standard when interpreting unusual headers.
RFC Editor archive	Open	Canonical text of internet standards including message format, SMTP, SPF, DKIM, DMARC and related specifications.	Definitive reference for what each header and authentication result actually means, rather than tool interpretations.
DMARC.org resources	Open	Documentation and deployment guidance on domain-based message authentication, reporting and conformance.	Reference for interpreting DMARC policy, alignment and aggregate reporting when assessing sender configuration.
M3AAWG best practices	Open	Industry best current practice documents on messaging abuse, authentication deployment, and mailbox provider expectations.	Establishes what a competently run mail domain should look like, providing the baseline anomalies are judged against.
Have I Been Pwned	Open	Index of email addresses appearing in known data breaches, with breach descriptions, dates and exposed data categories.	Establishes public exposure of an address and possible credential compromise routes, without exposing the underlying data.
Internet.nl	Open	Open test service reporting on modern internet standards deployment for domains including mail authentication and transport security.	Assesses published mail security posture of a domain from published records rather than by probing infrastructure.
MXToolbox	Registration	Lookup service for MX, SPF, DMARC, blacklist status and mail configuration diagnostics for a domain.	Rapid consolidated view of published mail configuration during triage of a suspicious sending domain.
abuse.ch threat intelligence feeds	Open	Community feeds covering malware distribution infrastructure, malicious URLs and associated indicators.	Checks whether infrastructure in a message is already known malicious, avoiding rediscovery and adding corroboration.
MITRE ATT&CK	Open	Knowledge base of adversary tactics and techniques, including phishing and initial access behaviours observed in intrusions.	Provides consistent technique vocabulary for describing what a campaign attempted, enabling comparison across reports.
National CERT and CISA advisories	Open	Government advisories on active phishing and business email compromise campaigns, with indicators and mitigations.	Correlates locally observed campaigns with nationally reported activity and provides authoritative mitigation guidance.
IC3 and national fraud reporting bodies	Open	Reporting channels and published statistics on business email compromise and internet-enabled fraud.	The lawful reporting route for observed fraud and a source of typology data for what current campaigns look like.
Company registries and official filings	Registration	Registered company details including contact information appearing in statutory filings and public registers.	Corroborates whether an address is genuinely associated with a company when used as a due diligence identifier.

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 Intelligence. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

• Header parsing and visualisation tools — Reconstruct the hop sequence and present timestamps and authentication results clearly. Limitation: they display asserted values as though verified, so the analyst must still distinguish claims from confirmed facts.
• Authentication result interpreters — Explain SPF, DKIM and DMARC outcomes recorded by the receiving system. Limitation: results reflect the receiver's evaluation at the time, and forwarding or mailing lists routinely cause legitimate failures.
• RDAP and DNS lookup clients — Retrieve published registration and DNS records for domains under examination. Limitation: registration data is heavily redacted for privacy in many regions, limiting what can be established about a registrant.
• Certificate transparency search — Finds hostnames sharing certificate issuance patterns with a suspect domain. Limitation: reveals only names that were certificated, so infrastructure using no TLS or wildcards stays invisible.
• Attachment and URL detonation sandboxes — Execute suspicious content in isolation to observe behaviour. Limitation: evasive samples detect analysis environments, and detonation can alert the operator that a target reported the message.
• Indicator management platforms — Store, tag and share observed infrastructure indicators with communities in structured formats. Limitation: sharing must strip victim-identifying data, which is easy to overlook when exporting bulk indicators.
• Breach exposure notification services — Report whether an address appears in known breach corpora and which data categories were exposed. Limitation: they establish exposure, not compromise, and handling the underlying corpora is legally restricted in several jurisdictions.
• Passive DNS services — Show historic resolution of domains to addresses, revealing infrastructure reuse over time. Limitation: coverage varies by sensor network and gaps are invisible, so absence of a record means very little.

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.

• Threat Hunt — Runs saved hypotheses against the corpus and surfaces what matches, with the query preserved as a versioned artifact.
• Auto-Collect Feeds — Pulls the registered feed set server-side on a schedule, recording per-feed status so a silently dead feed is visible.
• Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
• 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:

• Only the headers added by infrastructure you control or trust are reliable. Everything below your trusted boundary is an assertion by an unknown party, and treating the whole chain as evidence is the most common beginner error.
• Ask reporters to attach the message rather than forward it. Forwarding rewrites headers and destroys exactly the routing evidence the analysis depends on, and the original is usually unrecoverable afterwards.
• An authentication pass means a mechanism succeeded, not that a message is honest. Attackers routinely register domains and configure SPF, DKIM and DMARC correctly, precisely because a pass reduces scrutiny.
• Authentication failures are more often caused by forwarding, mailing lists and misconfiguration than by spoofing. Diagnose the cause before treating a failure as evidence of attack, or you will chase your own mail flow.
• Sending platform fingerprints outlast lure content. Message identifier format, boundary strings, header ordering and encoding choices cluster campaigns whose visible text has been completely rewritten.
• Domain creation date relative to campaign date is one of the strongest single signals available, and it is free. A domain registered four days before the message landed rarely has an innocent explanation in a targeted attack.
• Stop at published DNS records. Connecting to a third-party mail server to test behaviour or verify an address exceeds passive enumeration, may breach computer misuse law, and can alert the operator you are investigating.
• Address verification techniques that touch remote servers also touch the target. Silent verification is not silent, and in fraud and due diligence work the alerting cost frequently exceeds the value of the confirmation.
• Strip victim detail before sharing indicators. Internal routing headers, recipient addresses and organisational identifiers leak into indicator exports routinely, and once shared with a community they cannot be recalled.

Measuring whether it is working

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

• Proportion of analysed messages preserved as hashed native-format originals with full headers, rather than as forwarded copies or screenshots.
• Median time from user report to indicator deployed in mail filtering, measured for campaigns targeting the organisation.
• Campaign clustering yield: number of previously unlinked messages connected to a known cluster through durable technical artefacts rather than lure similarity.
• Reporting rate by staff for suspicious messages, tracked alongside false report rate, as a measure of whether awareness training reflects the lures actually in use.
• Share of shared indicator sets audited as free of victim-identifying detail before release to partners or communities.
• Authentication posture of domains the organisation controls, measured by DMARC enforcement level and alignment rate, as a preventive outcome.
• Proportion of analyses that generated a specific taskable pivot into another discipline, rather than concluding as a standalone incident record.

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

• Trusting the display name or the From header, both of which are trivially forged and mean nothing alone.
• Reading received headers in the wrong order or ignoring clock skew, producing an impossible timeline.
• Treating a DMARC pass as proof of legitimacy, when a lookalike domain passes its own policy perfectly.
• Probing mail servers or sending test messages, which tips off the subject and can constitute unauthorised access.
• Handling breach corpora carelessly, which is often unlawful and always risky to the people in them.
• Assuming a shared mail provider indicates a shared operator, when millions of tenants share the same platform.

Legal and ethical considerations

Analyse only messages that you or your client lawfully hold. Never access mailboxes, credentials or traffic without authority, since interception and unauthorised access are criminal in most jurisdictions. Email addresses are personal data, so apply lawful basis, minimisation and retention rules, and note that possessing or querying breach corpora is restricted in several jurisdictions depending on purpose. Avoid verification techniques that alert the subject, and preserve originals with hashes if the message may become evidence.

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 Intelligence, 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 6 data points, 1 mission domains, 2 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Which headers can actually be trusted?

Only those added by mail infrastructure you control or explicitly trust, which in practice means the headers inserted from your trusted boundary inward. Everything below that was written by systems outside your control and can be fabricated wholesale, including entire fabricated Received chains designed to make a message look as though it traversed legitimate infrastructure. Read from the bottom upward and identify where your own systems first touched the message; treat everything below that as asserted. Timestamps from untrusted hops are unreliable, and inconsistent time sequencing across the chain is itself a useful indicator of fabrication.

Does a DMARC pass mean the message is legitimate?

No. It means the sending domain's authentication mechanisms succeeded and aligned according to policy. Attackers frequently register domains, publish SPF and DKIM records and configure DMARC correctly, because doing so improves deliverability and reduces scrutiny. A pass on a lookalike domain is entirely expected in a competent campaign. Conversely, failures on legitimate mail are common because forwarding and mailing lists break SPF alignment and can invalidate DKIM signatures. Use authentication results to understand what the sending domain claims and how the receiver evaluated it, then assess the domain itself.

Can I check whether an email address exists?

Not by any method that touches the remote mail server, which is where every convenient technique goes. Connecting to a third-party server to probe recipient acceptance exceeds passive enumeration, may engage computer misuse law depending on jurisdiction, and frequently alerts the operator. Commercial verification services perform the same probing on your behalf and carry the same problems. The defensible approach uses passive evidence: whether the address appears in public filings, listings, advertisements or archived pages, whether the domain has valid MX records published, and whether the address appears in breach notification indexes.

Is it lawful to use breach data in an investigation?

It depends heavily on jurisdiction, purpose and how the data is handled, and the answer is often no for private actors. Several jurisdictions restrict possession and processing of data known to derive from unlawful access, and data protection law applies to the personal data within regardless of how it was obtained. Notification services that report whether an address appears in a breach, without exposing the underlying records, are a materially safer route and usually sufficient for the analytic question. Obtain legal advice before ingesting corpora, and never use breach data to access accounts, which is a separate offence.

How do you cluster a phishing campaign reliably?

On durable technical artefacts, not on the text. Lures are rewritten constantly, but sending platform fingerprints persist: message identifier construction, MIME boundary patterns, header ordering, encoding choices and mail user agent strings. Add infrastructure overlap such as shared hosting, name servers, certificate issuance patterns and registrar and creation-date clustering, plus attachment characteristics and link shortener reuse. Any single artefact is weak; the combination is what makes a cluster defensible. Record the artefacts explicitly per message so a reviewer can test the grouping rather than accepting an assertion of similarity.

What can email analysis establish about who is behind a campaign?

Usually a great deal about infrastructure and very little about people. You can often show convincingly that a set of messages came from the same operation, using the same tooling and provisioning patterns, and sometimes link them to previously reported activity. Moving from that to naming an individual or a state requires evidence that email artefacts do not contain and that private practitioners generally cannot obtain lawfully. Report infrastructure clustering with the confidence it deserves and actor attribution with the caution it deserves, keeping the two clearly separated in the product.

What should never be done with a suspicious message?

Do not click links or open attachments outside an isolated environment, do not reply or engage with the sender, do not forward it as a normal message since that destroys headers, and do not probe or attack the sending infrastructure. Do not access any mailbox other than one you are authorised to access. If the message contains what appears to be stolen data, restrict access immediately and take legal advice before further handling. Report it through the organisation's channel and, where fraud is involved, to the relevant national reporting body promptly, because recovery timelines for payment fraud are extremely short.

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 internet message format and RFC 5321 SMTP, defining header structure, the Received trace field and the transport semantics analysis relies on.
• SPF, DKIM and DMARC specifications, governing sender authorisation, cryptographic signing and policy-based alignment evaluation.
• ISO/IEC 27037, governing identification, collection, acquisition and preservation of digital evidence including message files.
• Computer misuse and unauthorised access legislation such as the UK Computer Misuse Act and the US Computer Fraud and Abuse Act, which prohibit mailbox access and server probing without authority.
• Interception of communications regimes, which criminalise access to mail in transit absent a specific warrant and place such collection outside private practice.
• GDPR and equivalent regimes, which treat email addresses and message content as personal data with lawful basis, minimisation and retention obligations.
• M3AAWG best current practices on messaging abuse, authentication deployment and abuse reporting between providers.
• MITRE ATT&CK phishing and initial access techniques, providing standard vocabulary for describing observed campaign behaviour.

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. Internet standards archive including RFC 5322, SPF, DKIM and DMARC — RFC Editor. Canonical specifications for message format and mail authentication
2. DMARC deployment resources — DMARC.org. Documentation on domain-based authentication, reporting and conformance
3. Messaging abuse best current practices — Messaging, Malware and Mobile Anti-Abuse Working Group. Industry practice on authentication deployment and abuse handling
4. Protocol parameter registries — Internet Assigned Numbers Authority. Authoritative registries including message header field names
5. Have I Been Pwned — Have I Been Pwned. Index of addresses appearing in known data breaches
6. Internet.nl standards test — Internet.nl partners. Open assessment of published mail authentication and transport security
7. Certificate transparency search — crt.sh. Public log of issued TLS certificates used to link campaign infrastructure
8. Advisories on phishing and business email compromise — US Cybersecurity and Infrastructure Security Agency. Authoritative campaign advisories and mitigation guidance
9. Internet Crime Complaint Center — US Federal Bureau of Investigation. Reporting channel and statistics for internet-enabled fraud including business email compromise
10. ATT&CK knowledge base — MITRE. Standard vocabulary for adversary techniques including phishing

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: header parsing, authentication checks and infrastructure pivots from a single preserved message. Explore the platform, or browse the rest of the library by following any tag above.