Email Security

---
name: email-security
description: "Expert routing agent for email security. Covers email authentication (SPF/DKIM/DMARC/BIMI), secure email gateways, API-based protection, phishing/BEC defense, and post-delivery remediation. WHEN: \"email security\", \"phishing\", \"BEC\", \"email gateway\", \"SPF\", \"DKIM\", \"DMARC\", \"email authentication\", \"secure email gateway\", \"SEG\". Do NOT use for vendor-specific questions -- use the `proofpoint`, `mimecast`, `abnormal`, `defender-o365`, or `sublime` skill."
license: MIT
---

# Email Security

This skill covers email security: the full threat landscape, authentication standards, gateway architectures, and modern API-based solutions. It points to specific sibling skills for deep platform expertise and applies foundational email security knowledge directly.

## How to Approach Tasks

When you receive a request:

1. **Classify** the request type:
   - **Authentication/Standards** (SPF, DKIM, DMARC, BIMI, MTA-STS) — Apply knowledge from `references/concepts.md` directly
   - **Platform-specific** — Read the appropriate sibling skill below
   - **Threat analysis** (phishing, BEC, account takeover) — Apply threat taxonomy from `references/concepts.md`
   - **Architecture decision** (SEG vs. API-based, deployment model) — Compare approaches using gateway architecture knowledge
   - **Incident response** — Apply post-delivery remediation patterns

2. **Identify the platform** in use (M365, Google Workspace, on-prem Exchange) — this determines which products are viable.

3. **Load context** — For deep concepts, read `references/concepts.md`. For platform work, read the relevant sibling skill.

4. **Analyze** — Apply email-specific reasoning. Email security has layered controls; address all relevant layers.

5. **Recommend** — Provide actionable guidance. For authentication issues, include DNS record syntax.

6. **Verify** — Suggest validation steps (MX lookups, DMARC report analysis, test emails).

## Technology Agents

Read these sibling skills for platform-specific expertise:

| Product | Agent | Use When |
|---|---|---|
| Microsoft Defender for Office 365 | `defender-o365` | M365 environments, EOP, Safe Links/Attachments, AIR, Threat Explorer |
| Proofpoint Email Protection | `proofpoint` | Proofpoint SEG, TAP, URL Defense, TRAP, VAP analysis |
| Mimecast | `mimecast` | Mimecast SEG, continuity, DMARC analyzer, archive |
| Abnormal Security | `abnormal` | API-based BEC/VEC detection, behavioral AI, no-MX-change deployment |
| Sublime Security | `sublime` | MQL-based programmable detection, YAML rules, community detections |

## Email Authentication Standards

### SPF (Sender Policy Framework)

SPF authorizes mail servers to send on behalf of a domain via a DNS TXT record.

**Record syntax:**
```
v=spf1 include:spf.protection.outlook.com include:_spf.google.com ip4:203.0.113.10 -all
```

**Mechanisms:**
- `include:domain` — Inherit another domain's SPF record
- `ip4:x.x.x.x/cidr` / `ip6:` — Explicit IP authorization
- `a` / `mx` — Authorize the domain's A or MX records
- `~all` (softfail) / `-all` (hardfail) / `?all` (neutral)

**Limitations:**
- 10 DNS lookup limit (include + a + mx + exists + redirect each count)
- Does not survive email forwarding (envelope sender changes)
- Only validates the envelope sender (MAIL FROM), not the visible From header
- No cryptographic verification — any server within an IP range passes

**Common issues:**
- Exceeding 10 lookups: Use SPF flattening services or reduce includes
- Forwarding failures: DKIM is the forwarding-resilient mechanism
- Missing senders: Marketing platforms (Mailchimp, Salesforce, HubSpot) must be added

### DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outbound messages, allowing receivers to verify the message has not been modified.

**How it works:**
1. Sending MTA signs email headers and body with a private key
2. Public key published in DNS as `selector._domainkey.domain.com` TXT record
3. Receiving MTA retrieves the public key and verifies the signature
4. Signature covers specified headers (From, Subject, Date, To) and body

**DNS record format:**
```
selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."
```

**Key parameters:**
- `k=rsa` (default) or `k=ed25519` (smaller, faster)
- `p=` — Base64-encoded public key (2048-bit minimum for RSA)
- `t=y` — Test mode (receivers should not reject on failure)
- `s=email` — Service type restriction

**Forwarding resilience:** DKIM survives forwarding because the signature is in the message body, not the transport layer. This is why DKIM alignment is critical for DMARC with forwarded mail.

**Common issues:**
- Key rotation: 2048-bit keys recommended; rotate annually
- Body canonicalization: `relaxed` tolerates minor whitespace changes during transit
- Header signing: Always include `From`, and add `Reply-To`, `Subject`, `Date`

### DMARC (Domain-based Message Authentication, Reporting & Conformance)

DMARC ties SPF and DKIM together with a policy specifying what to do when both fail, plus reporting.

**Record format:**
```
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=s; aspf=s"
```

**Policy values (`p=`):**
- `none` — Monitor only; no enforcement. Start here.
- `quarantine` — Failed messages go to spam/junk folder
- `reject` — Failed messages are rejected at SMTP

**Alignment modes:**
- `adkim=r` (relaxed, default) — DKIM signing domain can be a subdomain of the From domain
- `adkim=s` (strict) — DKIM signing domain must exactly match the From domain
- `aspf=r` (relaxed, default) — SPF envelope sender domain can be a subdomain
- `aspf=s` (strict) — Exact match required

**DMARC passes when:** At least one of SPF or DKIM aligns AND passes.

**Reporting:**
- `rua=` — Aggregate reports (XML, sent daily) — shows volume by sending source and pass/fail breakdown
- `ruf=` — Forensic reports (individual message copies on failure) — privacy-sensitive, many providers have disabled sending

**Deployment roadmap:**
1. `p=none` with `rua=` — Collect 2-4 weeks of aggregate reports
2. Identify all legitimate senders; ensure SPF and DKIM pass for each
3. Move to `p=quarantine; pct=10` — Gradually increase pct
4. Move to `p=quarantine; pct=100`
5. Move to `p=reject` after validation

### BIMI (Brand Indicators for Message Identification)

BIMI displays an organization's brand logo in the email client when DMARC passes at `p=quarantine` or `p=reject`.

**Requirements:**
- DMARC policy at `p=quarantine` or `p=reject`
- Verified Mark Certificate (VMC) from a Certificate Authority (DigiCert, Entrust) for most providers
- Logo in SVG Tiny PS format, hosted at HTTPS URL

**DNS record:**
```
default._bimi.example.com TXT "v=BIMI1; l=https://example.com/bimi-logo.svg; a=https://example.com/bimi-vmc.pem"
```

**Supported clients:** Gmail, Yahoo Mail, Apple Mail (iOS 16+), Fastmail. Not yet Outlook.

### MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS enforces TLS encryption for SMTP delivery, preventing downgrade attacks and MITM interception.

**How it works:**
1. Publish DNS TXT record: `_mta-sts.example.com TXT "v=STSv1; id=20240101000000Z"`
2. Host policy file at `https://mta-sts.example.com/.well-known/mta-sts.txt`
3. Sending MTAs cache the policy and enforce TLS for delivery to your domain

**Policy file format:**
```
version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 86400
```

**Modes:** `testing` (report only), `enforce` (reject non-TLS connections), `none` (disable)

**Complements:** DANE (DNS-based Authentication of Named Entities) offers similar protection via DNSSEC, but MTA-STS has broader adoption.

## Email Threat Taxonomy

### Phishing Types

| Type | Description | Detection Signals |
|---|---|---|
| Spear Phishing | Targeted, personalized phishing using researched details | Low volume, no prior relationship, urgency |
| Whaling | Spear phishing targeting executives | CEO/CFO impersonation, wire transfer, legal themes |
| Clone Phishing | Legitimate email resent with malicious payload substituted | Identical structure to prior email, different links |
| Smishing | SMS phishing | Out-of-band; use security awareness training |
| Vishing | Voice phishing | Out-of-band |
| Quishing | QR code phishing (bypasses URL scanning) | QR image attachments or inline images |

### Business Email Compromise (BEC) Taxonomy

BEC is financially motivated fraud exploiting email. FBI IC3 reports BEC as the highest-cost cybercrime category.

**BEC Types:**
1. **CEO Fraud / Executive Impersonation** — Attacker impersonates CEO to instruct finance to wire funds
2. **Vendor Email Compromise (VEC)** — Compromise legitimate vendor email account; intercept invoices, change payment details
3. **Attorney Impersonation** — Pose as law firm, create urgency around legal matter
4. **W-2/HR Fraud** — Request employee W-2 or direct deposit changes
5. **Gift Card Scams** — Request purchase of gift cards, extract codes

**BEC indicators:**
- Request to change banking/payment details
- Urgency + secrecy ("don't tell anyone")
- Reply-to address different from From address
- Domain lookalikes (examp1e.com, example-corp.com)
- Missing DMARC authentication

### Account Takeover (ATO)

Attackers compromise legitimate email accounts (often via credential phishing) to:
- Send internal-looking BEC messages that bypass authentication checks
- Move laterally to compromise additional accounts
- Access sensitive data from the compromised mailbox
- Establish inbox rules to forward email or hide responses

**Detection signals:** Impossible travel, new device/location, unusual send volume, inbox rule creation, delegated access changes.

## SEG vs. API-Based Architecture

### Secure Email Gateway (SEG) — Inline / MX-Record Based

**How it works:** Organization's MX record points to the SEG. All inbound email passes through the gateway before delivery to the mail server.

**Products:** Proofpoint Email Protection, Mimecast, Cisco Secure Email

**Advantages:**
- Pre-delivery blocking — malicious mail never reaches the mailbox
- Full SMTP control — can reject, quarantine, or modify messages
- Works with any mail platform (M365, Google Workspace, on-prem)
- URL rewriting at delivery time

**Disadvantages:**
- MX record change required — deployment complexity
- Latency added to mail flow
- Bypassed by internal email (user-to-user within same tenant)
- Cannot detect account takeover (message is authenticated)

### API-Based — Post-Delivery Detection

**How it works:** Product connects via Microsoft Graph API or Google Workspace API. Analyzes messages after delivery. Can retroactively remove messages.

**Products:** Abnormal Security, Sublime Security

**Advantages:**
- No MX change — rapid deployment, no disruption
- Can analyze internal email (user-to-user)
- Can detect account takeover via API access to behavioral data
- Retroactive remediation of delivered messages

**Disadvantages:**
- Post-delivery — message reached mailbox before detection
- Dependent on platform API availability and rate limits
- Cannot modify messages in-flight (no URL rewriting)
- Limited to M365/Google Workspace (no on-prem Exchange)

### Layered Architecture

Best practice combines both approaches:
- **SEG or native gateway** (EOP/Defender) as the first layer — blocks known threats at delivery
- **API-based behavioral layer** (Abnormal, Sublime) as second layer — catches sophisticated BEC and ATO that evades signature-based detection

## Reference Files

Load these when you need deep conceptual knowledge:

- `references/concepts.md` — Complete email security fundamentals: full authentication chain, protocol details, BEC taxonomy, SEG vs. API architecture comparison, DMARC reporting analysis, SMTP security standards.