Mimecast to Microsoft 365 and IRONSCALES

TL;DR - The Easy Button Version

Important Notes Before You Begin

Comprehensive Migration Guide

For organizations wanting detailed documentation and a methodical approach

Overview

This document provides step-by-step technical instructions for migrating email security from Mimecast to Microsoft 365 with IRONSCALES.

Key Points:

• IRONSCALES can be activated immediately without affecting current mail flow (API-based, not MX-based)
• No security gap during migration - run IRONSCALES alongside Mimecast if desired
• Core migration is DNS changes, connector removal, and DKIM cutover

The migration involves four components (color coded throughout):

• DNS DNS changes: Redirecting mail flow from Mimecast to Microsoft 365
• MICROSOFT Exchange Online cleanup: Removing Mimecast connectors and IP restrictions
• MIMECAST Mimecast cleanup: DKIM handoff, DNS record removal, add-in removal
• IRONSCALES IRONSCALES deployment: API-based security activated independently of mail flow

Week 1: Pre-Migration Preparation (Optional but Recommended)

Step 1: MICROSOFT Document existing Mimecast configuration (Optional)

Only if needed for compliance or rollback planning:

Connect-ExchangeOnline

# Find Mimecast connectors
Get-InboundConnector | Where-Object {$_.Name -like "*Mimecast*"} |
  Export-Clixml -Path "C:\Backup\MimecastInboundConnector.xml"
Get-OutboundConnector | Where-Object {$_.Name -like "*Mimecast*" -or
  $_.SmartHosts -like "*mimecast*"} |
  Export-Clixml -Path "C:\Backup\MimecastOutboundConnector.xml"

# Document any transport rules referencing Mimecast
Get-TransportRule | Where-Object {$_.Name -like "*Mimecast*"} |
  Export-Clixml -Path "C:\Backup\MimecastTransportRules.xml"

Step 2: MIMECAST Identify Mimecast regional infrastructure

Document the specific Mimecast infrastructure in use. Mimecast uses standardized regional hostnames:

• US MX: us-smtp-inbound-1.mimecast.com, us-smtp-inbound-2.mimecast.com
• EU MX: eu-smtp-inbound-1.mimecast.com, eu-smtp-inbound-2.mimecast.com
• Smart hosts (outbound): us-smtp-o365-outbound-1.mimecast.com (or regional equivalent)

SPF includes to note for later removal:

• US: include:us._netblocks.mimecast.com
• EU: include:eu._netblocks.mimecast.com
• DE: include:de._netblocks.mimecast.com
• AU: include:au._netblocks.mimecast.com

Step 3: DNS Reduce DNS TTL values

Three days before cutover, reduce TTL on all mail-related DNS records:

• MX records: Set TTL to 300 seconds
• SPF TXT records: Set TTL to 600 seconds
• DKIM CNAME records: Set TTL to 600 seconds

Step 4: MICROSOFT Generate and enable Microsoft 365 DKIM keys

1. Navigate to Microsoft 365 Defender Portal > Email & collaboration > Policies & rules > Threat policies
2. Select DKIM
3. Select your domain and enable DKIM signing
4. Note the two CNAME records Microsoft generates — you'll add these to DNS now

Step 5: DNS Add Microsoft 365 DKIM CNAME records

Add the two CNAME records generated in Step 4. These can coexist with Mimecast DKIM records temporarily — Mimecast DKIM uses different selector names, so there's no conflict.

# Microsoft 365 DKIM CNAME records (example)
selector1._domainkey.yourdomain.com → selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey.yourdomain.com → selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Step 6: IRONSCALES Activate IRONSCALES protection

Contact IRONSCALES to provision your tenant:

1. IRONSCALES activation takes ~10 minutes
2. No mail flow changes required - works immediately via API
3. Can run alongside Mimecast without conflict
4. You'll receive login instructions and configuration guides

Week 2: Pre-Cutover Validation (Optional)

Step 1: MICROSOFT Verify Microsoft 365 configuration

Confirm Microsoft 365 is ready to receive mail directly:

1. Check that your domain is verified in Microsoft 365 admin center
2. Confirm all user mailboxes are created and licensed
3. Verify Exchange Online Protection is enabled
4. Test internal mail flow between Microsoft 365 users
5. Confirm M365 DKIM is enabled and CNAME records have propagated (critical for Mimecast migrations)

Step 2: MICROSOFT Document transport rules and connector settings requiring modification

List all rules and settings that reference Mimecast:

• Mimecast IP addresses in connector SenderIPAddresses
• Transport rules or connector settings like "reject messages if they aren't sent from within this IP address range" — if those IPs are Mimecast egress IPs, they'll need to be removed or updated
• Any Enhanced Filtering for Connectors (skip listing) configuration

Step 3: Create rollback plan

Document exact steps to revert if issues arise:

1. DNS record values to restore (screenshot current DNS settings)
2. Connector configurations to re-enable
3. Transport rules to reactivate
4. Mimecast DKIM can resume signing immediately if MX is reverted — no separate DKIM rollback needed

Week 3: Production Cutover (The Actual Migration)

Day 1 (Friday evening/maintenance window)

Step 1: DNS Add Microsoft 365 MX record (staged approach)

Add new MX record with higher preference number (lower priority):

MX Priority 20: [domain-name]-com.mail.protection.outlook.com
MX Priority 10: us-smtp-inbound-1.mimecast.com (existing Mimecast)

Step 2: DNS Update SPF record

Modify SPF to include both providers temporarily:

v=spf1 include:us._netblocks.mimecast.com include:spf.protection.outlook.com -all

Use your region-specific Mimecast include (see Week 1, Step 2).

Step 3: DNS Swap MX priorities

Once the new MX record has propagated, swap priorities:

MX Priority 10: [domain-name]-com.mail.protection.outlook.com (now primary)
MX Priority 20: us-smtp-inbound-1.mimecast.com (now fallback)

Monitor Exchange Admin Center mail flow reports. Confirm messages are arriving via Microsoft 365.

Day 2 (Saturday)

Step 4: DNS Remove Mimecast from SPF and remove Mimecast MX

After confirming stable mail flow to Microsoft 365:

# Final SPF record
v=spf1 include:spf.protection.outlook.com -all

# Remove Mimecast MX record(s) entirely
# Only Microsoft 365 MX should remain

Step 5: MICROSOFT Check for IP-range restrictions

• In Microsoft 365, you may have transport rules or connector settings like "reject messages if they aren't sent from within this IP address range"
• If those IPs are Mimecast egress IPs, either remove or update that restriction. After MX cutover, email may still egress Mimecast briefly due to caching; strict IP checks can cause rejects until caching expires

Step 6: MICROSOFT Remove Mimecast connectors

Option A — PowerShell

# Inspect existing connectors
Get-InboundConnector
Get-OutboundConnector

# Remove Mimecast connectors (replace Identity with your connector names)
Remove-InboundConnector -Identity "Mimecast Inbound" -Confirm:$false -WhatIf
Remove-OutboundConnector -Identity "Mimecast Outbound" -Confirm:$false -WhatIf

# When ready, rerun without -WhatIf to execute:
Remove-InboundConnector -Identity "Mimecast Inbound" -Confirm:$false
Remove-OutboundConnector -Identity "Mimecast Outbound" -Confirm:$false

Option B — Exchange admin center (EAC)

• Mail flow → Connectors
• Select the Mimecast inbound and/or outbound connector(s) → Delete

Typical deployments will have up to two Mimecast connectors: one inbound and one outbound.

Step 7: Verify mail flow and DKIM

1. Send test emails from external accounts (Gmail, Yahoo, etc.)
2. Verify IRONSCALES is processing messages in the dashboard
3. Check Microsoft 365 message trace for delivery confirmations
4. Check email headers on outbound mail to confirm M365 DKIM signatures are present (look for dkim=pass in Authentication-Results)
5. Verify DMARC alignment is passing with the new DKIM signing source

Day 3 (Sunday)

Step 8: MICROSOFT Configure EOP with IRONSCALES

Set baseline Exchange Online Protection (EOP) anti-spam policies so they operate cleanly alongside IRONSCALES:

• Follow the recommended EOP settings for use with IRONSCALES (configuration guidance in the IRONSCALES EOP white paper, starting on page 6)
• Apply the policies, then verify they don't conflict with IRONSCALES classification/quarantine workflows

Week 4: Cleanup and Optimization (Post-Migration - Optional)

Step 1: MIMECAST Remove Mimecast DKIM DNS records

Now that Microsoft 365 is handling DKIM signing, remove Mimecast's DKIM CNAME or TXT records from your DNS. These typically use Mimecast-specific selectors (e.g., mimecast20230512._domainkey) and won't conflict with M365, but removing them keeps DNS clean.

Step 2: MIMECAST Remove Mimecast Outlook Add-in

Remove the Mimecast for Outlook plugin from Microsoft 365 Admin Center → Settings → Integrated Apps. This add-in provides encryption triggers and phishing reporting buttons that are no longer needed.

Step 3: DNS DNS cleanup

• Remove any Mimecast-specific TXT or CNAME records used for domain verification
• Remove Mimecast Targeted Threat Protection CNAME records (used for URL rewriting) if present
• If Mimecast DMARC monitoring was used, update the DMARC record's rua and ruf tags to remove Mimecast addresses
• Restore MX TTL to normal values

Step 4: MIMECAST Export Mimecast data (Optional)

Before your Mimecast subscription expires, export any data you need to retain:

• Mimecast archive content (if using Mimecast's archiving service)
• Message tracking logs for compliance records
• Allow/block lists (recreate critical entries in EOP if needed)
• Quarantine hold messages

Post-Migration Monitoring (Optional Ongoing Tasks)

Daily tasks (first week)

• Review IRONSCALES dashboard for classification accuracy
• Check message trace in Exchange Admin Center for delivery issues
• Monitor for user-reported false positives or false negatives
• Verify DKIM pass rate in DMARC aggregate reports — this is the key metric for Mimecast migrations

Weekly tasks (first month)

• Review IRONSCALES incident reports for detection trends
• Confirm DMARC reports show expected alignment (SPF + DKIM)
• Validate EOP policies are complementing IRONSCALES correctly
• Check that no Mimecast DNS records have been inadvertently restored

Rollback Procedures

Within 4 hours of cutover

1. DNS Revert MX record priorities (Mimecast back to lowest number)
2. DNS Restore Mimecast SPF include
3. Mimecast resumes DKIM signing automatically once mail flows through it again — no separate DKIM rollback required
4. IRONSCALES continues to protect — no action needed on the IRONSCALES side

After 4 hours but within 48 hours

1. Same DNS steps as above
2. If connectors were already removed, recreate them from your exported configuration (Week 1, Step 1)
3. Re-enable any IP-range restrictions that were removed

Known Issues and Resolutions

DKIM failures after cutover

• Symptom: Outbound mail fails DKIM authentication; DMARC reports show dkim=fail
• Cause: Microsoft 365 DKIM was not enabled before MX cutover. Mimecast was handling DKIM signing, and that stopped when mail flow changed
• Fix: Enable M365 DKIM immediately in the Defender portal. Add the two CNAME records if not already present. DKIM signing begins within minutes of CNAME propagation

Bounces during DNS caching window

• Symptom: Some senders see bounce backs during the first 24 hours after cutover
• Cause: DNS caching is still directing some mail to Mimecast while connectors have been removed, or IP-range restrictions are rejecting mail from non-Mimecast sources
• Fix: Keep connectors alive for 24 hours after MX swap. Remove IP-range restrictions before or at the same time as MX changes. Plan cutover during a low-volume period (Friday evening) and notify users in advance

Mimecast URL rewriting in historical emails

• Symptom: Links in older emails still route through Mimecast Targeted Threat Protection URLs (protect-us.mimecast.com/...)
• Cause: Mimecast rewrote URLs in delivered messages. These rewritten URLs depend on active Mimecast service to resolve
• Fix: Coordinate with Mimecast on their URL rewriting retention policy. As long as your Mimecast subscription remains active, existing rewritten URLs continue to work. Once the subscription terminates, those links may break. Notify users if needed

Orphaned Mimecast Outlook Add-in

• Symptom: Users see Mimecast buttons in Outlook that no longer function
• Cause: The Mimecast for Outlook add-in was not removed during cleanup
• Fix: Remove from Microsoft 365 Admin Center → Settings → Integrated Apps (see Week 4, Step 2)