Deploying Sophos Email Security changes how mail flows to your organisation — all inbound mail is re-routed through Sophos's cloud scanning infrastructure via an MX record change before being delivered to your Microsoft 365 or Google Workspace inbox. Getting the DNS changes, SPF configuration, and Sophos Central setup right is what separates a seamless cutover from a mail delivery disruption.
This guide covers the complete migration to Sophos Email Security, whether you are moving from native M365/Google Workspace filtering, from a competing vendor like Mimecast or Barracuda, or deploying email security for the first time on your domain.
Why Organisations Migrate to Sophos Email Security
The primary drivers for moving to Sophos Email Security in India:
BEC and impersonation protection. Microsoft 365's native filtering and Google Workspace's built-in protection are effective against bulk spam and known malware. They are less effective against business email compromise — CEO fraud, vendor impersonation, lookalike domain attacks — because these emails carry no malicious payload. Sophos Email Advanced includes AI-based impersonation detection specifically trained on BEC patterns.
Completing the Sophos Synchronized Security stack. Organisations already running Sophos Intercept X endpoint protection and Sophos XGS Firewall add Sophos Email Security to complete the Synchronized Security loop — one Sophos Central console managing email, endpoint, and firewall security with cross-product threat sharing.
Moving from a competing email security vendor. Indian organisations migrating off Mimecast, Barracuda, or Proofpoint to consolidate vendors or reduce cost move to Sophos Email, typically with a straightforward MX record swap.
Adding email encryption and DLP. Organisations in BFSI, legal, or healthcare needing email encryption and Data Loss Prevention (DLP) for outbound mail move to Sophos Email Standard or Advanced, which include both natively.
How Sophos Email Security Deploys
Sophos Email Security deploys as an MX gateway — it sits between the public internet and your mail server. When you change your domain's MX records to point to Sophos's cloud infrastructure, all inbound mail routes through Sophos's scanning engine before delivery to your Microsoft 365 or Google Workspace mailbox.
This is different from Microsoft Defender for Office 365's API-based integration (which scans within M365 without MX changes). Sophos Email is MX-gateway-based across all configurations — both M365 and Google Workspace use the same deployment model.
What this means for migration:
- An MX record change is required — this is the core cutover step
- SPF record update is required — Sophos needs to be authorised as a sending source
- Your mail server (M365 or GWS) configuration needs to be updated to accept mail from Sophos and bypass re-filtering
- DNS propagation takes 15–60 minutes with proper TTL management
Pre-Migration Checklist
Before making any changes, document and prepare:
1. Current DNS state
- Record all existing MX records (hostname, priority, TTL) — copy these exactly
- Copy your current SPF TXT record in full
- Note any existing DKIM selectors published in DNS
- Check your current DMARC policy at
_dmarc.yourdomain.com
2. Sophos Central setup
- Log in to Sophos Central (central.sophos.com) — access provisioned by Cloudfy at licence activation
- Navigate to Email Security — confirm Sophos Email is available in your account
3. Mail platform admin access
- Microsoft 365: Global Admin access for Exchange connector and anti-spam policy changes
- Google Workspace: Super Admin access for inbound gateway and SMTP relay configuration
4. Cutover window planning
- Plan the MX change for a low-mail-volume period (Friday evening or Saturday morning)
- Inform your IT team of the maintenance window
- Have mobile phone hotspot or alternate internet available for management access during the window (in case WAN goes down during the process)
Step 1 — Add Your Domain to Sophos Email Security
- Log in to Sophos Central (central.sophos.com)
- Navigate to Email Security → Domains
- Click Add Domain and enter your primary domain:
yourcompany.com - Sophos generates a domain ownership verification TXT record:
Type: TXT
Name: _sophos-domain-verification.yourcompany.com
Value: sophos-verify-xxxxxxxxxxxxxxxxxx
TTL: 3600
Add this record to your DNS at your registrar (GoDaddy, Namecheap, BigRock, Cloudflare, or your hosting provider).
- DNS propagation typically completes within 15–30 minutes. Return to Sophos Central and click Verify — the domain status changes to Verified.
If you have additional domains receiving mail (e.g., yourcompany.in or a subsidiary domain), repeat this step for each domain.
Step 2 — Configure Sophos Email Policies Before Cutover
Configure your inbound scanning policies in Sophos Central before making any DNS changes. This ensures protection is active the moment mail starts flowing through Sophos.
Inbound anti-spam and anti-malware:
- Navigate to Email Security → Policies → Inbound
- Enable anti-spam: set sensitivity to Medium initially; review quarantine for 48 hours before tightening
- Enable anti-malware: set action to Quarantine for suspected malware
- Enable attachment sandboxing: block password-protected archives if required
Impersonation protection (Advanced licence):
- Navigate to Impersonation Protection
- Add your executives and finance team members to the protected identity list
- Enable lookalike domain detection for your domain and any closely related domains
- Set action to Quarantine for detected impersonation attempts
Quarantine and end-user digest:
- Configure quarantine digest notifications — daily digest to end users showing their quarantined email
- Configure the release and allow-listing behaviour: end users can release spam but not malware
Outbound policies:
- Enable outbound scanning for DLP and malware if you have the relevant licence tier
- Configure outbound mail routing through Sophos (covered in the M365/GWS-specific sections below)
Step 3 — Lower Your MX Record TTL
One hour before your planned cutover:
- Log in to your DNS registrar
- Change the TTL on your existing MX records to 300 seconds (5 minutes)
- Save the change and wait 30 minutes for the existing cached TTL to expire
With a 5-minute TTL, global DNS propagation after your MX change will complete within 5–15 minutes instead of 24–48 hours. This minimises the window during which some external senders are still delivering to your old MX destination.
Step 4 — Get Your Sophos MX Records
In Sophos Central:
- Navigate to Email Security → Domains → your domain
- Find the MX Records section — Sophos shows your assigned MX hostnames:
Priority: 10 MX: [assigned-hostname].sophos-mx.com
Priority: 20 MX: [assigned-hostname-2].sophos-mx.com
The exact MX hostnames are specific to your Sophos account and regional datacenter. Use the values shown in your Sophos Central portal, not any generic examples.
Step 5 — Update SPF Record
Sophos routes your outbound mail through its infrastructure (when outbound scanning is enabled). Sophos's sending IP ranges must be authorised in your SPF record.
Locate your existing SPF TXT record (query at your registrar or use an online SPF checker). It might look like:
For M365:
v=spf1 include:spf.protection.outlook.com -all
For Google Workspace:
v=spf1 include:_spf.google.com ~all
Add Sophos's SPF include:
For M365 with Sophos:
v=spf1 include:spf.sophos.com include:spf.protection.outlook.com ~all
For Google Workspace with Sophos:
v=spf1 include:spf.sophos.com include:_spf.google.com ~all
Important rules:
- There must be exactly one SPF TXT record per domain — do not create a second SPF record; update the existing one
- If migrating from a competing vendor, remove their SPF include
- The
include:spf.sophos.comentry resolves Sophos's current sending IP ranges dynamically — always use the include form, not hardcoded IPs - Keep total DNS lookups (each
include:counts as one) under 10
Publish the updated SPF record and verify it with an online SPF checker before proceeding to the MX cutover.
Step 6 — MX Record Cutover
At your planned maintenance window start:
- Log in to your DNS registrar
- Delete your existing MX records
- Add the Sophos MX records from Step 4 with your assigned Sophos hostnames:
Priority: 10 [your-assigned-sophos-mx-hostname]
Priority: 20 [your-assigned-sophos-mx-backup-hostname]
- Set TTL to 3600 on the new MX records
- Note the exact time of the change
Within 5–15 minutes (given the TTL lowering in Step 3), new inbound mail for your domain will route through Sophos. Mail already accepted by your old MX provider will continue to be delivered to your mailbox — there is no loss of already-accepted mail.
Step 7A — Microsoft 365 Post-Cutover Configuration
After the MX change, configure M365 to properly handle Sophos-scanned mail.
Create an Inbound Connector
Without a connector, Microsoft Defender may re-filter Sophos-scanned mail and cause false positives.
In Microsoft 365 Admin Centre → Exchange Admin Centre → Mail Flow → Connectors:
- Click New → From: Partner organisation → To: Office 365
- Name:
Sophos Email Security - Identify sender by: Sender's IP address ranges
- Add Sophos's inbound mail IP ranges (published in Sophos Central documentation or provided by Cloudfy at setup)
- Enable Require TLS for this connector
- Enable Bypass Microsoft 365 spam filtering for email from this connector
Configure the Anti-Spam Policy
In Microsoft 365 Defender → Email & Collaboration → Policies & Rules → Anti-spam policies:
- Create or edit the default inbound policy
- Add Sophos's IP ranges to the Allowed IP addresses list (connection filter policy)
- This ensures Microsoft treats Sophos-delivered mail as pre-screened
Set Sophos as the Delivery Destination in Sophos Central
In Sophos Central → Email Security → Domains → your domain → Mail Delivery:
- Set Destination mail server to:
yourtenantname.mail.protection.outlook.com(your M365 MX endpoint) - Port: 25
- Enable TLS: Yes
Sophos scans inbound mail, then delivers clean mail to your M365 mail endpoint.
Step 7B — Google Workspace Post-Cutover Configuration
Configure Inbound Gateway in Google Admin
- In Google Admin Console → Apps → Google Workspace → Gmail → Spam, Phishing, and Malware
- Scroll to Inbound Gateway
- Enable Inbound Gateway
- Add Sophos's inbound mail IP ranges (provided in Sophos Central or by Cloudfy)
- Enable Automatically detect and reject mail from this IP that is not authenticated — enable after DKIM is configured
- Enable Require TLS for connections from the email gateways listed above
- Check Message is considered spam if the following header regexp matches — this enables passing Sophos's spam verdict to Google
Set Sophos as the Delivery Destination in Sophos Central
In Sophos Central → Email Security → Domains → your domain → Mail Delivery:
- Set Destination mail server to:
aspmx.l.google.com(Google Workspace MX) - Port: 25
- Enable TLS: Yes
Outbound Mail Through Sophos (Optional)
To route outbound Google Workspace mail through Sophos for DLP and outbound scanning:
- In Google Admin → Apps → Google Workspace → Gmail → Routing → SMTP relay service
- Add Sophos's SMTP relay server address (available in Sophos Central → Email Security → Outbound Routing)
- Authentication: requires TLS
Step 8 — DKIM Configuration
DKIM adds a cryptographic signature to your outbound mail, allowing receiving servers to verify authenticity.
For outbound mail routed through Sophos (MX gateway outbound):
- In Sophos Central → Email Security → DKIM
- Generate a new DKIM key pair (2048-bit RSA recommended)
- Sophos provides the DNS record to publish:
Type: TXT
Name: sophos._domainkey.yourcompany.com
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkq...
TTL: 3600
- Publish this record and click Verify DKIM in Sophos Central
- Enable DKIM signing for outbound mail
For M365 DKIM (when M365 handles outbound directly): Configure DKIM in Microsoft 365 Defender → Email & Collaboration → Policies & Rules → Email Authentication → DKIM. This is independent of Sophos's DKIM and handles M365-originated messages.
Step 9 — DMARC Setup
DMARC tells receiving servers what to do with messages that fail SPF or DKIM alignment from your domain.
Publish a TXT record at _dmarc.yourcompany.com:
Start with monitoring mode:
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; sp=none; adkim=r; aspf=r
After 4–6 weeks, analyse aggregate reports (rua) to confirm all legitimate mail is passing SPF and DKIM before moving to p=quarantine and eventually p=reject.
Post-Migration Validation Checklist
Complete these checks 24–48 hours after the MX cutover:
- Inbound mail is appearing in Sophos Central's Message History log
- Quarantine contains appropriate spam/phishing — no obvious false positives
- Impersonation Protection alerts are firing (Advanced) — check alert email
- SPF check: external lookup shows
include:spf.sophos.comin your SPF record - DKIM check: selector record is live at
sophos._domainkey.yourdomain.com - Send a test message from external (Gmail) to your domain — appears in Sophos Message History
- Send a test message from your domain to external — check headers at recipient side for DKIM pass and Sophos headers
- Use mail-tester.com to confirm outbound score (SPF pass, DKIM pass, DMARC pass)
- End users are receiving quarantine digest notifications
- No reports of missing legitimate mail (false positives)
- Old vendor's MX entries are fully removed from DNS
Common Mistakes to Avoid
Not lowering the MX TTL before cutover. Default TTLs of 86400 (24 hours) mean some global DNS resolvers cache your old MX for up to 24 hours after you change it. External senders with cached old MX records keep delivering to the old destination during this window. Always lower TTL to 300 at least 30 minutes before the switch.
Forgetting to create the M365 inbound connector. Without the connector, Microsoft Defender re-scans Sophos-delivered mail and may quarantine it. This creates confusing double-quarantine situations where a message passes Sophos but Microsoft blocks it.
Removing the previous vendor's SPF before verifying Sophos SPF is live. Verify the updated SPF record (with Sophos include, old vendor removed) is propagated before making the MX change.
Starting with aggressive impersonation sensitivity. Begin with Medium sensitivity and review quarantine for 48 hours. Some legitimate external senders use patterns that trigger impersonation detection — identify and whitelist them before tightening.
Not configuring outbound routing through Sophos. If you want DLP and outbound scanning, configure M365/GWS to route outbound mail through Sophos's SMTP relay. This is a separate step from inbound MX — easy to miss.
Frequently Asked Questions
How long does migration to Sophos Email Security take? The full migration — domain verification, policy configuration, DNS cutover, M365/GWS connector setup, and post-cutover validation — takes 3–5 hours. The MX propagation itself takes 5–30 minutes with proper TTL management.
Will there be any mail delivery downtime? With proper TTL lowering before cutover, the delivery gap is under 5 minutes. Mail in transit during the cutover window is queued by sending servers and delivered within minutes once Sophos MX records propagate.
Can we run Sophos alongside our current email security vendor during migration? You cannot have two MX gateways simultaneously (mail routes to only one MX). A brief parallel window is possible by using MX priority weights (lower priority = backup), but in practice this adds complexity without meaningful benefit. The standard approach is a direct cutover.
What happens to quarantined mail at our old vendor after migration? Mail quarantined at your previous vendor before the cutover remains in that quarantine until the subscription ends. Sophos quarantine starts fresh from the cutover date.
Can Cloudfy manage the Sophos Central console for us after migration? Yes — Cloudfy provides managed email security services, handling policy updates, quarantine review, SPF/DKIM/DMARC management, and Sophos Central configuration on your behalf.
Ready to migrate to Sophos Email Security? Contact Cloudfy Systems — authorised Sophos Partner in India. We handle the full migration with zero-downtime cutover and 48-hour post-migration monitoring.