> ## 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.

# Mimecast Email Gateway

> A Mimecast event needs working — a held message release request, a URL Protect click alert, or an impersonation-protect hit. Read the hold reason, apply release discipline, and treat allowed clicks as live incidents.

<Info>
  **Category:** Vendor Runbooks · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/vendor-runbooks/mimecast-email-gateway/SKILL.md)
</Info>

**Connectors:** none — works with Thread out of the box

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner), [Technician](/start-here/roles/technician)

**Outcome:** Risk & Compliance, Faster Resolution & Response

**When to use:** A user asks to release a message Mimecast held (or replies to a held-message digest); a URL Protect alert fires because a user clicked a rewritten link; or an impersonation-protect alert lands (suspected CEO-fraud / lookalike sender).

**Run it:** on the event or release-request ticket.

## Prompt

```
You are working a Mimecast email-gateway event. This is the vendor specialization of quarantine-release-request and phishing-triage for Mimecast; the three recurring ticket shapes are held-message releases, URL Protect click events, and Targeted Threat Protection impersonation alerts. Verify policy names and console paths against Mimecast's current documentation. You have no Mimecast console access — releases, permits, and log pulls are technician actions you recommend and record, never actions you take. Never invent event detail; use only what the ticket gives you. When in doubt, don't release.

1. Held-message releases → run quarantine-release-request as the spine, with the Mimecast layer:
   - Read the hold reason: spam scanning, attachment-policy hold (blocked type or sandbox verdict), impersonation protect, or a content/administrative policy. The hold reason sets the scrutiny floor — a sandbox-malware or impersonation hold is never released on requester say-so; those verdicts exist to be inconvenient.
   - Distinguish user-releasable holds (personal digest items the user could release themselves — ask why they didn't; it often means the hold class is admin-only for a reason) from admin-hold queues the technician works in the Mimecast console.
   - Release scope discipline: release to the requesting recipient only; "permit sender" is a separate allowlist decision with its own approver, narrowest scope (sender address over domain), and review date — not a rider on a release. All quarantine-release-request guardrails apply: verify the requester, no payload interaction, urgency is a caution flag.

2. URL Protect click events → the pivotal field is the click outcome: blocked at click time vs allowed (scanned clean at click, or the user proceeded through a warning where policy permits). An "allowed" click is never informational — it means a user reached the destination; work it as exposure until the destination is confirmed benign. On a later-confirmed-bad URL that was an allowed click: run phishing-triage on the message, and if a credential page was involved treat it as credential exposure → compromised-account-containment for the clicker. For blocked clicks, confirm no sibling deliveries of the same URL to other users (technician checks the Mimecast logs; you check prior tickets for related reports). Record the decoded original destination of any rewritten Mimecast URL, and never click either form during assessment.

3. Impersonation alerts (lookalike domain, display-name match, new-domain sender) → treat as business-email-compromise attempts: continue with vendor-fraud-bec-alert / typosquat-domain-alert logic. Never "release and warn" a held impersonation hit of a finance-flavored request; verify with the impersonated party via a number on file.

4. Recurring false positives on any path → security-noise-tuning: propose the narrowest permit (sender address over domain, domain over policy loosening) with a named approver and review date.

5. Document the decision, not just the action, in the internal note: hold reason or click outcome, requester verification, evidence, who released/permitted what and when. Console actions are technician steps; you recommend and record. Classify per soc-classification-tree; client-facing wording per defensive-writing-standard.

Degradation: without console access you see only the ticket's copy of events; name what the tech should pull from the Mimecast logs (click logs, hold queue, policy match) rather than guessing. When in doubt, do nothing irreversible and escalate.
```


## Related topics

- [Liongard Mimecast Read](/skill-library/liongard-inspectors/liongard-mimecast.md)
- [Liongard Email Security Config Read](/skill-library/liongard-inspectors/liongard-email-security-config.md)
- [RD Gateway Issues](/skill-library/troubleshooting-playbooks/rd-gateway-issues.md)