> For the complete documentation index, see [llms.txt](https://herd-security.gitbook.io/herd-security-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://herd-security.gitbook.io/herd-security-docs/simulations/phishing-simulations/whitelisting-email-domains-mimecast.md).

# Whitelisting Email Domains (Mimecast)

Allowlist Herd's phishing-simulation domains in Mimecast so simulations reach the inbox with links intact — including which bypasses are required, how to scope them to Herd's authenticated sender doma

When Herd sends a phishing simulation, the message comes from one of Herd's verified sending domains rather than your own, and it is deliberately built to look like a real phishing attempt. If your organization runs **Mimecast** in front of Microsoft 365 or Google Workspace, Mimecast inspects the message before your mail platform ever sees it — spam and anti-spoofing scanning, URL Protection (which rewrites and follows links), Attachment Protection, and Impersonation Protection. Any of these can block the simulation, strip or pre-click its links, or quarantine it, which skews your results.

This guide explains how Herd's simulation mail authenticates, which Mimecast policies you need to allow it through, and how to scope those policies tightly to Herd's domains.

{% hint style="info" %}
Mimecast is a gateway that sits **in front of** your mail platform. If you also want simulations to skip your platform's own filtering, allowlist there too: [Microsoft 365](/herd-security-docs/simulations/phishing-simulations/whitelisting-email-domains-microsoft-365.md) or [Google Workspace](/herd-security-docs/simulations/phishing-simulations/whitelisting-email-domains.md). To credit users who **report** a simulation, see [Outlook](/herd-security-docs/email-providers/email-providers/outlook.md) or [Gmail](/herd-security-docs/email-providers/email-providers/gmail.md).
{% endhint %}

## How Herd's simulation mail authenticates

Every Herd simulation domain is a full sending identity in Amazon SES, not a landing-page-only domain. For each domain, all three sender identifiers align to that same domain and pass authentication:

| Identifier                         | Value                                                      | Authenticates by                     |
| ---------------------------------- | ---------------------------------------------------------- | ------------------------------------ |
| Header `From`                      | `<name>@<domain>` — e.g. `it-support@okta-auth-verify.com` | —                                    |
| Envelope `Return-Path` (MAIL FROM) | `mail.<domain>` — e.g. `mail.okta-auth-verify.com`         | SPF (`v=spf1 include:amazonses.com`) |
| DKIM signing (`d=`)                | `<domain>` — e.g. `okta-auth-verify.com`                   | DKIM (Amazon SES managed keys)       |

In other words, **the From domain, the MAIL FROM domain, and the DKIM `d=` domain are all derived from the same sending domain** — the MAIL FROM is the `mail.` subdomain of it, and the DKIM `d=` is the domain itself. Each domain also publishes a DMARC record. Because these are dedicated simulation domains used for nothing else, a permitted-sender rule scoped to them, combined with an SPF or DKIM pass, is both precise and safe.

## Herd sending domains

Herd sends simulations from a shared pool of verified domains, each styled to impersonate a familiar brand; the generic `x7k2m.net` is used when a simulation isn't brand-specific. **You only need to allow the domains relevant to your organization.** See the full, current list in [Whitelisting Email Domains in Google Workspace → Herd sending domains](/herd-security-docs/simulations/phishing-simulations/whitelisting-email-domains.md#herd-sending-domains).

The three sender identifiers you need for Mimecast policies map from that list as follows — the **sending domain** is the header `From` domain, the **MAIL FROM domain** is its `mail.` subdomain, and the **DKIM signing domain** (`d=`) is the sending domain itself. The current set:

| Sending domain (`From`)        | MAIL FROM (`Return-Path`)           | DKIM signing (`d=`)            |
| ------------------------------ | ----------------------------------- | ------------------------------ |
| `x7k2m.net`                    | `mail.x7k2m.net`                    | `x7k2m.net`                    |
| `okta-auth-verify.com`         | `mail.okta-auth-verify.com`         | `okta-auth-verify.com`         |
| `claude-auth-verify.com`       | `mail.claude-auth-verify.com`       | `claude-auth-verify.com`       |
| `anthropic-portal.com`         | `mail.anthropic-portal.com`         | `anthropic-portal.com`         |
| `chatgpt-customer-care.com`    | `mail.chatgpt-customer-care.com`    | `chatgpt-customer-care.com`    |
| `codex-support.com`            | `mail.codex-support.com`            | `codex-support.com`            |
| `cursor-services.com`          | `mail.cursor-services.com`          | `cursor-services.com`          |
| `github-status-update.com`     | `mail.github-status-update.com`     | `github-status-update.com`     |
| `aws-account-portal.com`       | `mail.aws-account-portal.com`       | `aws-account-portal.com`       |
| `amazon-account-team.com`      | `mail.amazon-account-team.com`      | `amazon-account-team.com`      |
| `google-status-update.com`     | `mail.google-status-update.com`     | `google-status-update.com`     |
| `slack-customer-care.com`      | `mail.slack-customer-care.com`      | `slack-customer-care.com`      |
| `salesforce-customer-care.com` | `mail.salesforce-customer-care.com` | `salesforce-customer-care.com` |
| `oracle-portal.com`            | `mail.oracle-portal.com`            | `oracle-portal.com`            |
| `netsuite-account-confirm.com` | `mail.netsuite-account-confirm.com` | `netsuite-account-confirm.com` |
| `calendly-support.com`         | `mail.calendly-support.com`         | `calendly-support.com`         |
| `zip-portal-verify.com`        | `mail.zip-portal-verify.com`        | `zip-portal-verify.com`        |
| `whatnot-customer-team.com`    | `mail.whatnot-customer-team.com`    | `whatnot-customer-team.com`    |

Mimecast policies can match either the header sender or the envelope (MAIL FROM) sender, so include both columns where a policy allows it. The DKIM signing domain doesn't need a separate Mimecast entry — it's listed so you can confirm `d=` alignment.

{% hint style="info" %}
Herd adds sending domains over time, so **this list grows**, and any new domain follows the same pattern: it sends as `<domain>`, its MAIL FROM is `mail.<domain>`, and it signs with `d=<domain>`. The current set, and Herd's fixed sending IP for policies that scope by connecting address, is always shown in the Herd admin console under **Settings → Integrations → Outlook** (or **Gmail**) **→ Allow-list Herd simulation mail**, with copy buttons. The username portion of an address can vary; scoping to the **domain** covers every address on it.
{% endhint %}

## Identifying simulation messages

Every Herd simulation message carries an **`X-Campaign-ID`** header, so you can build a Mimecast rule that matches on the presence of that header. Two things to note:

* The header's **value** identifies the individual campaign, not your organization, so it is not a single static value you can pin one rule to.
* The header is **not a secret**, so on its own it should not be the only condition on a bypass — pair it with the sending-domain scope and an SPF or DKIM pass.

{% hint style="info" %}
If your security team would prefer a **stable, hard-to-guess header scoped to your tenant** to key allow rules on, ask your Herd representative — Herd can add one for your organization.
{% endhint %}

## Mimecast policies to configure

Scope every policy below to Herd's **sending domains** (and their `mail.` MAIL FROM subdomains), and — wherever the policy type allows a condition on authentication — require an **SPF or DKIM pass**. This lets Herd's legitimately-signed simulations through while a real attacker spoofing the same names is still caught.

### Required

These are needed for simulations to deliver and for click and open tracking to stay accurate:

* **Permitted Senders** — a permitted-senders / anti-spoofing bypass for Herd's sending domains, so the messages aren't blocked or flagged as spoofed.
* **URL Protection** — a bypass (do not rewrite, do not scan) for Herd's senders. If Mimecast rewrites and follows the tracked links, its own scan registers as a click before your user ever sees the message. Herd detects and discounts gateway scans server-side, but a bypass removes the noise at the source and is the reliable option.
* **Attachment Protection** — a bypass for Herd's senders, required for any template that carries an attachment, so the file is delivered intact rather than held or detonated.

### Recommended

* **Impersonation Protection** — an exception for Herd's sending domains. They deliberately resemble known brands and can trip newly-registered-domain or similar-domain checks.
* **Spam scanning and greylisting** — permit Herd's senders so a first-time send isn't delayed or scored as spam.
* **Scope by authentication, not IP.** Herd sends through Amazon SES shared IP space, which is broad and changes; the sending domains plus an SPF or DKIM pass are the stable, precise signal. Prefer domain-plus-authentication scoping over IP allow-listing.

## Verify the allowlist

1. In the Herd admin console, send a phishing simulation that includes your own mailbox.
2. Confirm the message arrives in your **Inbox** — not held, quarantined, or bounced by Mimecast — with its links intact and un-rewritten.
3. Open the link and confirm the click is attributed to you in the campaign results, and that no click appears before you opened the message (which would indicate URL Protection is still scanning it).
4. If the message is held or the link is rewritten:
   * Confirm the sending domain and its `mail.` MAIL FROM subdomain match exactly, and that you allowed the domains used in the simulation you sent.
   * Check that the URL Protection bypass applies to the same senders as the Permitted Senders rule.
   * Allow a few minutes for policy changes to propagate, then resend.

{% hint style="warning" %}
Mimecast policy changes can take a few minutes to apply across your organization. Allow time before testing delivery with a real simulation.
{% endhint %}