Mimecast Email Security Cloud Gateway

At a glance

Vendor	Mimecast Email Security Cloud Gateway. API 2.0 only — legacy API 1.0 with regional HMAC-signed URLs is not supported.
Source type	email
Vendor ID (slug)	mimecast
Base URL	https://api.services.mimecast.com — unified API 2.0 endpoint for every region. The legacy us-api, eu-api, au-api, de-api, za-api hostnames are API 1.0 only and NOT supported by this connector.
Auth method	oauth2 — client-credentials flow. Draxis mints an access token from POST /oauth/token on every run and caches it for that run only.
Schedule default	daily — 24h-rolling-window KRIs self-reset each run. Hourly is fine but buys little new signal unless you want tighter response on the "not blocked" KRIs.
Licensing	Core TTP KRIs (impersonation, attachment, URL) need the respective TTP modules. Internal Email Protect KRI requires the IEP module. DMARC alignment KRI requires the DMARC Analyzer module. Tenants missing a module get 0 + warn log on the affected KRI.
Availability	New in 2026.04.

Required scopes & roles

Mimecast API 2.0 uses per-application scope assignment. Create an API 2.0 Application in the Admin Console and grant it read-only scopes in the following areas:

• TTP Attachment Protect: Read — backs the malware-delivered KRI.
• TTP URL Protect: Read — backs the URL-clicks KRI.
• TTP Impersonation Protect: Read — backs the impersonation KRI.
• Held Message Management: Read — backs the user-released-held KRI.
• Internal Email Protect: Read — optional, backs the IEP KRI.
• DMARC Analyzer: Read — optional, backs the auth-alignment KRI.

Every scope is read-only; Mimecast's API 2.0 separates read/write scopes cleanly. Do not grant any Write, Release, or Administration scope — the connector never modifies mailbox or policy state.

Setup steps

1. Confirm your tenant is on API 2.0. In the Mimecast Admin Console, go to Services → API and Platform Integrations. If you see an "API 2.0 Applications" section, you're migrated. If you only see "Services → API Applications" (the older UI), your tenant is still on API 1.0 — request the migration from Mimecast support before wiring Draxis.
2. Create the API 2.0 Application. Services → API and Platform Integrations → API 2.0 Applications → Add API 2.0 Application. Name: draxis-connector. Description: "Read-only access for Draxis email-security KRIs."
3. Assign scopes matching the modules you've licensed (see Required Scopes above — at minimum the three TTP reads and Held Message Management).
4. Copy the Client ID and Client Secret. Mimecast shows the secret only once at creation — copy both into your password manager immediately. If you lose the secret, delete and recreate the application.
5. Verify with a token exchange before wiring Draxis:

   curl -s -X POST 'https://api.services.mimecast.com/oauth/token' \
     -H 'Content-Type: application/x-www-form-urlencoded' \
     --data-urlencode 'grant_type=client_credentials' \
     --data-urlencode 'client_id=<client_id>' \
     --data-urlencode 'client_secret=<client_secret>' \
     | jq '.access_token | .[0:20] + "..."'

   You should see a truncated access token. 400 errors usually mean a typo in the client ID / secret; 401 means the application was deleted or disabled.

Wire it into Draxis

1. Open Settings → Integrations in your tenant.
2. Click Add integration and pick Email Security as the source type.
3. Pick Mimecast Email Security Cloud Gateway from the vendor dropdown. Draxis pre-fills the API 2.0 base URL, OAuth auth method, and daily schedule.
4. In Client ID, paste the API 2.0 application client ID from step 4.
5. In Client Secret, paste the client secret. Draxis encrypts it server-side with encryption.key before storage.
6. Click Test. Green means Draxis exchanged the credentials for an access token and called /api/v2/account/get-account successfully. The message includes your Mimecast account code and name.
7. Under KRIs to import, tick the KRIs you want Draxis to manage. All six mimecast_* KRIs are checked by default; uncheck the IEP and DMARC-alignment KRIs if you don't license those modules (otherwise 0 could be misread as a clean posture). Selected rows are created on save. Unchecking a previously-imported KRI deletes it on save.
8. Save. The connector runs daily by default; use Run now from run history to trigger the first sync immediately.

KRIs produced

Slug	Meaning	Derivation
mimecast_impersonation_not_blocked_24h	Impersonation events delivered (not blocked) in 24h	POST /api/v2/ttp/impersonation/get-logs with filter action=permitted and a 24h time window, read meta.pagination.totalCount.
mimecast_malware_delivered_24h	Malicious attachments that reached users in 24h	POST /api/v2/ttp/attachment/get-logs with result=malicious, action=released, 24h window.
mimecast_url_clicks_post_delivery_7d	URL rewrites clicked and allowed (7d)	POST /api/v2/ttp/url/get-logs with action=allow, route=inbound, 7d window.
mimecast_internal_anomalies_24h	Internal Email Protect anomaly detections in 24h	POST /api/v2/iep/get-logs, 24h window. 403/404 → 0 + warn (IEP not licensed).
mimecast_auth_alignment_pct	% inbound passing DMARC alignment (7d)	POST /api/v2/dmarc/get-analyzer-summary, 7d window. Reads passPct or computes aligned / total × 100. 403/404 → 0 + warn (DMARC Analyzer not licensed).
mimecast_user_released_held_24h	Held messages released by end-users (bypassing admin), 24h	POST /api/v2/held-messages/get-release-logs with releaseType=user, 24h window.

Each row is a slug the connector writes to. Draxis creates the matching kri rows automatically when you check them in the KRIs to import section of the integration form — no manual API call or seed script needed. Thresholds shown in the table are the seeded defaults; you can edit them freely in the KRIs tab afterwards.

Vendor quirks

• API 2.0 only. Mimecast's API 1.0 (regional HMAC-signed URLs) is not supported. If your tenant still uses 1.0, API 2.0 migration is a Mimecast support ticket — usually one business day.
• All requests are POST with JSON body. Even "list" endpoints are POST in API 2.0; filters go in data[0] and pagination controls in meta.pagination. The connector handles this internally.
• Count via meta.pagination.totalCount. All list endpoints return this field in the envelope, which means a pageSize=1 request gets the total count without streaming all results. The connector uses this pattern throughout.
• Filter field names vary by endpoint. TTP Attachment uses action=released; TTP URL uses action=allow; Impersonation uses action=permitted. The connector's filter dicts use the field names that match each endpoint's API docs at time of authoring. If a future Mimecast release renames fields, the KRI silently returns 0 — edit the filter dicts in the connector to catch up.
• DMARC alignment is 7d, not 24h. DMARC alignment trends matter over days, not hours — a 24h window has high variance from normal email volume fluctuations. The connector uses a 7-day window for a smoother trend signal.
• Impersonation "not blocked" includes user-releases. Mimecast's impersonation pipeline can mark a message as impersonation but still deliver it if a user (or admin) releases from the digest. The KRI counts every final-state=delivered case, regardless of reason. Pair with the user-released-held KRI to see how much of the total comes from end-user releases.
• Held-message release-type enum varies by tenant config. Mimecast releases tagged user, admin, auto, or autorelease depending on how your held-message workflow is configured. The KRI filters on releaseType=user; if your tenant uses a different label for end-user releases, edit the filter.
• Tokens are short-lived. Mimecast API 2.0 access tokens expire in ~60 minutes. The connector mints a fresh token on every run, so expiration is not a concern for daily scheduling.
• Rate limits are per-application. Mimecast API 2.0 allows 1000 req/minute per application. The connector makes ~7 calls per run, well under the ceiling.
• Client-secret rotation. Mimecast secrets don't auto-expire. Standard hygiene is quarterly rotation: create a new application secret in the admin console (Mimecast supports multiple active secrets per app), update Draxis, then revoke the old one. Brief overlap is safe.
• No on-prem / cloud-private-gateway support. This connector targets Mimecast's cloud API. Some Mimecast Gateway deployments use a dedicated private endpoint — not covered here.

Troubleshooting

• HTTP 400 on token exchange with "invalid_client" — client ID or secret has a typo. Mimecast client IDs are GUIDs; client secrets are long base64-ish strings. Verify by copy-pasting from your password manager, not the console (the console may truncate on display).
• HTTP 401 with "invalid_grant" — the API 2.0 application was deleted or disabled. Recreate in the admin console.
• HTTP 403 on a specific endpoint — the application is missing the scope for that module. Edit the application's scope list in the admin console and re-save.
• mimecast_auth_alignment_pct is 0 with "DMARC Analyzer not licensed" warn — you don't have the DMARC Analyzer module. Uncheck the KRI, or add the module to your Mimecast subscription.
• mimecast_internal_anomalies_24h is 0 with "IEP module not licensed" warn — same as above for Internal Email Protect.
• Test passes but every KRI is 0 — application might have no scopes assigned. In the Mimecast admin console, re-check the scope list on the application; newly-created apps default to "no scopes" which happily authenticates but returns nothing.
• rowsSkipped > 0 and rowsWritten = 0 — your tenant hasn't imported any KRIs for this integration yet. Open the integration in Settings → Integrations, tick the KRIs under KRIs to import, and save.
• Still stuck? Open a support ticket with the run ID (from Run history) and we'll dig in.