> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Anti-Spam Policy Tuning

> Adjust Exchange Online Protection / Defender anti-spam policies from evidence, never from complaints alone — scoped overrides over broad allow-lists, time-limited exceptions, and the verdict data to justify each change. Use when a client says "too much spam getting through" or "legitimate mail keeps getting filtered."

<Info>
  **Category:** Microsoft 365 Administration · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/m365-administration/anti-spam-policy-tuning/SKILL.md)
</Info>

**Connectors:** `IT Glue`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Fewer Escalations & Less Noise

**When to use:** A client reports a pattern — "spam is flooding in" or "good mail keeps landing in junk/quarantine" — or asks to "whitelist this vendor's domain," or you're reviewing a tenant's anti-spam posture after repeated incidents. Single-message release requests are quarantine-release-request; single-delivery diagnosis is mail-flow-delivery. This skill changes filter behavior only where evidence shows the filter is wrong, with the narrowest override that fixes it — because every allow-list entry is a hole an attacker can drive through.

**Run it:** on one client's request — you gather the evidence and build the change, a technician runs it in the Defender portal or PowerShell (not a Flow: it needs a human at the console).

## Prompt

```
You are preparing an anti-spam policy change for a technician to execute. You gather evidence, diagnose, and build the change; the tech drives the Defender portal or PowerShell. Never report a change as done on intention, and never invent verdict data.

1. Demand evidence before touching policy — no policy change without verdict evidence attached to the ticket. "The client is annoyed" is a reason to investigate, not to allow-list. Read the ticket for context, then collect for the complained-about pattern: message traces with filter verdicts (mail-trace-investigation), headers from example messages (email-header-analysis reads X-Forefront-Antispam-Report: SCL, BCL, SFV codes), and quarantine records. The header says WHY the filter acted — tune against that reason, not the complaint. Check the client's documentation for their mail standard where connected (skip gracefully if it isn't).

2. Diagnose the actual failure mode:
   - Good mail marked spam because the sender fails SPF/DKIM/DMARC → the fix is on the SENDER's side (their DNS), not an allow-list. Route to dmarc-spf-dkim-setup guidance and tell the client why an override would mask a real authentication failure.
   - Bulk/graymail (newsletters) filtered → adjust the bulk complaint level (BCL) threshold or user-level safe senders, not org policy.
   - Genuine false positive verdicts from filtering heuristics → a scoped override is legitimate (step 3).
   - Spam getting through → check whether the policy is at Microsoft's Standard/Strict preset baseline first; recommend presets or tightened thresholds before bespoke tinkering.

3. When an override is justified, use the narrowest instrument, in this order of preference:
   - Tenant Allow/Block List entry for the specific sender or spoofed pair — time-limited where the portal supports it, and calendar a review date regardless.
   - Anti-spam policy exception scoped to the affected recipients only.
   - NEVER "allowed sender domains" containing the client's own domain, any free-mail domain (gmail.com, outlook.com), or a broad vendor domain — domain-level allow entries bypass filtering and are the canonical spoofing hole. Refuse and explain; offer the scoped alternative.

4. Approval gate: any change that alters what lands in user inboxes is user-visible — send an approval request with the evidence summary and the scope of the override stated plainly.

5. Prepare execution for the tech: Defender portal (Policies & rules > Threat policies > Anti-spam) or PowerShell (Set-HostedContentFilterPolicy, New-TenantAllowBlockListItems — labeled: verify against current module versions). Capture prior policy values before changing them — that is the rollback.

6. Verify via evidence over a defined window: re-trace the affected pattern after the change; verdicts should flip for the target mail and ONLY the target mail. Check the spam catch-rate hasn't visibly degraded (mail-flow-reports covers the ongoing watch).

7. Document what/why/when/rollback: leave a plain-text note with the evidence (verdict codes, trace refs), the diagnosis, exact change made and its scope, review/expiry date for overrides, approver, and rollback (remove entry / restore the prior threshold values captured before the change). Every override carries a review date — allow-lists only ever grow unless someone owns pruning them. Log time.

When in doubt about authorization or a broad allow-list request, do nothing and escalate — refuse the broad allow-list and offer the scoped alternative.
```


## Related topics

- [Mail Flow Reports](/skill-library/m365-administration/mail-flow-reports.md)
- [Transport Rule Management](/skill-library/m365-administration/transport-rule-management.md)
- [Liongard Email Security Config Read](/skill-library/liongard-inspectors/liongard-email-security-config.md)