Mimecast SPF, DKIM and DMARC setup, step by step

For mail already routed through Mimecast Email Security’s MX-based gateway, publish the appropriate Mimecast SPF authorization and the public DKIM TXT record generated for your internal domain. Then validate and save the signing definition, attach it to a matching outbound policy, and verify a real message. Publishing a key or receiving a successful DNS-check result does not establish that the policy signs your actual mail.

This guide covers an authorized internal domain in the Mimecast Administration Console. It does not onboard a new gateway, configure external-domain signing, change inbound filtering, or configure a separate marketing platform. Your mail must actually leave through the outbound route being authenticated. Official outbound definition · Official policy and SPF instructions.

This is documentary guidance; no customer account, DNS or message was tested.

On this page: Establish the route and change boundary · Identify the account grid before choosing SPF · Generate the internal domain’s DKIM definition · Publish the exact public TXT record · Apply the verified definition to the outbound policy · Accept the actual message, not just the green status · Troubleshoot by the failing layer · Frequently asked questions

Establish the route and change boundary

Identify the internal domain, approved visible From address, current outgoing gateway, actual envelope sender and account grid. Confirm that the domain is already authorized and available in the console. Obtain approval for the particular domain, signing definition, policy scope and DNS changes. Confirm the operator has the required administrative access; these instructions do not establish a universal subscription entitlement.

Record the current DNS RRsets, selectors, policy associations and rollback owner before changing them. Include application and fallback routes in the inventory: a mailbox message through Mimecast does not prove that an application bypassing the gateway is covered. Do not switch connectors, change MX records or grant new relay authority merely to follow this guide.

Keep existing upstream DKIM signatures and their dependencies in the inventory. A signature is not invalid simply because a different server delivers the message. Changes to signed headers or body content can invalidate it. Mimecast’s overview cautions about upstream signing when it is the final gateway; treat this as a reason to validate the complete path, not permission to disable every other signer. The intended Mimecast signature must independently pass and align for this setup. Mimecast route considerations.

Identify the account grid before choosing SPF

Do not select a regional include from your office’s location. Mimecast identifies the routing grid from the account code. Find it in the dashboard’s Account Summary, Account > Account Settings, or the avatar menu’s Account and support details. The documented US codes distinguish A-grid and B-grid accounts. Official account-grid identification.

The current outbound policy guide lists these mechanisms:

These are authorization mechanisms, not complete replacement policies. Confirm the applicable entry against the account’s actual routing. The region guide includes Singapore, but the reviewed SPF table does not provide a Singapore-specific mechanism. Do not manufacture one or infer an Offshore account-code mapping. Ask Mimecast for the current applicable authorization where the documented mapping is incomplete. Do not broaden regional authorization to the global option without the DNS owner’s approved design. Provider SPF table.

Merge into the correct single SPF policy

SPF evaluates the SMTP MAIL FROM domain, or HELO in the applicable null-sender case, not automatically the visible From. Determine the actual evaluated owner before editing DNS. A service-owned envelope identity may pass SPF without aligning with your visible From.

Inspect the current TXT policy and its dependency chain. Keep one v=spf1 policy per evaluated owner, preserving legitimate senders, qualifiers and deliberate ordering. Add only the approved missing authorization. If an existing include already provides the required Mimecast coverage, do not duplicate it. Do not copy the provider’s illustrative IP addresses, Unicode dash or an incomplete prose example into DNS.

Review the ten evaluated DNS-dependent-term budget, including nested mechanisms. It is not a limit of ten visible includes. An all mechanism suppresses redirect; mechanisms after a matching all cannot authorize another sender. A careful merge must preserve intentional exclusions rather than blindly moving an include ahead of them. SPF qualifiers describe authentication results, not a guarantee of delivery or rejection by every receiver. SPF rules.

Generate the internal domain’s DKIM definition

In the Administration Console, open Policies > Gateway Policies, then Definitions and the outbound signing definition type. Create the authorized definition or inspect the existing one. Enable the DKIM-signing option and select the intended internal domain through its lookup control. Use a clear description so a policy can be associated with the correct domain later.

Choose the supported key length and generate the pair. For a new internal-domain configuration, prefer 2048 bits where the DNS service supports the record representation. Mimecast retains the private key and displays the public value. Do not attempt to retrieve or transfer a private key. Copy the complete generated DNS Address and Public Key for that domain. Do not invent a selector from a date or another account’s example.

The provider requires a definition and policy association for each internal domain. Do not reuse one domain’s definition as blanket coverage for all domains. Leave external-domain signing outside this workflow; its separate prerequisites and restrictions are not needed to authenticate an already-authorized internal domain. Definition fields and key handling.

Before generating or replacing anything, check whether the selector is already serving live mail. A rotation must preserve the old public key for queued or delayed messages according to the approved rotation plan. Do not regenerate keys repeatedly while diagnosing a DNS-name mistake.

Publish the exact public TXT record

At authoritative DNS for the generated owner, publish the complete issued public value as TXT. The structural owner format is selector._domainkey.domain; this describes the structure, not a record to paste.

Map the full owner into the correct zone. If the DNS editor automatically appends the zone name, enter the required relative owner only. For a separately delegated child zone or _domainkey namespace, use its actual authority instead of assuming the parent zone controls it. Confirm the final saved fully qualified name to avoid a doubled suffix.

Do not place a TXT record beside a CNAME at the same owner, overwrite another selector, or remove an NS delegation blindly. Coordinate a supported record location with the DNS owner if there is a conflict. No mailbox MX, nameserver or DNSSEC change is required merely to publish this DKIM TXT.

Preserve the full tagged public-key value. The DNS TXT character-string limit is not a universal 255-character maximum for the entire resource record: a long value can use multiple strings within one TXT resource record when supported by the host. Do not create separate keys, truncate the value or insert arbitrary spaces into its base64 key material. Have the DNS provider preserve the exact logical issued value and confirm the answer matches. Mimecast publication instructions.

Back in the definition, run Check DNS and compare the resolved value with the issued public key. Correct the authoritative owner or value before merely waiting. Mimecast mentions up to 72 hours when a new TXT is not found; this is not a guarantee and does not fix publication at the wrong DNS provider. After a successful check, save the definition. Mimecast explicitly says that a validated key not saved will not be used for outbound signing.

Apply the verified definition to the outbound policy

Open the outbound DNS Authentication policy under the gateway policy controls. Select the newly verified definition. Review the actual matching scope before enabling it: the definition identifies the signing domain, but the policy decides which messages receive it.

Mimecast’s documented internal-domain policy uses both address forms for matching, a specific sending email domain, all recipients, and an enabled validity period. It leaves policy override unchecked and source-IP restrictions blank in its example. These settings can expand which messages match; do not copy them over a deliberately narrower production policy without approval. Match the authorized sender domain, recipient scope, validity period and route, and check more-specific or overriding policies before saving. Outbound policy fields and example.

A policy’s “Both” address-matching option is not a change to the SPF protocol’s identity. Continue evaluating SPF against the actual envelope identity. Do not enable bi-directional matching, change inbound rejection settings, or add bypasses as a side effect of outbound signing. If existing policy precedence is unclear, resolve it with the administrator before release rather than forcing a global override.

Accept the actual message, not just the green status

After the approved definition and policy are saved, send a harmless message through the intended established route to a controlled external recipient. Test applications, mailbox traffic and materially different policy matches separately. Preserve the intended From; a rewritten provider sender is not successful authentication of the original brand.

Use authentication results generated inside the receiving service’s known processing boundary, following its documented treatment of externally supplied Authentication-Results. Ignore injected or otherwise untrusted result headers. A familiar authserv-id or header position alone is not a trust guarantee. Receiver-result trust model.

Record:

1. The actual visible From and MAIL FROM identities, route and test time.
2. The intended Mimecast DKIM signature’s d= domain and selector, matching the definition, with trusted dkim=pass.
3. Alignment of that intended passing signature with visible From under the effective DMARC policy.
4. Trusted dmarc=pass for that From, plus the independent SPF result and evaluated identity.

Relaxed DKIM alignment requires the same Organizational Domain; strict alignment requires an exact domain match. SPF alignment compares its authenticated envelope domain with visible From on the corresponding relaxed or strict basis. A child envelope domain does not automatically satisfy strict alignment. DMARC can pass through aligned SPF alone, so that pass does not prove the intended Mimecast DKIM signature is working. Alignment rules · Raw DKIM results versus aligned policy results.

Retain existing direct or inherited DMARC protection and approved report destinations. This task does not require a new policy, a downgrade to monitoring or a new reporting recipient. Authentication and correct routing also do not guarantee inbox placement.

Troubleshoot by the failing layer

If a change fails, pause the affected controlled rollout and restore only the approved configuration. Retain public keys still needed by queued mail or other routes. Give support redacted domain/selector, definition and policy identifiers, grid, timestamps and trusted result evidence, not credentials or private message contents.