> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsiam/detect-investigate-and-respond-to-threats/cortex-advanced-email-security/cortex-advanced-email-security-threat-detection-and-issues.md).

# Cortex Advanced Email Security threat detection and issues

The Cortex Advanced Email Security module supports a wide range of detection types, designed to identify malicious, suspicious, or policy-violating emails. These detections are generated by the artifact-based, metadata-driven, and LLM-powered engines described in the Architecture and Data Flow section.

<details>

<summary>Threat detection categories</summary>

All analytics-based detections are documented in the external Analytics Issue Reference, including the following:

* Issue name
* Trigger conditions
* Associated MITRE TTPs (where applicable)
* Recommended response actions

In addition to Analytics listed in the reference, the module supports the following extended categories:

* WF Analysis issues: Generated based on WildFire verdicts (malicious/suspicious) for file attachments, where integration is enabled.
* AURL issues: Based on Advanced URL analysis verdicts (for example, detected phishing kit, dynamic redirects, credential harvesting behavior).
* IOC-Based issues: Triggered when an email contains known malicious indicators (SHA256, domain, URL, or sender) that match internal or external blocklists.
* User-Reported Phishing issues: Generated when users forward emails to a designated phishing report address. These issues can be generated independently or correlated with other detection logic if matches are found.

Each issue type may be subject to additional correlation and aggregation into case entities based on shared characteristics, for example, sender, artifact, theme, etc.

</details>

<details>

<summary>Email security issue metadata and fields</summary>

Each issue contains a structured set of metadata fields that provide forensic and contextual insight for downstream investigation. Below is a breakdown of key issue fields available via the console, APIs, or case export.

| Attribute                | Field Name                                  | Description                              |
| ------------------------ | ------------------------------------------- | ---------------------------------------- |
| Issue Name               | issue\_name                                 | High-level issue classification          |
| Issue Description        | issue\_description                          | Human-readable description of the threat |
| Message ID               | internet\_message\_id                       | Unique ID of the email message           |
| Conversation ID          | conversation\_id                            | Thread/conversation identifier           |
| Email Created Date       | created\_date                               | Timestamp when the message was sent      |
| Subject                  | subject                                     | Subject line of the email                |
| Email Recipient(s)       | recipients.name, recipients.email           | All TO recipients of the email           |
| CC Recipient(s)          | cc\_recipients.name, cc\_recipients.email   | All CC recipients                        |
| BCC Recipient(s)         | bcc\_recipients.name, bcc\_recipients.email | All BCC recipients                       |
| From Address             | from.address                                | Displayed From: email address            |
| From Display Name        | from.name                                   | Display name shown in From field         |
| Sender Address           | sender.address                              | Actual sender address (SMTP-level)       |
| Sender Name              | sender.name                                 | Display name of sender (SMTP envelope)   |
| Return-Path              | return\_path\_data.address                  | Return path address (SMTP envelope)      |
| Attachment SHA256        | attachments.hash\_str                       | Hashes of attached files                 |
| Attachment Name          | attachments.name                            | Filenames of attached files              |
| URLs                     | url\_verdicts.url\_name                     | URLs extracted from the message body     |
| Internet Message Headers | internet\_message\_headers                  | Full set of original headers             |

{% hint style="info" %}

### Note

Depending on data collection mode and platform capabilities, not all fields may be populated for every message. API and export documentation provides further clarification on optional vs required fields.
{% endhint %}

</details>

<details>

<summary>Email security issue correlation mechanism</summary>

The issue correlation layer is responsible for linking related issues into cohesive cases. Correlation is performed using the following logic.

* Sender-based correlation: Issues from the same sender with similar delivery patterns across multiple recipients.
* Artifact-based correlation: Issues with shared attachment hashes, URLs, or domains.
* User-based correlation: Issues involving the same recipient or identity in a short time window.

Correlated issues are grouped into a single case object with unified investigation timelines and shared contextual insights (for example, conversation metadata, risky user involvement, cumulative score).

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/cortex-xsiam/detect-investigate-and-respond-to-threats/cortex-advanced-email-security/cortex-advanced-email-security-threat-detection-and-issues.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
