# 3.4 Domain

#### 📖 Overview

The **Domain** submodule under the Analyzed section provides a focused view of all **email-sending domains** identified during threat analysis. It tracks the domain origin of each message flagged as SPAM, PHISHING, or SUSPICIOUS, and enables security teams to take **proactive action** by blacklisting or whitelisting them directly from the interface.

> 🛡️ This module helps you eliminate malicious infrastructure at its source — the sending domain.

***

#### 🧠 What You’ll See

| Column            | Description                                        |
| ----------------- | -------------------------------------------------- |
| **Sender Domain** | The domain that sent the analyzed email            |
| **Verdict**       | Classification result (SPAM, PHISHING, SUSPICIOUS) |
| **Actions**       | Add to blocklist or whitelist                      |

Each row represents a unique sending domain from past emails that triggered a security verdict.

***

#### 🧪 Verdict Types

| Verdict        | Description                                                       |
| -------------- | ----------------------------------------------------------------- |
| **SPAM**       | Domain responsible for bulk/unwanted email content                |
| **PHISHING**   | Domain used in impersonation, credential theft, or scam campaigns |
| **SUSPICIOUS** | Newly registered, low-reputation, or anomaly-indicating domains   |

***

#### 🔧 Domain Filter Operations

Clicking the action button opens the **Domain Filter Operations** modal, where you can:

* Select the **filter type**:
  * ✅ Allow (Whitelist)
  * 🚫 Block (Blacklist)
* Apply instantly across your SEG rules
* Prevent future emails from or allow communications to trusted domains

> ✔️ This functionality helps you create a dynamic trust model around incoming mail infrastructure.

***

#### 📋 Use Cases

| Goal                            | Domain Module Benefit                            |
| ------------------------------- | ------------------------------------------------ |
| Block phishing campaign sources | Instantly blacklist high-risk sender domains     |
| Whitelist known partners        | Ensure no interruption in legitimate email flow  |
| Analyze domain-based attacks    | View clusters of suspicious or recurring sources |
| Enrich block/allow lists        | Make data-driven trust/distrust decisions        |

***

#### 🧠 Common Patterns Identified

* Phishing emails from lookalike domains (e.g., `out1ook.com`)
* Spam relays from marketing platforms
* Spoofed sender addresses from legitimate domains (if SPF/DKIM fails)
* Unknown domains with no DNSSEC, DMARC, or low TTL

***

#### ⚙️ Analyst Tips

* Sort by verdict to focus on high-priority domains (PHISHING > SPAM).
* Repeated appearances across **multiple users** indicate targeted campaigns.
* Combine this with **3.3 Mail** to see the full context of delivery, recipients, and message content.

***

#### 🔐 Best Practices

| Practice                            | Why It's Important                     |
| ----------------------------------- | -------------------------------------- |
| Review domain list weekly           | Catch evolving phishing infrastructure |
| Auto-block newly registered domains | Many threats originate from fresh TLDs |
| Use with DMARC/SPF validation logs  | Validate whether spoofing is occurring |
| Sync with other filters (URL, Mail) | Apply protection holistically          |

***

> 🎯 The Domain module gives you strategic control over what infrastructure can — and cannot — communicate with your users. It’s one of the most effective ways to stop email-based threats at the source.


---

# Agent Instructions: 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:

```
GET https://docs.shieldsguard.com/shieldsguard-seg/3.-analyzed/3.4-domain.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.