Email Inspector
Use this view when you need the technical evidence behind the message: who sent it, how it traveled, and what the headers support.
Email
Email Inspector
One shared email intake, focused here on evidence: sender identity, transport hops, authentication, and extracted indicators.
Phishing Check
Open the phishing-first view when the main question is whether to quarantine, escalate, or verify a likely lure.
Switch to Phishing Check
Use the original raw message or full header block. The same intake also powers Phishing Check, and the email rules now review common lure patterns in multiple languages alongside evidence and transport context.
How to get raw headers
Run the inspector to populate sender identity, authentication results, extracted IOCs, and first-pass phishing or spam signals.
Quick Answers
When to use Email Inspector
These short answers are intended for both human readers and answer engines.
What email input gives the best result?
The best input is the original raw message source or the original full header block from the mailbox that received the message.
What does Email Inspector analyze?
Email Inspector analyzes sender identity, authentication results, transport hops, sender-domain DNS, and extracted indicators such as URLs, domains, IPs, and email addresses.
When should I switch to Phishing Check?
Switch when the technical evidence is already enough and the main decision becomes whether the message is a credential lure, consent lure, payment fraud, or another phishing attempt.
Do both pages need raw headers?
Usually yes. Good phishing decisions still depend on transport context, sender identity, and authentication signals, not only the visible wording of the message.
Why This Workflow Exists
Email review needs transport context, not only visible sender text.
The page is meant for cases where a human needs to understand who sent a message, how it moved, and whether the visible identity matches the supporting evidence.
Identity is layered
`From`, `Reply-To`, `Return-Path`, SPF, DKIM, and DMARC do not always tell the same story. The workflow is built to line those signals up in one readable view.
Mail flow adds evidence
Received headers, relay timing, source IPs, and reverse DNS are useful when the message looks normal at a glance but the transport path still feels wrong.
Publishing posture matters too
Sender-domain MX, SPF, DMARC, DKIM, and BIMI checks are included because suspicious messages often ride on top of weak or incomplete sender-domain configuration.