From an email to a reviewable evidence record.

Choose the right evidence source

Start an email investigation with the strongest source you are authorized to submit. The canonical modes are plain_text, raw_eml, and trusted_receiver_event. The result declares available evidence and gaps instead of presenting missing checks as verified facts.

Upgrading a completed same-workspace investigation links a strictly stronger evidence stage. That lineage is user-linked context, not independent proof of the same message or improved classifier accuracy.

Investigate pasted text or an original email

• For text, provide a subject, body, or both. Subject-only input is supported; include the relevant message wording and visible links.
• For .eml, upload the original RFC822 export. The browser declares its exact byte size and SHA-256, reserves a private upload, and sends original bytes directly to authorized Storage.
• Analysis rechecks size/hash, parses the message, evaluates evidence, invokes required classifiers, and records the final result or explicit failure.
• Review the available evidence, coverage, indicators, policy disposition, and recommended next action.

Reservations are bound to the authorized tenant/user/key/integration. Expired, foreign, or mismatched uploads fail. Idempotency can replay the existing finalized result rather than repeat inference or create duplicate evidence.

Input and parsing limits

Browser, route, transport, decoded parser, and model sampling limits are independent. Larger Storage allowances do not permit unsupported media or bypass the email route contract.

Read authentication and identity correctly

Raw-byte checks retain protocol, result, source quality, DNS observation, and failure context. DKIM checks signatures; ARC checks chain structure/signatures; DMARC uses available validated alignment and domain policy. SPF requires observed SMTP client, HELO, and envelope facts, so it is unavailable for an ordinary uploaded .eml.

From, Reply-To, Return-Path, Message-ID, signed domains, and URL domains are compared for identity relationships. A display name or shared organizational domain does not prove a legitimate person or exclude a compromised mailbox. Uploaded authentication headers remain claims rather than our independent receiver verdict.

Embedded links and attachment evidence

Email v2 can extract up to 50 unique URLs as child artifacts. Swift classifies URL strings with deterministic supporting patterns; the standalone Link API accepts one URL per request. The current version does not fetch webpages, resolve shortened links, or follow redirects. Swift operates on URL strings rather than executing the destination as a browser.

Attachment evidence includes filenames/extensions, MIME/signature patterns, sizes, hashes, and suspicious naming/type combinations. Contents are not executed or given an exhaustive malware verdict. Archived media/deepfake/learning references are not active detector features.

Infrastructure, GeoTrace, and threat intelligence

GeoTrace labels message-carried Received claims separately from the controlled receiver boundary. Only eligible public infrastructure is enriched; private/special/reserved addresses are excluded from public geo/reputation queries.

The reference pilot uses IPinfo for infrastructure context, DNS for authentication, RDAP for registration, and configured AbuseIPDB checks for reputation context. Provider failures and missing fields stay explicit. Map lines are illustrative; coordinates are approximate and do not locate a person or establish a physical mail route.

Models, scoring, and failed evidence

The documented active runtime hosts the pretrained MailGuard email classifier and Swift URL classifier on private AWS CPU services. Vercel assumes a scoped OIDC workload role to invoke a private Lambda proxy. Exact model identity/revision/labels are checked; unexpected or failed responses remain explicit errors.

MailGuard uses bounded text sampling—up to three approximately 1,200-character chunks—and the runtime is token bounded. It does not classify every byte of an accepted original file. MailGuard’s current low/high score boundaries are 0.2 and 0.7, with the middle uncertain; these are thresholds, not calibrated correctness or published accuracy.

Final correlated risk uses usable evidence, deterministic floors, interactions, and configured policy. Identity/authentication concerns can require review. Required failures mark degradation and apply the failure policy; missing evidence does not yield a benign default. See model disclosures and limitations.

Campaign Memory and progressive lineage

Campaign matching compares normalized domains, IPs, and attachment hashes only within the same organization. An exact attachment hash can qualify alone; other connections need sufficient weighted support across entity families. Related investigations show why a match was made.

Common infrastructure/provider identifiers can overlap in benign email. A match is reviewable context, not global campaign or actor attribution. Progressive acquisition records stronger-stage linkage and retains original signed snapshots without independently proving the same message.

Saved reports, exports, and Evidence Passports

Reopen authorized investigations from the Dashboard and review Acquisition, GeoTrace, Campaign, and Passport context. Cases preserve analyst review and references to evidence. Email investigations and standalone scan-history/usage paths have distinct persistence contracts.

Supported API exports include JSON, CSV, observed-artifact JSON, and STIX. Browser report/PDF paths provide readable summaries. Keep the complete original signed package when independent verification matters; a PDF or redacted excerpt is not the unchanged canonical signed snapshot.

The Evidence Passport binds canonical evidence and manifest hashes with Ed25519. Production uses a dedicated key; the retained snapshot is reopened rather than reconstructed from current report rows. Full verification checks signature, evidence hash, manifest hash, key fingerprint, and configured issuer trust.

Trusted receiver and delivery workflow

The reference pilot uses a hardened STARTTLS-required Postfix edge and a loopback Node receiver. Controlled transport facts accompany raw email to authenticated internal analysis; arbitrary internet headers cannot grant trusted provenance. Analysis/policy/authentication outcomes control allow, warn, reject, or safe deferral.

Configured final delivery uses authorized Gmail API import for the pilot mailbox and a separate required-TLS relay path for the reporting group. Encrypted durable receipts and exact-marker reconciliation handle specific retry/ambiguous-outcome cases. An unresolved delivery defers; there is no universal exactly-once delivery guarantee.

Receiver status is workspace-assignment scoped and checks credentials, feature availability, quotas, observation freshness, TLS, and model readiness. The documented reporter runs every 60 seconds; observations older than 180 seconds are stale. Status refresh is not a new investigation or inference call.

Open your connected receiver. The private companion guide covers controlled sender/receiver demonstrations. It does not replace the production assignment, routing, and recipient setup.

Accounts, roles, and API access

Use Auth for email/password sign-in, account creation, confirmation/recovery, and logout. The current site access controller requires a verified session for workspace tools and these reference pages; it does not rely on a page being described as public in older copy.

Active membership and role authorize operations. Production session tokens use HttpOnly cookies. Scoped keys also check owner/membership, activation/expiry, status, feature availability, and quotas. A workspace label is not authorization.

Canonical API paths include /api/v2/phishing/analyze-text, /api/v2/phishing/uploads, /api/v2/phishing/analyze-upload, scoped evidence/export reads, and bounded /api/v2/phishing/verify-evidence. Read the developer guide alongside the actual route/OpenAPI contract.

Availability, progress, and error handling

The documented model operating window is 07:00–19:00 IST. Startup and warmed readiness are separate from an instance being running; SMTP is a separate service. Workspace quotas reset on UTC-day/month boundaries. Outage, overload, schedule, or quota failure can prevent or safely defer analysis/delivery.

Relevant responses distinguish invalid input (400), authentication (401), permission (403), unavailable/foreign resources (404), replay/conflict (409), expired upload (410), size (413), type (415), invalid evidence (422), quota/overload (429), and runtime/provider failures (5xx).

Optional progress is newline-delimited JSON, not WebSockets. Once streaming starts, an outer HTTP 200 can precede a failed final event; clients must inspect the final embedded status and result. A progress animation alone is not proof of persistence or delivery.

Data lifecycle and operational scope

Private uploads and derived records follow authorized retention and hold-aware lifecycle handling. Hashing lookup keys does not anonymize all evidence. Export and erasure requests are scoped governance workflows; erasure prepares review rather than automatically deleting every copy.

The review distinguishes current observations, earlier real tests, and deferred rollout work. Integrated quality benchmarks, sustained traffic/provider coverage, self-service multi-organization SMTP setup, and a fresh hosted disaster-recovery validation remain separate tasks.

Read Privacy, Security, Terms, and Limitations for the matching boundaries. Operators must validate each new deployment and delivery path rather than assume the pilot’s results apply universally.