Migrating to Barracuda Email Protection in India — Step-by-Step Guide for M365 & Google Workspace

Switching your organisation's email security platform is one of the higher-stakes IT decisions you will make. Done correctly, the migration is invisible to your users — mail flows without interruption, existing policies carry over, and protection improves from day one. Done incorrectly, it creates mail delivery gaps, quarantine confusion, and user complaints.

This guide covers everything you need to know about migrating to Barracuda Email Protection in India — whether you are moving from native Microsoft 365 filtering, from a competing vendor like Mimecast or Proofpoint, or deploying email security for the first time on Google Workspace.

Why Organisations Switch to Barracuda Email Protection

The most common reasons Indian organisations migrate to Barracuda Email Protection:

Inadequate BEC protection from native M365 filtering. Microsoft Defender for Office 365 (Plan 1 and Plan 2) is effective against known malware and mass phishing campaigns. It is less effective against targeted business email compromise — CEO fraud, vendor impersonation, lookalike domain attacks — because these emails contain no malicious payload. Barracuda's AI models are specifically trained on BEC patterns.

Account takeover incidents. Once attackers compromise a Microsoft 365 mailbox, they typically set up inbox rules to intercept finance-related emails and delete alert notifications. Barracuda Advanced and Premium Plus include Account Takeover Protection that detects anomalous login behaviour and mailbox rule changes in real time.

Moving from an on-premise gateway. Indian organisations running on-premise Barracuda Email Security Gateway (ESG) hardware or legacy appliances are migrating to cloud-delivered Barracuda Email Protection as hardware reaches end-of-life.

Consolidating vendors after a merger or acquisition. Multi-entity Indian organisations often end up with different email security tools across entities. Barracuda Email Protection covers M365 and Google Workspace from a single management console.

Compliance and archiving requirements. Organisations in BFSI, healthcare, and legal sectors requiring email archiving, DLP, or audit-trail capabilities for SEBI, RBI, or DPDP Act compliance move to Barracuda Premium Plus.

Barracuda Email Protection Deployment Modes

Before planning a migration, understand how Barracuda Email Protection connects to your mail environment. There are two fundamentally different deployment architectures:

API-Inline Mode (Recommended for Microsoft 365)

Barracuda connects to Microsoft 365 via the Microsoft Graph API using OAuth consent. Mail continues to flow through Microsoft's mail servers — Barracuda intercepts and scans each message via the API before it lands in the user's inbox.

What this means for migration:

Zero MX record changes required — no DNS cutover, no mail flow disruption
No connection to Barracuda mail servers — mail routing is unchanged
Scanning is in-path — messages are held briefly during scanning, then delivered or quarantined
Internal mail is also scanned — unlike MX gateway mode, API-inline can scan internal-to-internal email, which is where account takeover threats often propagate

This is the preferred mode for M365 organisations because it eliminates the single biggest migration risk: DNS propagation and mail delivery gaps during MX record changeover.

MX Gateway Mode (Used for Google Workspace and Some M365 Deployments)

Your domain's MX records are changed to point to Barracuda's cloud mail scanning infrastructure. All inbound mail is routed through Barracuda before being delivered to your mail server. Outbound mail can also be routed through Barracuda for scanning and policy enforcement.

What this means for migration:

MX record change is required — this is the critical step; execution timing matters
SPF record update required — your SPF record must authorise Barracuda's IP ranges
Existing mail server remains unchanged — Barracuda is a layer in front of it, not a replacement
Google Workspace uses this mode — GWS does not support Graph API integration

Pre-Migration Checklist

Complete these steps before making any changes:

1. Document your current state

Record all current MX records (hostname, priority, TTL) — screenshot or export to a text file
Copy your existing SPF TXT record in full
Note any existing DKIM selectors published in DNS
Note your current DMARC policy (if any): p=none, p=quarantine, or p=reject
Export current email security policies (blocked senders, allowed senders, quarantine rules) from your existing tool

2. Identify your user base

Total licensed M365 or GWS users who will be covered by Barracuda
Any shared mailboxes, distribution lists, or service accounts that receive external email
Any mail-enabled groups or aliases

3. Prepare your Barracuda account

Activate your Barracuda Email Protection licences (Cloudfy provisions these)
Log in to the Barracuda Email Protection admin portal
Have your M365 Global Admin or Google Workspace Super Admin credentials ready

4. Plan your cutover window

For API-inline (M365): no cutover window needed — activation is instant
For MX gateway: plan cutover for a low-email-volume period (Friday evening or weekend)
Inform your IT team and, if needed, your end users about the migration date

Migration Path A: From Native M365 Filtering to Barracuda (API-Inline)

This is the most common migration scenario in India. Your organisation uses Microsoft 365 with default Microsoft Defender for Office 365 filtering, and you are adding Barracuda Email Protection on top via API-inline.

Step 1 — Add Your Domain to Barracuda Email Protection

Log in to the Barracuda Email Protection portal
Navigate to Domains → Add Domain
Enter your primary domain (e.g., yourcompany.com)
Barracuda will show you a domain ownership verification record:

Type: TXT
Name: @yourcompany.com (or as instructed)
Value: barracuda-domain-verify=xxxxxxxxxxxxxxxxxx
TTL: 3600

Add this record to your DNS. Verification typically completes within 15–60 minutes.

Step 2 — Connect Barracuda to Microsoft 365 via Graph API

In the Barracuda portal, navigate to Microsoft 365 → Connect Microsoft 365
Click Authorise — this redirects you to the Microsoft OAuth consent screen
Log in with your M365 Global Admin account
Review and accept the Microsoft Graph API permissions Barracuda requires:
- Read and write to mailboxes (for scanning and remediation)
- Read organisation details (for tenant verification)
- Access to security events (for Account Takeover Protection)
Return to the Barracuda portal — the connection status should show Connected

Barracuda will begin scanning your M365 tenant immediately. There is no mail flow disruption — the API connection is additive.

Step 3 — Configure Inbound Policies

Before Barracuda starts acting on email (not just scanning), configure your inbound policies:

Anti-phishing sensitivity: Start at Medium; review quarantine for 48 hours before tightening
BEC / Impersonation Protection: Enable and add your domain's executives and finance team members to the protected sender list
Quarantine notification digest: Configure daily quarantine digest emails for end users
Safe senders list: Import any existing allowed-sender lists from your previous tool

Step 4 — Enable Account Takeover Protection (Advanced and Above)

Navigate to Account Takeover Protection in the Barracuda portal
Enable Login Monitoring — Barracuda will baseline normal login patterns for each user over 7–14 days before alerting
Enable Mailbox Rules Monitoring — alerts when new inbox rules are created (attacker behaviour)
Set alert recipients (IT admin email addresses)

Step 5 — Validate and Go Live

Monitor the Barracuda portal for 48 hours:

Check the Message Log to confirm inbound mail is being scanned
Check Quarantine to verify legitimate mail is not being quarantined incorrectly
Review Impersonation Protection hits to tune sensitivity if needed

No DNS changes, no MX cutover, no end-user impact.

Migration Path B: From a Competing Vendor (MX Gateway Swap)

If you are migrating from Mimecast, Proofpoint, or another MX-gateway-based email security tool, the migration involves a DNS cutover.

Step 1 — Activate Barracuda and Configure Policies in Parallel

Set up Barracuda Email Protection completely — domain verification, policy configuration, safe senders, blocked senders — before making any DNS changes. Run Barracuda in monitoring mode (not enforcement) if possible.

Step 2 — Lower Your MX Record TTL

One week before your planned cutover, reduce the TTL on your existing MX records to 300 seconds (5 minutes). This ensures that when you make the MX change, global DNS propagation is complete within minutes rather than 24–48 hours.

Step 3 — Get Your Barracuda MX Records

In the Barracuda Email Gateway Defense portal:

Navigate to Domains → your domain → MX Records
Barracuda will show you your assigned MX hostnames, for example:

Priority: 10    MX: cluster1.mx.barracudanetworks.com
Priority: 20    MX: cluster2.mx.barracudanetworks.com

These are specific to your Barracuda account — use the values shown in your portal, not these examples.

Step 4 — Update SPF Record

Add Barracuda's SPF include to your existing SPF record:

Before:

v=spf1 include:spf.protection.outlook.com ~all

After (Barracuda MX gateway added):

v=spf1 include:spf.barracudanetworks.com include:spf.protection.outlook.com ~all

If you are removing your old vendor, also remove their SPF include from this record.

Step 5 — Perform the MX Cutover

At your planned cutover window:

Log in to your DNS registrar or DNS management panel
Delete your existing MX records (the ones pointing to your old vendor or directly to M365)
Add the Barracuda MX records from Step 3
Set TTL to 3600 (1 hour) on the new records
Note the exact time of the change

Within 5–10 minutes (given the TTL lowering in Step 2), new inbound mail will begin routing through Barracuda. Mail that was queued at your old vendor's servers will continue to be delivered to your mailboxes — there is no gap in already-accepted mail.

Step 6 — Configure M365 to Accept Mail from Barracuda

Create an inbound connector in Microsoft 365 that:

Accepts mail from Barracuda's IP ranges (documented in Barracuda's admin guide)
Bypasses Microsoft's own spam/phishing filtering for mail already scanned by Barracuda

Without this step, Microsoft may re-filter Barracuda-scanned mail and quarantine legitimate messages.

Step 7 — Decommission Your Old Vendor

After 48–72 hours of confirmed stable mail flow through Barracuda:

Cancel your old vendor's subscription (check your contract notice period)
Remove their SPF include from your SPF record (if not done in Step 4)
Remove their CNAME or TXT DNS verification records
Archive any historical message logs or reports you need to retain

Migration Path C: Google Workspace with Barracuda (MX Gateway)

Barracuda Email Protection connects to Google Workspace in MX gateway mode — the same DNS-based approach as Path B above. The key difference is on the Google side.

Inbound Routing in Google Admin Console

After updating MX records to Barracuda, configure Google Workspace to:

Allow Barracuda's IP ranges as trusted sources: In Google Admin → Apps → Google Workspace → Gmail → Spam, Phishing, and Malware → Inbound Gateway, add Barracuda's published IP ranges. This tells Google not to re-filter mail Barracuda has already scanned.
Require TLS from Barracuda: Optional but recommended — configure the inbound gateway to require TLS encryption on mail received from Barracuda's servers.

Outbound Routing Through Barracuda

If you want Barracuda to scan outbound mail from Google Workspace:

In Google Admin → Apps → Google Workspace → Gmail → Routing → SMTP relay service, add Barracuda as an outbound relay
Configure Barracuda's outbound mail policies to scan for data loss, spam, and policy violations

Post-Migration Validation Checklist

Run these checks 24–48 hours after migration:

Inbound external email is flowing and being logged in Barracuda's Message Log
Quarantine is populated with appropriate items (spam, phishing) — check for false positives
Impersonation Protection alerts are firing for actual threats, not legitimate senders
DMARC reports (if enabled) are showing Barracuda's IP ranges as passing SPF/DKIM
End users are receiving quarantine digest notifications
No end-user complaints about missing legitimate email
Account Takeover Protection baseline is being established (7–14 day learning period)
Old vendor's systems are confirmed decommissioned or in parallel-run mode

Common Migration Mistakes to Avoid

Not lowering MX TTL before cutover. If your MX TTL is 86400 (24 hours), propagation after the switch can take up to 24 hours. Some external senders will keep delivering to the old destination for the entire propagation window.

Forgetting to update SPF. Mail routed through Barracuda's MX servers will appear to receiving servers as coming from Barracuda's IP ranges. If your SPF record doesn't include Barracuda, outbound mail — particularly through MX gateway mode — can fail SPF alignment and trigger DMARC failures.

Not configuring the M365 inbound connector. Without an inbound connector, Microsoft applies its own filtering to already-scanned Barracuda mail. This causes false positives and creates a confusing situation where mail passes Barracuda but is blocked by Microsoft.

Going live without a parallel monitoring period. For MX gateway migrations, monitor Barracuda in a logging-only or low-sensitivity mode for 48 hours before setting aggressive enforcement policies. This identifies legitimate senders that need to be whitelisted before enforcement kicks in.

Not documenting the pre-migration state. If something goes wrong after cutover, you need your old MX records, SPF record, and policy configuration to roll back quickly. Document everything before touching DNS.

Frequently Asked Questions

How long does migration to Barracuda Email Protection take? For API-inline M365 migration (the most common scenario), activation takes under 2 hours — domain verification, Graph API connection, policy configuration, and validation. For MX gateway migrations (competing vendor swap or Google Workspace), allow 4–6 hours including DNS propagation monitoring and post-cutover validation.

Will there be any mail delivery downtime during migration? For API-inline M365 migration: zero downtime. Mail continues to flow through M365 servers without interruption. For MX gateway migration: with proper TTL lowering beforehand, mail delivery interruption is typically under 5 minutes during the DNS cutover window.

Can we run Barracuda in parallel with our existing tool during migration? For API-inline: yes — Barracuda can run alongside Microsoft's native filtering during the evaluation period. For MX gateway: you cannot have two MX-gateway tools simultaneously (mail can only route through one MX). One exception: you can deliver mail to both Barracuda and your old vendor using MX priority weights during a brief parallel-run window, but this is complex and rarely necessary.

What happens to existing quarantined messages at our old vendor? Messages already quarantined at your old vendor remain in their quarantine system until that subscription ends. Barracuda's quarantine starts fresh — it will only contain messages quarantined after the Barracuda migration date.

Do we need to migrate historical email logs? Historical message logs are separate from live mail flow and are not part of the migration to Barracuda Email Protection. If you need to retain historical logs, export them from your old vendor before cancelling that subscription. Barracuda archiving (Premium Plus) stores mail going forward from the activation date.

How does Cloudfy help with the migration? Cloudfy manages the full migration — domain verification, Graph API connection or MX cutover, policy configuration, M365 or GWS connector setup, and post-migration monitoring. We carry out the DNS changes with you on the call, monitor the Barracuda console for 48 hours post-cutover, and tune policies based on false positive/negative patterns in your specific email environment.

Ready to migrate to Barracuda Email Protection? Contact Cloudfy Systems — Barracuda Preferred Partner in India. We handle the migration end-to-end with zero-downtime execution and post-migration support.