Barracuda SPF & DKIM Configuration — A DMARCReport Guide

By DMARCReport — practical, vendor-specific guidance to make your email authentication reliable and DMARC-ready.

Getting SPF and DKIM right for traffic that routes through a Barracuda appliance is one of the quickest wins you can make to reduce spoofing, stop spam that appears to come from your domain, and help your DMARC policy work as intended. Below we walk through why each protocol matters for Barracuda deployments, the exact SPF values Barracuda expects by region, step-by-step DNS changes, how DKIM fits into the picture (and an important caveat about Barracuda’s handling of signatures), plus test and troubleshooting tips to verify success.

Why SPF and DKIM matter for Barracuda (and your DMARC posture)

SPF (Sender Policy Framework) tells receivers which IPs and services are authorized to send mail for your domain. DKIM (DomainKeys Identified Mail) cryptographically signs messages so recipient systems can check content integrity and the sending domain. When properly configured, these two protocols allow your DMARC policy to validate mail and either pass or take action (none/quarantine/reject) based on alignment between the headers and the authenticated sources.

For organizations using Barracuda’s email gateway services, the right SPF include and DKIM configuration are essential because Barracuda will often relay or process outbound mail on behalf of your domain. If the DNS records don’t include Barracuda’s sending infrastructure, SPF checks at destination mail servers will fail, and DMARC alignment will break. Likewise, ensuring your mail system signs outgoing mail with DKIM (and that signatures survive any processing) gives you a stronger authentication signal for DMARC enforcement.

The SPF record values Barracuda expects

Barracuda publishes specific SPF include mechanisms depending on the region of your Barracuda instance. Use the include value that matches the region where your Barracuda service is hosted:

• Australia: v=spf1 include:spf.ess.au.barracudanetworks.com ~all
• Canada: v=spf1 include:spf.ess.ca.barracudanetworks.com ~all
• Germany: v=spf1 include:spf.ess.de.barracudanetworks.com ~all
• India: v=spf1 include:spf.ess.in.barracudanetworks.com ~all
• United Kingdom: v=spf1 include:spf.ess.uk.barracudanetworks.com ~all
• United States: v=spf1 include:spf.ess.barracudanetworks.com ~all.
  

If you already publish an SPF record, you should merge Barracuda’s include into that single record rather than creating a second SPF TXT — DNS lookup rules require one SPF record per domain or you’ll get a permanent error. For example, a combined record can look like:

v=spf1 ip4:18.57.156.221 include:spf.ess.barracudanetworks.com include:thirdpartyservice.com ~all

This approach keeps all authorized senders in one place and avoids SPF evaluation problems. 

Step-by-step: publishing (or updating) your SPF TXT record

1. Sign in to your DNS provider or control panel for the domain you want to authenticate.
2. Create (or edit) a TXT record for the zone; the record name is typically @ (or your root domain).
3. Paste the SPF string that includes your Barracuda include (use the region-appropriate include shown above) and any other authorized senders you use.
4. Save the DNS change.
5. Allow DNS propagation — it can take time; plan on up to 72 hours for changes to be visible everywhere.
   

Important reminders:

• Only one SPF TXT record must exist per domain. Multiple separate SPF records will cause a PermError during SPF evaluation.
• Consolidate all IPs, email service provider (ESP) includes, and third-party services into a single record to avoid lookup issues and to remain inside SPF lookup limits.
  

DKIM and Barracuda — the practical reality

A key point: Barracuda does not automatically sign outgoing mail with DKIM on your behalf. If you need DKIM signing for messages that traverse Barracuda, you must enable and manage DKIM on the origin mail server or your sending service (for example, Microsoft 365, Google Workspace, SendGrid, or your on-premises Exchange). Barracuda primarily handles scanning and policy enforcement, not DKIM signing of origin traffic. 

Because Barracuda may add footers or make other benign modifications to mail during processing, enabling DKIM at the origin can sometimes surface signature validation issues downstream — for instance, if Barracuda alters a header or injects content that breaks the canonicalization used by DKIM. If you encounter DKIM failures after configuring signatures at the origin, open a support ticket with Barracuda; their team can advise on how their processing interacts with outbound signatures and whether configuration changes (or disabling certain message footers) are required. 

Practical DKIM setup checklist

• Generate DKIM keys on your sending server or within your ESP. Keep the private key on the signing server; publish the public key as a DNS TXT under the selector you choose.
• Ensure the selector and domain in the DKIM-Signature header match the DNS TXT you publish.
• Send test messages to external accounts and inspect headers to confirm the DKIM-Signature is present and dkim=pass at the recipient.
• If Barracuda or other intermediaries are in the path, test whether signatures survive processing. If they don’t, work with Barracuda support to identify the modification and a mitigation path (for instance, moving signing to a later hop or changing footer behavior).
  

Testing and validation (how to be confident)

After publishing SPF and DKIM:

• Use public checkers to validate your SPF TXT and DKIM DNS entries (there are many free tools that will simulate lookups and parse records).
• Send test messages to accounts on Gmail, Outlook.com, and other large providers — examine the message headers and look for spf=pass and dkim=pass results and for DMARC alignment status.
• If you use a DMARC report analyzer (or a service like DMARCReport), ingest aggregate reports and look for sending sources with failures so you can iterate on the SPF/DKIM lists.
  

Common pitfalls and how to avoid them

• Multiple SPF TXT records: Never split your authorized senders into separate TXT records. Consolidate into one record to avoid PermError results.
• Forgotten third-party senders: If a marketing platform, transactional provider, or corporate cloud service sends mail for your domain, be sure to include their mechanism in the same SPF record or ensure they sign via DKIM and align with your domain.
• DKIM signing placed too early: If you sign at an origin that’s later modified by a gateway, DKIM may break. Test message paths and coordinate with gateway vendors to prevent this.
  

Final notes from DMARCReport

Configuring SPF correctly for Barracuda’s services is straightforward when you use the right include string for your region and consolidate all authorized senders into a single SPF TXT. DKIM requires action at your sending platform — Barracuda won’t sign on your behalf — and you should validate that signatures survive any processing Barracuda performs. Once SPF and DKIM are passed and aligned, your DMARC policy can function as intended and you’ll see fewer spoofing attempts and more predictable inbox placement.

If you’d like, DMARCReport can analyze your current DNS and DMARC aggregate reports and give you a prioritized list of next steps (which includes exact SPF merges and DKIM selector checks based on your real sending sources). For guidance tailored to your domain and sending flow, share your DMARC aggregate reports or the domain name and we’ll walk you through the concrete changes.