Barracuda (EGD) to Microsoft 365 and IRONSCALES

IMPORTANT: This guide covers Barracuda Email Gateway Defense (EGD), the cloud-hosted service managed through Barracuda Cloud Control. If your organization runs a physical or virtual Barracuda Email Security Gateway (ESG) appliance, see our ESG migration guide.

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 Barracuda Email Gateway Defense (EGD) 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 Barracuda EGD if desired
• Core migration is DNS changes, connector/rule removal, and EGD portal cleanup

The migration involves four components (color coded throughout):

• DNS DNS changes: Redirecting mail flow from Barracuda EGD to Microsoft 365
• MICROSOFT Exchange Online cleanup: Removing Barracuda connectors, transport rules, and allow lists
• BARRACUDA Barracuda EGD cleanup: Domain unverification, Azure app 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 Audit existing Barracuda configuration

Document what Barracuda installed in your Exchange Online environment:

Connect-ExchangeOnline

# Find all Barracuda connectors
Get-InboundConnector | Where-Object {$_.Name -like "*Barracuda*"} |
  Format-List Name, RestrictDomainsToIPAddresses, SenderIPAddresses, EFSkipLastIP
Get-OutboundConnector | Where-Object {$_.Name -like "*Barracuda*" -or
  $_.SmartHosts -like "*barracuda*"}

# Find Barracuda transport rules (including legacy SCL-1 bypass)
Get-TransportRule | Where-Object {$_.Name -like "*Barracuda*" -or
  $_.Name -like "*bypass spam*" -or $_.Name -like "*SCL*"}

Step 2: BARRACUDA Identify Barracuda EGD IP ranges and smart hosts

Document the specific Barracuda infrastructure in use:

• US IP range: 209.222.82.0/24
• UK IP ranges: 35.176.92.96/27, 18.133.136.128/26
• Germany IP ranges: 35.157.190.224/27, 18.185.115.192/26
• EGD MX hostnames: Customer-specific hashed values (e.g., <hash>a.ess.barracudanetworks.com) — look these up in your EGD Domains page
• Smart hosts: d<ID>.o.ess.barracudanetworks.com (unique per domain)

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

Step 4: MICROSOFT Verify Microsoft 365 DKIM is enabled

Since Barracuda doesn't handle DKIM, your M365 DKIM is likely already active (or was never configured). Confirm it's enabled:

1. Navigate to Microsoft 365 Defender Portal > Email & collaboration > Policies & rules > Threat policies
2. Select DKIM
3. Select your domain and confirm DKIM signing is enabled
4. If not enabled, enable it now and add the two CNAME records to DNS

Step 5: 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 Barracuda EGD 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

Step 2: MICROSOFT Document transport rules and EOP policies requiring modification

List all transport rules and policies that reference Barracuda:

• Barracuda IP addresses in connector SenderIPAddresses
• SCL score modifications (-1) — legacy Barracuda spam bypass rule
• RestrictDomainsToIPAddresses setting on the inbound connector
• Barracuda IPs in the Connection Filter IP Allow List
• Barracuda entries in the Tenant Allow/Block List
• Inline deployment rules (if "Inline with Microsoft" mode was used)

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. RestrictDomainsToIPAddresses value to restore

Week 3: Production Cutover (The Actual Migration)

Day 1 (Friday evening/maintenance window)

Step 1: BARRACUDA Disable tenant lockdown (DO THIS FIRST)

# Check current state
Get-InboundConnector | Where-Object {$_.Name -like "*Barracuda*"} |
  Format-List Name, RestrictDomainsToIPAddresses

# Disable the restriction — mail will still flow through Barracuda via MX
Set-InboundConnector -Identity "Barracuda Inbound Connector" `
  -RestrictDomainsToIPAddresses $false

Step 2: 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: <hash>a.ess.barracudanetworks.com (existing Barracuda EGD)

Step 3: DNS Update SPF record

Modify SPF to include both providers temporarily:

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

Use your region-specific Barracuda SPF include if outside the US (see Week 1, Step 2).

Step 4: 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: <hash>a.ess.barracudanetworks.com (now fallback)

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

Day 2 (Saturday)

Step 5: DNS Remove Barracuda from SPF and remove Barracuda MX

After confirming stable mail flow to Microsoft 365:

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

# Remove Barracuda MX record entirely
# Only Microsoft 365 MX should remain

Step 6: MICROSOFT Remove Barracuda connectors

# Remove connectors (replace Identity values with your connector names)
Remove-InboundConnector -Identity "Barracuda Inbound Connector" -Confirm:$false
Remove-OutboundConnector -Identity "<Barracuda Outbound>" -Confirm:$false

Or via Exchange Admin Center: Mail flow → Connectors → select Barracuda connector(s) → Delete.

Standard EGD deployments have two connectors (1 inbound, 1 outbound). "Inline with Microsoft" deployments may have up to three (2 inbound, 1 outbound).

Step 7: MICROSOFT Remove Barracuda transport rules

# Find Barracuda transport rules
Get-TransportRule | Where-Object {$_.Name -like "*Barracuda*" -or
  $_.Name -like "*bypass spam*" -or $_.Name -like "*SCL*"}

# Remove each rule
Remove-TransportRule -Identity "<rule name>" -Confirm:$false

Common Barracuda transport rules to look for:

• SCL -1 bypass rule — legacy configuration that sets Spam Confidence Level to -1 for Barracuda IPs, bypassing all EOP spam filtering
• Inline deployment rules — up to 3 auto-created rules if "Inline with Microsoft" mode was used. Barracuda provides an offboarding script on their support site to remove these

Step 8: MICROSOFT Clean up EOP allow lists

• Connection Filter IP Allow List: Go to security.microsoft.com → Anti-spam → Connection filter policy. Remove any Barracuda IP ranges
• Tenant Allow/Block List: Check security.microsoft.com/tenantAllowBlockList for Barracuda-related entries
• Enhanced Filtering skip listing: Verify at security.microsoft.com/skiplisting that nothing is orphaned after connector removal

Day 3 (Sunday)

Step 9: BARRACUDA Remove domains from the Barracuda EGD portal

Log into Barracuda Cloud Control → Email Gateway Defense → Domains → remove/unverify each domain.

Step 10: Verify mail flow and monitoring

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. Confirm no mail is still routing through Barracuda

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

Step 1: BARRACUDA Remove Azure Enterprise Applications

Barracuda installs up to six app registrations in Microsoft Entra ID. Remove any that are present from Azure portal → Enterprise Applications:

• Barracuda AzureAD Sync App
• Barracuda Cloud Archiving Service
• Cloud-to-Cloud Backup
• Barracuda Data Inspector
• Barracuda Networks (Impersonation Protection / Incident Response)
• Barracuda Phishline Address Book Connector

Not every tenant will have all six — it depends on which Barracuda products were licensed.

Step 2: BARRACUDA Remove journal rules (if archiving was used)

If Barracuda Cloud Archiving Service was in use, Exchange Online will have a journal rule sending copies to a Barracuda archiving address. Remove from Microsoft Purview compliance portal and also remove any dedicated send connector for archiving traffic.

Step 3: BARRACUDA Remove Barracuda Outlook Add-in

Remove from Microsoft 365 Admin Center → Settings → Integrated Apps. The add-in provides encryption triggers and phishing reporting buttons.

Step 4: DNS DNS cleanup

• Remove any Barracuda domain-verification TXT or CNAME records created during EGD onboarding
• If Barracuda Domain Fraud Protection (DMARC monitoring) was used, update the DMARC record's rua and ruf tags to remove Barracuda mailto addresses
• Restore MX TTL to normal values

Step 5: 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

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 no mail is still routing through Barracuda EGD

Weekly tasks (first month)

• Review IRONSCALES incident reports for detection trends
• Confirm DMARC reports show expected alignment
• Check that Barracuda Azure Enterprise Applications have not reappeared
• Validate EOP policies are complementing IRONSCALES correctly

Rollback Procedures

Within 4 hours of cutover

1. DNS Revert MX record priorities (Barracuda back to lowest number)
2. DNS Restore Barracuda SPF include
3. MICROSOFT Re-enable RestrictDomainsToIPAddresses if it was previously enabled
4. IRONSCALES continues to protect — no action needed on the IRONSCALES side

After 4 hours but within 48 hours

1. Same DNS and connector steps as above
2. If transport rules or allow list entries were already removed, recreate them from your documentation (Week 2, Step 2)
3. If domains were unverified from Barracuda EGD, re-verify them in the EGD portal

Known Issues and Resolutions

RestrictDomainsToIPAddresses bounces

• Symptom: Inbound mail bounces with 550 5.7.51 TenantInboundAttribution; Rejecting
• Cause: Tenant lockdown was not disabled before MX cutover
• Fix: Run Set-InboundConnector -Identity "Barracuda Inbound Connector" -RestrictDomainsToIPAddresses $false

Internal Barracuda routing after MX change

• Symptom: Some external senders using Barracuda still deliver mail through Barracuda's internal network instead of your new MX
• Cause: Domain is still verified in the Barracuda EGD portal
• Fix: Remove/unverify your domain in Barracuda Cloud Control → EGD → Domains

Stale SCL -1 bypass allowing spam

• Symptom: Increased spam after migration despite EOP being active
• Cause: Legacy Barracuda transport rule still setting SCL to -1, bypassing all EOP spam filtering
• Fix: Remove the transport rule via Mail flow → Rules or PowerShell

Orphaned Azure Enterprise Applications

• Symptom: Security audit flags unused app registrations with broad permissions
• Cause: Barracuda Azure apps were not removed during migration
• Fix: Remove from Azure portal → Enterprise Applications (see Week 4, Step 1 for the list of app names)

Support Resources

• IRONSCALES Support: https://ironscales.com/contact-us
• Microsoft 365 Admin Center: https://admin.microsoft.com
• Exchange Online PowerShell: Microsoft Documentation
• Barracuda EGD Offboarding Guide: Barracuda Campus