Reviewing and Assessing Reported Phishes

When a phishing email is reported, Red Canary’s Phishing Triage Agent automatically analyzes the email content and flags any suspicious features, such as unexpected attachments, generic greetings, or sender impersonation. These appear as yellow badges at the top of each reported phish.

The Triage Agent provides an initial classification of Phish or Not a Phish, along with a summary of its findings, visible in the Triage Agent tab. This classification is a recommendation only; the Agent cannot set a final Assessment. A human analyst always makes the final determination.

The intended workflow for analysts is:

1. Review the Triage Agent’s flagged indicators and initial classification.

2. Analyze the underlying email data, such as authentication results, domains, URLs, and attachments, to validate or challenge the recommendation.

3. Set the final Assessment based on your findings.

This guide walks you through the process of investigating a reported phishing email in Red Canary, from reviewing AI-flagged indicators to analyzing email metadata, setting an Assessment, and collaborating with your team.

Note

Users must have an Analyst or Analyst Viewer role to view and manage reported phishes.

Filtering and Sharing Reported Phishes

The Phishing page displays all reported phishes collected from your reporting tool(s). You can filter by attributes or date range to narrow your view, and export results using the download button. Click any phish ID to open its detail page and begin your investigation.

Reviewing the Assessment Status

The Assessment Header provides an at-a-glance summary of a reported phish before you dive into the details. The colored border indicates the current classification, so you can immediately orient yourself to where the investigation stands:

• Red: The email is assessed as a confirmed Phish

• Blue: The email is assessed as Not a Phish

• Gray: Assessment status is TBD (awaiting assessment)

The header also displays the subject line of the reported email, the sender’s “From” address, the reporter’s email address, and the date and time the email was collected (in UTC).

Examining Reporter Details

Understanding who reported a phishing email provides important context for your assessment. A reporter with a history of low-accuracy submissions may warrant more scrutiny than one with a strong track record. Similarly, knowing a reporter’s role or department can help you evaluate whether the email’s sender was targeting a specific individual or team.

Reporter details are displayed in the Assessment Header card and are available for every reported phish. Click the reporter information in the header to open a slide-out panel with a full breakdown of the reporter’s metrics and, if enrichment is enabled, their identity attributes.

The information displayed in the header card depends on what data is available for that reporter:

• Without Recipient Enrichment enabled: The reporter’s email address is displayed and linked to the slide-out.

• With Recipient Enrichment enabled: The reporter’s display name, job title, and department are displayed and linked to the slide-out.

Reporter Details

Selecting a reporter opens a slide-out with details about the reporting user, organized into three tabs. Reporter details are available for all customers and are aggregated automatically based on the reporting user's email address. When Recipient Enrichment is enabled, the slide-out also includes identity attributes pulled from your connected identity providers.

Reporter Metadata

The Reporter Metadata tab summarizes who the reporter is and how reliable their submissions have been:

• Email Address: The reporting user's email address

• Display Name: The reporter's name as it appears in the connected identity source

• Job Title: The reporter's role within the organization

• Department: The reporter's team or business unit

• Reporter Accuracy Rate: The percentage of the reporter's submissions that were assessed as a confirmed Phish

• Last Reported: The timestamp of the reporter's most recent submission

Display Name, Job Title, and Department are enrichment attributes collected during processing of each reported phish, using the reporter's email address. Each is timestamped to show when the identity source was last queried. These attributes help you assess the sender's potential intent and target — for example, a phishing email directed at someone in finance or HR may indicate a business email compromise attempt or a targeted credential-harvesting campaign.

Reporter Source Data

The Reporter Source Data tab displays the raw record returned by each connected identity provider (for example, a Microsoft Office 365 tenant), including attributes such as the reporter's user principal name, employee type, office location, and proxy addresses. Use this tab when you need the complete, unprocessed identity record behind the summarized metadata.

Reported Phishes

The Reported Phishes tab lists other reported phishes associated with this reporter, including any currently awaiting assessment. Each entry links directly to the report and includes the collection timestamp, collector, sender, email subject, and assessment.

Use this submission history to identify patterns. For example, a reporter with consistently high accuracy may indicate a targeted attack, while a first-time reporter submitting a borderline email may benefit from closer review.

Reviewing Suspicious Feature Badges

Yellow badges at the top of each reported phish surface indicators flagged by the Triage Agent, such as unexpected attachments, generic greetings, or sender impersonation. These badges give you a quick read on which characteristics of the email warranted attention before you review the full analysis in the Triage Agent tab.

Reviewing Triage Agent Findings

The Triage Agent analyzes each reported email before a human analyst reviews it, flagging suspicious features and providing an initial classification. Reviewing its findings first can help you prioritize where to focus your analysis and surface indicators you might otherwise overlook.

The Triage Agent tab displays a full summary of the Agent’s findings, including extracted and analyzed email content, any flagged Suspicious Features, and an initial classification of Phish or Not a Phish.

Note

The Triage Agent tab may show a classification that contradicts the current Assessment (for example, the Triage Agent tab shows Not a Phish but the Assessment status is set to Phish). This is expected; the Agent provides a recommendation only and cannot set a final Assessment. A human analyst always makes the final determination.

Analyzing Email Origin and Authentication

Email authentication failures in SPF, DKIM, or DMARC are common indicators of spoofed or tampered messages. Reviewing these results early can help you quickly rule out legitimate senders and focus your investigation on higher-risk emails.

The Reported Email card in the Overview tab contains the metadata needed to analyze the origin and authentication of a reported phish:

• From: The sender’s email address

• Auth-Results and Auth-Results-Orig: Email authentication results (SPF, DKIM, and DMARC checks)

• ARC-Auth-Results: Authentication chain results, if applicable

• To: The recipient’s email address

• Subject: The email subject line

• Reply To: The address replies will be directed to

• Return Path: The address used for bounce messages

• Origination: Details of the email’s original delivery time

• Message ID: A unique identifier for tracking the email across systems

Investigating Domains and URLs

Phishing emails frequently use lookalike domains, obfuscated links, or redirect chains to obscure malicious destinations. Reviewing the domains and URLs in an email (and cross-referencing them with external investigative tools) is one of the most reliable ways to identify credential-harvesting or malware delivery attempts.

The Message URLs card in the Overview tab breaks down all domains and URLs found in the reported email:

• Email Domains: Displays the “From” and “Reply-To” domains, with visual indicators highlighting unique or mismatched domains

• URLs in Email: Groups URLs by host domain and displays each URL alongside any associated link text. Hover over a URL to view its full details.

• Domain Helpers: Each domain includes icons linking to external investigative tools:

  • Whois: Retrieves domain registration details, including ownership and contact information

  • Shodan: Provides hosting information such as server location, IP ownership, and open services or ports

  • VirusTotal: Analyzes domains, IPs, and URLs to detect malware and potential security threats

Viewing Email Details

Malicious attachments are a primary delivery mechanism for malware. Even when an attachment appears benign, reviewing file type, size, and metadata can surface anomalies worth investigating further.

The Attachments card in the Overview tab displays all files included in the reported email, including the attachment name, file type, and file size. Click any attachment to jump to its detailed view in the Email Message card.

The Email Message card provides an in-depth view of the reported email organized across tabbed views:

• Headers: The complete multipart/mixed headers, including routing metadata essential for analyzing delivery paths and identifying header manipulation

• Summary: The message body rendered in Markdown, with email security banners removed, obfuscated links resolved, and extra whitespace collapsed

• Body: The HTML message body in its original view

• <body>: The message body stripped of HTML attributes and tags

• Attachments: A detailed view of each file and image attachment, including raw metadata and rendered images showing what the attachment actually looks like

Updating the Assessment Status

Once you’ve reviewed the available evidence, use the Assessment dropdown to classify the email as Phish or Not a Phish. Analysts can update the Assessment at any time if new information warrants a change.

The Attributes card on the right panel records the state of the current Assessment:

• Assessment: The current classification status

• Summary: The reasoning behind the Assessment, along with details of the last update

• Last Claimed By: The user who last took responsibility for the Assessment

• Last Claimed At: When a Red Canary analyst last claimed the email for Assessment

• Collected At: When Red Canary first collected the reported email

• Collected By: The Collector that collected the reported email

The Stats card below it records timestamps for key Assessment lifecycle events: when the email was collected, when it was claimed, and when the Assessment was first and last set.

Note

Only users with the Analyst role can change the Assessment status.

Tracking Activity and Collaboration

The Activity timeline at the bottom of the page provides a full record of everything that has happened to a reported phish: Assessment changes, Triage Agent activity, automation execution, and team comments. Use the Comments tab to add notes for your team or Red Canary’s analysts, and the History tab to audit the complete log of Assessment updates.

The timeline is organized into four tabs:

• Activity shows a consolidated view of all Assessment status changes and user comments, including actions taken by the platform itself — such as the Triage Agent completing its analysis or the Email Analyzer finishing its review of attachments.

• Comments displays notes added by your team and Red Canary’s analysts. Analysts can add new comments directly from the top of the timeline. Note that Red Canary’s team is not notified of comments your team adds, and analyst comments from Red Canary are not guaranteed on every reported phish.

• Automations provides a detailed breakdown of any automations triggered by the reported phish, including execution status and associated details. A summary of this activity also appears in the Activity tab.

• History displays a complete audit log of all changes made to the Assessment, including updates to the Assessment summary. Use this tab to review how a classification evolved over the course of an investigation.

Note

Users with the Analyst role can view and add comments. Users with the Analyst Viewer role can view comments only.