An email asks your finance team to update a supplier’s bank details. Another asks an employee to sign in before their mailbox is suspended. Someone forwards the message to IT with a familiar question: is this phishing?
The person needs a useful answer. The analyst needs the original context. The organisation needs to know whether other people received the same message. Handling those three needs together is the purpose of Karst, the phishing and scam reporting platform we are developing at ObsidianCorps in Luxembourg.
Karst combines email inspection, reporting, privacy filtering and analyst review. It is self-hostable, with an isolated deployment for each operator. As of 22 September 2026, it remains pre-production: the reporting core is implemented, while production acceptance and several planned capabilities still require further work.
How do you check whether an email is phishing?
Start with the requested action. An unexpected payment change, credential request or attachment deserves verification through a channel you already trust. Avoid following the message’s links or using its contact details to verify the message itself. This is also the approach described in NIST’s phishing guidance.
Next, preserve the message in a form that supports analysis. A screenshot shows what the recipient saw, but leaves out headers and much of the underlying structure. The original email source or an exported .eml file gives an analyst more context about the sender, message routing, links and attachments.
A useful assessment considers several observations together: the claimed sender, the reply address, authentication results recorded in the headers, the destinations embedded in links and the language used to request action. No single observation proves that a message is legitimate. Our article on social engineering in the Greater Region explores the wider human context behind these requests.
Use the Karst Email Inspector for a one-off check
The public Karst Email Inspector accepts an .eml file or pasted raw email source, including headers and body, up to 10 MB. It examines observable signals and returns an explanation. You do not need to file a report to use this inspection path.
- Export the suspicious message or copy its original source from your mail application.
- Open the Inspector and upload the file or paste the source.
- Read the observations and their context, including any limitations caused by missing information.
- Use your organisation’s reporting procedure if the message needs investigation or you have already interacted with it.
The Inspector processes the submitted email content in memory. It does not write it to the reporting database or evidence vault, create a report, or dispatch threat intelligence. Connection metadata, such as an IP address, request time and response status, may appear in access logs. This is an analysis service that receives your submission; it is not analysis performed solely inside your browser.
The inspection covers recorded authentication results, message context, links, bounded attachment checks and embedded phishing, scam and spam rules. It does not visit the links. Attachment checks are not a claim that every file has undergone malware detonation. A result without detected warning signs is not a guarantee of safety.
What happens when you report a phishing email?
Reporting has a different purpose from a one-off inspection. It gives an operator evidence to investigate, review and connect with other reports. Karst’s implemented reporting clients include a web app, a Thunderbird add-on and an MV3 browser extension. Their use depends on the operator’s deployment and client configuration.
The reporting workflow has five stages:
- Submit: the reporter sends a suspicious message to the chosen Karst operator.
- Protect: the platform stores the original email as encrypted evidence.
- Analyse: parsing, privacy filtering and classification extract and assess relevant signals.
- Review: an analyst can inspect findings, access evidence when authorised and make accountable decisions.
- Act: reviewed indicators can leave through signed webhooks and local blocklists.
This creates a shared working context for reporting and investigation. It also keeps responsibilities visible: an automated finding, an analyst’s decision and publication of an indicator are distinct steps. Reporting through Karst does not automatically notify a national authority or replace an organisation’s incident escalation procedure.
Understand the email header analysis
Authentication results need careful interpretation, especially when someone forwards an email. Karst records SPF, DKIM and DMARC results carried in the submitted headers. Those are reported observations, not independent verification of the original delivery.
The latest implementation distinguishes directly reported messages, attached originals and forwarding wrappers. When an original message is attached, its authentication context is kept separate from the surrounding forward. A successful result on the wrapper must not be presented as a successful result for the original message.
This distinction matters in ordinary helpdesk work. A colleague can forward a suspicious email through a correctly configured corporate mail system. The forwarding message may pass authentication while saying nothing conclusive about the original sender’s request. Conversely, missing authentication information is not the same as a failed check.
Karst exposes these distinctions so an analyst can understand what the evidence actually supports. Authentication failures and spam markers alone do not establish a malicious verdict, and an authentication pass does not establish that the content is legitimate.
Connect individual reports into phishing campaigns
An isolated report may answer one employee’s question. Related reports can show that several people are being targeted. Karst’s analyst console supports incidents and campaign views, bringing related observations into a common investigation context.
That helps a team ask operational questions: are these messages connected, which evidence supports the assessment, and what should be reviewed before an indicator is published? Campaign correlation supports investigation; it does not establish who the attacker is or prove that every similar message is malicious.
The console also includes triage, evidence access, analyst overrides, approvals, appeals and audit history. These controls matter when a legitimate message is flagged or an initial assessment needs correction. The reporter and analyst need a way to revisit the decision with its context intact.
What changed in the latest Karst implementation?
The September 2026 work includes more explicit forwarding and authentication context, changes to evidence scoring, and an analyst comparison view. These are implementation updates; availability on a particular instance depends on its deployed version.
Related signals are grouped before scoring. Multiple rules describing the same evidence family should not inflate confidence as though they were independent observations. The updated aggregation uses the strongest contribution within each group before combining groups. Scores remain heuristics, not calibrated probabilities of maliciousness.
Analysts can preview detection changes. The comparison view runs current local rules against retained, filtered report fields and shows how the results differ from stored assessments. It preserves saved classifications and human overrides. Missing historical inputs are made explicit, and agreement with an earlier analyst label is not presented as measured detection accuracy.
Retained reports can be revisited as URL intelligence changes. A bounded, optional re-evaluation path can append a new assessment and audit history. It uses retained filtered information and is separate from a complete replay of every original input. These changes support careful review without turning every new signal into an automatic public warning.
Privacy and control when reporting suspicious emails
A suspicious email can still contain confidential business information. Karst’s reporting design separates the original evidence from the structured signals used across the processing workflow. Original email evidence is encrypted at rest, and personal information is filtered before downstream analysis.
Raw message bodies stay off the message bus. Authorised evidence access is recorded in the audit history. Retention controls, legal holds and encrypted backups are part of the implemented operational tooling. Filtering is a protective control, not a promise that every possible sensitive detail has been recognised or that the remaining text is anonymous.
Each operator runs an isolated instance with its own database, evidence storage and secrets. Self-hosting lets an organisation choose where that deployment runs and who operates it. It also brings responsibility for access, maintenance, retention and recovery. Our technology services address those infrastructure decisions alongside the application itself.
Where Karst fits in an organisation’s email security
Karst focuses on submitted messages and the investigation that follows. Existing mail filtering, identity protection, endpoint controls and incident response remain part of the wider setup. A deployment should make it clear who receives reports, who can access original evidence and who approves published indicators.
For a Luxembourg business or a community operator elsewhere, a useful pilot starts with that reporting process. Define the accepted submission channel, choose the analysts, agree retention rules and test what happens when someone disputes a result. Our security services can help connect those decisions to existing responsibilities.
Staff also need to recognise when to escalate and know what feedback to expect. Training and exercises can practise that complete path, including a message that turns out to be legitimate. A usable reporting process should support people who ask for help in good faith.
Frequently asked questions about Karst
Does inspecting an email also report it?
No. The public Inspector analyses the submitted email without creating a report or storing evidence. Reporting is a separate workflow for an operator’s investigation.
Can Karst guarantee that an email is safe?
No. Its findings explain observable signals. Unknown or unflagged results are not proof of legitimacy, especially when the original message context is incomplete.
Is Karst open source or production-ready?
Karst is currently proprietary and pre-production. There are currently no plans to release it as open source. Production acceptance remains specific to the operator’s environment, and a real classifier model has not yet completed the promotion gates.
Does Karst integrate with MISP or STIX/TAXII?
Those federation channels remain planned. The implemented output paths are signed webhooks and local blocklists. Native mobile share extensions are also on the roadmap.
Explore Karst or discuss a reporting pilot
Visit the Karst product website for its public implementation status and Email Inspector. To discuss a pilot around your organisation’s reporting channels, analyst workflow and hosting requirements, contact ObsidianCorps.
