Barracuda Email Protection Setup Guide India — SPF, DKIM, DMARC & Microsoft 365 Configuration

Barracuda Email Protection supports two deployment architectures — API-inline for Microsoft 365 (via Microsoft Graph API, no MX change required) and MX gateway mode for Google Workspace or legacy M365 deployments. Each has a distinct setup process. Getting SPF, DKIM, and DMARC configured correctly determines whether Barracuda can both protect your inbound mail and ensure your outbound mail passes authentication checks at receiving servers.

This guide covers the complete technical configuration for both deployment modes, starting from a fresh Barracuda Email Protection licence activation.

Prerequisites

Before starting any configuration:

Active Barracuda Email Protection licence — provisioned by your Barracuda partner (Cloudfy). Confirm the tier: Essentials, Advanced, or Premium Plus. Impersonation Protection and Account Takeover Protection require Advanced or above.
Access to your Barracuda Email Protection portal — credentials provided at licence provisioning. The portal URL is typically https://ess.barracudanetworks.com or your assigned regional endpoint.
Microsoft 365 Global Admin or Google Workspace Super Admin access — required to authorise the Graph API connection (M365) or configure inbound routing (GWS).
DNS management access — admin access to your domain's DNS zone at your registrar (GoDaddy, Namecheap, BigRock, Cloudflare, or your hosting provider's DNS panel). You will be adding or modifying TXT records and possibly MX records.
Document your current DNS state before making any changes:
- Export or screenshot your current MX records (hostname, priority, TTL)
- Copy your current SPF TXT record in full
- Note any existing DKIM selectors (selector._domainkey.yourdomain.com)
- Note your current DMARC record at _dmarc.yourdomain.com

Part 1 — Domain Setup in Barracuda Email Protection

Step 1 — Add Your Domain

Log in to the Barracuda Email Protection admin portal
Navigate to Domains (or Email Gateway Defense → Domains depending on your portal version)
Click Add Domain
Enter your primary domain: yourcompany.com
Barracuda generates a domain ownership verification TXT record:

Type:  TXT
Name:  yourcompany.com  (or _barracuda-domain-verify.yourcompany.com — use what your portal shows)
Value: barracuda-domain-verify=xxxxxxxxxxxxxxxxxxxx
TTL:   3600

Add this record at your DNS registrar. DNS propagation typically takes 15–60 minutes.

Return to the Barracuda portal and click Verify — the domain status will change to Verified once the TXT record is detected.

If you have multiple domains receiving mail (e.g., yourcompany.in as well as yourcompany.com), add and verify each domain separately.

Step 2 — Add Users / Sync from Mail Platform

Barracuda enforces policies per user. Add users through one of these methods:

For Microsoft 365 (after Graph API connection in Part 2): Barracuda auto-syncs users from your M365 directory. No manual user addition needed.

For Google Workspace: Users can be synced via Google Directory API or added manually via CSV upload.

Manual CSV upload: Download the CSV template from the Barracuda portal (Users → Import Users → Download Template). Fill in email addresses and names, then upload. This is practical for smaller organisations (under 100 users).

Part 2 — Microsoft 365 Deployment (API-Inline via Graph API)

This is the recommended deployment mode for M365. Mail routing is unchanged — Barracuda scans via API with no MX record changes.

Step 3 — Connect Barracuda to Microsoft 365

In the Barracuda portal, navigate to Microsoft 365 → Connect Microsoft 365
Click Connect / Authorise
You are redirected to the Microsoft OAuth consent screen
Log in with your M365 Global Admin account
Review the permissions Barracuda requests:
- Mail.ReadWrite — read and write access to mailboxes for scanning and automated remediation
- Mail.Send — for sending automated threat notifications
- MailboxSettings.Read — to read mailbox configurations
- User.Read.All — to enumerate all users in the tenant
- SecurityEvents.ReadWrite.All — for Account Takeover Protection (Advanced and above)
Click Accept
Return to the Barracuda portal — connection status should show Connected

Barracuda immediately begins scanning incoming mail for your M365 tenant via the Graph API. There is no mail flow disruption.

Step 4 — Configure the M365 Inbound Connector (Best Practice)

Even in API-inline mode, configuring an M365 inbound connector ensures mail scanned and released by Barracuda is not re-filtered by Microsoft Defender for Office 365.

In Microsoft 365 Admin Centre → Exchange Admin Centre → Mail Flow → Connectors:

Create a new Inbound connector
Connection from: Partner organisation
Name: Barracuda Email Protection
Identify the partner by: Sender's IP address ranges — add Barracuda's published IP ranges (available in the Barracuda Email Gateway Defense documentation under your regional datacenter assignment)
Enable Require TLS for the connection
Under Trust, enable Bypass Microsoft 365 spam filtering for email from this connector

This prevents double-filtering and reduces false positives from Microsoft re-evaluating already-scanned messages.

Part 3 — MX Gateway Deployment (Google Workspace and Legacy M365)

Use this mode if you are deploying on Google Workspace or if your M365 deployment requires an MX-based scanning path.

Step 5 — Get Your Barracuda MX Records

In the Barracuda Email Gateway Defense portal:

Navigate to Domains → your domain
Click on the domain to expand the configuration
Find the MX Records section — Barracuda provides your assigned cluster MX hostnames:

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

The exact hostnames depend on your regional datacenter assignment and are specific to your Barracuda account. Use the values shown in your portal, not this example.

Step 6 — Update MX Records in DNS

At your DNS registrar or DNS management panel:

Lower the TTL on existing MX records to 300 seconds (5 minutes) at least 30 minutes before making the switch — this speeds up propagation after you change the records
Delete your existing MX records
Add the Barracuda MX records from Step 5
Set TTL to 3600 on the new Barracuda MX records

After propagation (5–30 minutes with lowered TTL), new inbound mail for your domain will route through Barracuda's scanning infrastructure before delivery to your mail server.

Step 7 — Configure Google Workspace Inbound Gateway

After updating MX records, tell Google Workspace that Barracuda's servers are trusted inbound sources:

In Google Admin Console → Apps → Google Workspace → Gmail → Spam, Phishing, and Malware
Scroll to Inbound Gateway
Enable inbound gateway and add Barracuda's published IP ranges
Enable Automatically detect and reject mail from this IP that is not signed with DKIM — optional, tighten after DKIM is configured
Check Require TLS for connections from the email gateways listed above

Without this configuration, Google Workspace may treat Barracuda-scanned mail as unauthenticated and apply its own spam filters on top of Barracuda's — causing false positives and confusing quarantine decisions.

Step 8 — Configure Delivery Route (Barracuda → Your Mail Server)

In the Barracuda Email Gateway Defense portal, configure where Barracuda delivers scanned mail:

Navigate to Domains → your domain → Delivery
Set Mail Server to your mail server hostname or IP:
- For M365: yourtenantname.mail.protection.outlook.com
- For Google Workspace: aspmx.l.google.com (or your MX-based route)
Set Port: 25
Enable TLS — require TLS for delivery

Part 4 — SPF Configuration

SPF (Sender Policy Framework) authorises which IP addresses can send mail on behalf of your domain. When Barracuda routes your outbound mail, Barracuda's sending IPs must be authorised in your SPF record.

Step 9 — Update Your SPF Record

Locate your existing SPF record — query it:

nslookup -type=TXT yourdomain.com

or use any online SPF lookup tool. Your existing record likely looks something like:

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

Add Barracuda's SPF include to your existing record:

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

Rules for editing SPF:

There must be exactly one SPF TXT record per domain. Do not add a second SPF record — combine everything into one record.
Place include:spf.barracudanetworks.com before ~all or -all at the end.
If you are removing a previous vendor, delete their include statement.
Limit: SPF records must not exceed 10 DNS lookups. Each include: counts as one lookup. If you are already near the limit, use an SPF flattening service.

For Google Workspace with Barracuda as outbound gateway:

v=spf1 include:spf.barracudanetworks.com include:_spf.google.com ~all

Publish the updated TXT record in your DNS at the root of your domain (@ or yourdomain.com). SPF changes propagate within minutes to hours.

Part 5 — DKIM Configuration

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound messages, allowing receiving servers to verify that mail genuinely came from your domain and was not altered in transit.

Step 10 — Generate a DKIM Key Pair in Barracuda

If Barracuda is handling your outbound mail (MX gateway mode with outbound routing):

In the Barracuda Email Gateway Defense portal, navigate to Domains → your domain → DKIM Signing
Click Generate New Key
Select 2048-bit RSA key length (recommended; more secure than 1024-bit)
Barracuda generates a key pair and shows you the public key in DNS record format:

Type:  TXT
Name:  barracuda._domainkey.yourdomain.com
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ...
TTL:   3600

The selector name (barracuda in this example) is assigned by Barracuda — use the exact name shown in your portal.

Publish this TXT record in your DNS.
Return to the Barracuda portal and click Verify DKIM — Barracuda confirms the DNS record is live.
Enable DKIM Signing for outbound mail.

DKIM for API-Inline M365 Deployments

In API-inline mode, mail flows through Microsoft's servers, and DKIM signing is handled by Microsoft Exchange Online — not Barracuda. Configure DKIM signing in Microsoft 365 Defender → Email & Collaboration → Policies & Rules → Email Authentication → DKIM.

Barracuda validates DKIM signatures on inbound mail (checking that incoming messages from other domains are correctly signed) — this is automatic and requires no configuration.

DKIM for Google Workspace

Google Workspace handles DKIM signing for outbound GWS mail natively. Configure this in Google Admin Console → Apps → Google Workspace → Gmail → Authenticate email → Generate new record. Publish the DKIM TXT record Google provides.

Part 6 — DMARC Configuration

DMARC (Domain-based Message Authentication, Reporting, and Conformance) instructs receiving mail servers what to do with messages that fail SPF or DKIM alignment from your domain. It also enables you to receive reports about who is sending mail using your domain name.

Step 11 — Publish a DMARC Record

DMARC is a TXT record published at _dmarc.yourdomain.com:

Step 1: Start in monitoring mode (p=none)

Type:  TXT
Name:  _dmarc.yourdomain.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; sp=none; adkim=r; aspf=r
TTL:   3600

p=none means receiving servers take no action on DMARC failures — they just send you reports. This is the safe starting point. Run in p=none for 4–6 weeks and analyse the aggregate reports (rua) to confirm all legitimate sending sources are passing SPF and DKIM.

Step 2: Move to quarantine After confirming all legitimate mail passes (via DMARC reports):

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com

pct=25 applies the quarantine policy to 25% of failing messages first — a gradual rollout.

Step 3: Full enforcement

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

p=reject instructs receiving servers to reject mail from your domain that fails DMARC alignment. This is the highest protection level — it stops domain spoofing completely. Do not jump directly to p=reject without monitoring first.

DMARC Alignment with Barracuda

For DMARC to pass, either SPF or DKIM must align with your domain:

SPF alignment: The Return-Path (envelope sender) domain must match your domain (yourdomain.com). In MX gateway mode, ensure Barracuda is configured to send outbound mail using your domain as the return path — not Barracuda's domain.
DKIM alignment: The d= value in the DKIM signature must match your domain. If both M365/GWS DKIM and Barracuda DKIM are configured, at least one must align.

If your DMARC reports show failures from your own sending sources, check the SPF and DKIM configuration before tightening the DMARC policy.

Part 7 — Inbound Policy Configuration

Step 12 — Configure Core Inbound Policies

In the Barracuda Email Protection portal, configure these policies before considering setup complete:

Anti-Spam and Anti-Phishing:

Spam scoring: Enable and set to Medium sensitivity initially
Phishing protection: Enable — block phishing, allow end-user release of spam
Malware: Enable — block and quarantine; do not allow end-user release of malware

Impersonation Protection (Advanced and above):

Navigate to Impersonation Protection → Protected Identities
Add your CEO, CFO, Finance Director, and any other executives who are commonly impersonated in BEC attacks
Add your most-used vendor or partner domains (the ones you regularly receive invoices from)
Sensitivity: Start at Medium; review alerts before tightening

Account Takeover Protection (Advanced and above):

Enable Login Monitoring — Barracuda baselines each user's normal login geography and device patterns over 7–14 days
Enable Inbox Rules Monitoring — alerts when new inbox rules are created in a user's mailbox (common attacker behaviour post-compromise)
Configure alert recipients (your IT admin or security team)

Sender Authentication Enforcement:

Enable SPF, DKIM, and DMARC enforcement for inbound mail
Set handling for SPF fail: Quarantine or block (not just tag)
Set handling for DMARC reject policy: Block

Part 8 — Post-Setup Validation

Step 13 — Validate the Full Configuration

Run these checks 24 hours after completing setup:

SPF check: Use nslookup -type=TXT yourdomain.com or an online SPF checker to confirm your SPF record includes include:spf.barracudanetworks.com and that the total DNS lookup count is under 10.

DKIM check: Use an online DKIM checker (selector._domainkey.yourdomain.com) to confirm the public key is published and matches what Barracuda shows in its portal.

DMARC check: Query _dmarc.yourdomain.com — confirm the record is present and the policy matches your intended setting.

Send a test message: Send a message from an external email address (Gmail personal account) to a user at your domain. Check the Barracuda Message Log to confirm the message was received, scanned, and delivered. Check the message headers in the delivered email — you should see Barracuda's scanning headers.

Outbound test: Send a message from your domain to an external address. Use the mail-tester.com service to score the outbound message — confirm SPF pass, DKIM pass, and DMARC pass in the report.

DMARC reports: After 48 hours, check the rua email address you set in the DMARC record — you should begin receiving aggregate XML reports from major receiving domains (Google, Microsoft, Yahoo). These reports confirm which IP addresses are sending mail from your domain and whether SPF and DKIM are passing.

Frequently Asked Questions

Does Barracuda Email Protection API-inline mode require MX record changes? No. API-inline mode connects to Microsoft 365 via the Microsoft Graph API — mail routing is unchanged. No MX records, no SPF changes for inbound routing. SPF changes are only needed if you are routing outbound mail through Barracuda's servers.

Can Barracuda Email Protection work with both M365 and Google Workspace domains in the same account? Yes. You can add multiple domains to a single Barracuda Email Protection account. M365 domains can use API-inline while GWS domains use MX gateway — both managed from the same Barracuda admin console.

What is the difference between ~all and -all in an SPF record? ~all (softfail) means mail from unauthorised sources should be accepted but tagged. -all (hardfail) means mail from unauthorised sources should be rejected. Most organisations use ~all during SPF configuration and only move to -all after confirming all legitimate sending sources are authorised. DMARC with p=reject effectively enforces the same outcome as -all at the domain authentication level.

How long does it take for DMARC aggregate reports to arrive after publishing a DMARC record? The first reports typically arrive within 24–48 hours. Major senders (Google, Microsoft, Yahoo) send daily aggregate reports. Not all receiving servers send DMARC reports — compliance varies.

Does Barracuda generate DKIM signatures on API-inline scanned mail? No. In API-inline mode, mail flows through Microsoft Exchange Online, which handles DKIM signing. Barracuda validates inbound DKIM signatures but does not re-sign mail. Barracuda DKIM signing applies only in MX gateway (outbound relay) mode.

My SPF record is already at the 10 DNS lookup limit. How do I add Barracuda? Use SPF record flattening — a process that resolves all include: statements to their underlying IP addresses and replaces them with direct ip4: entries, eliminating the DNS lookup chain. Several online tools and vendors provide SPF flattening. Some domains use services like AutoSPF or dmarcian to keep flattened SPF records current as vendor IP ranges change.

Can we run the setup ourselves or do we need Cloudfy to do it? The API-inline M365 setup can be completed in under 2 hours by an M365 admin following this guide. The MX gateway setup is more involved — MX cutover timing, M365 inbound connector configuration, and DMARC alignment validation require care. Cloudfy typically handles the full setup for clients and monitors the first 48 hours post-cutover to catch any mail flow issues.

Need help configuring Barracuda Email Protection for your domain? Contact Cloudfy Systems — Barracuda Preferred Partner in India. We handle API connection, SPF/DKIM/DMARC setup, policy configuration and post-setup validation.