Barracuda Email Security Service SPF, DKIM and DMARC setup, step by step

For hosted Barracuda Email Gateway Defense outbound mail, add the SPF include for your configured Barracuda region to the correct envelope-domain policy. Configure branded DKIM in the upstream sending platform, then preserve that signature through the gateway. Barracuda warns that its outbound footer breaks DKIM. Verify the complete route at an independent receiver for intended branded DKIM alignment and dmarc=pass. Regional outbound SPF, Outbound Mail Scanning.

The checks below are for an authorized administrator to run; no customer account, DNS change or test send was performed for this guide.

On this page

• Confirm the hosted outbound route
• Select the correct regional SPF include
• Merge SPF at the evaluated envelope domain
• Enable branded DKIM at the upstream signer
• Preserve signatures through gateway processing
• Keep DMARC policy and reporting safe
• Validate DNS and the complete outbound message
• Troubleshoot by result, not by product name
• Rollback and maintain the route
• Frequently asked questions

Confirm the hosted outbound route

This procedure covers the hosted Email Gateway Defense outbound relay associated with the older Email Security Service name. It does not configure an Email Security Gateway appliance, Domain Fraud Protection, an API-only protection service or inbound authentication filtering.

Write down the actual route: originating mailbox/application → upstream signer → Email Gateway Defense → external receiver. Identify the account, region, outbound smart host, sending domains and mail platforms. A domain's inbound MX records or a successful inbound filter test do not prove outbound routing.

Have three responsibilities assigned: the mail administrator owns upstream signing, the gateway administrator owns routing and transformations, and the DNS administrator owns publication. One person can hold several roles, but the change record must identify who resolves a broken signature after a gateway edit.

Check relay readiness before diagnosing authentication

On Outbound Settings > Sender IP Address Ranges, review Use Shared IP Ranges and the approved upstream sending sources. This is an account-level setting, not a per-domain switch. Barracuda's current documentation says new accounts default to enabled while existing accounts retain their configuration; enabling it alone does not enable outbound relay. Microsoft 365 and Google Workspace are supported by default, while other providers or custom ranges need Support confirmation. Do not treat this switch as a promise of dedicated egress IPs. Current outbound relay controls.

For Microsoft 365, the vendor separately requires Outbound Groups to be enabled by Support, all sending domains to be added, and the correct tenant-specific outbound smart host. Retrieve that hostname from Domains > Outbound Smarthost Configuration; never reuse the sample hostname from a guide. Follow the current routing procedure for your deployment rather than changing connectors merely to troubleshoot SPF. Barracuda Microsoft 365 outbound prerequisites.

Select the correct regional SPF include

Use the region of the configured Barracuda instance, not your office address or recipient location. Barracuda's current table lists:

Choose only the region or regions that actually carry your approved mail. Do not add all six defensively. If the account is migrating regions, coordinate the overlap and retirement window with Support. Official regional SPF table.

Merge SPF at the evaluated envelope domain

SPF checks the SMTP MAIL FROM domain against the IP connecting to the receiver. For outbound gateway delivery, that connection comes through the gateway route. Confirm the envelope identity from the actual routing configuration and later from trusted receiver results; the visible From address alone is insufficient. A root SPF record is not inherited by subdomains. SPF identity rules.

1. Export the existing TXT records at the evaluated owner.
2. Identify the single v=spf1 policy and every legitimate sender it authorizes.
3. Insert the selected regional include before the final all, preserving other senders and the approved qualifier.
4. Evaluate the complete recursive policy before publishing.
5. Save one resulting SPF policy, then check authoritative and recursive DNS.

For illustration only, if the existing policy at the correct owner is v=spf1 include:spf.protection.outlook.com -all and the confirmed route is the US instance, the reviewed merge would be:

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

This is not a universal record. Retaining or retiring direct Microsoft 365 authorization depends on the organization's legitimate routes, including exceptions and rollback. Do not remove it merely because one test uses Barracuda. Do not paste Barracuda's include-plus-all fragment ahead of other mechanisms: processing stops at the matching all.

Multiple SPF policies at one owner cause an error; unrelated TXT records can remain. SPF permits at most ten evaluated DNS-querying terms using include, a, mx, ptr, exists and redirect, including nested processing. The limit is not the number of visible providers or raw DNS packets. Additional MX/address and void-lookup limits apply. ip4, ip6 and all do not consume the term budget. RFC 7208 limits, SPF lookup-limit guide.

Do not solve a limit problem by replacing the maintained regional include with a static IP snapshot or by authorizing all senders. Retire only confirmed unused entries or agree a supported redesign with the domain owner.

Enable branded DKIM at the upstream signer

The hosted outbound scanning documentation says SPF and DKIM inspection are not applied to outbound mail. That is not a statement that the gateway creates a replacement signature. This guide's supported design is to configure the upstream signer and preserve its result, not to invent a Barracuda selector or key-generation menu. Outbound inspection boundary.

For each originating platform, obtain its current account-generated DNS records for the intended branded domain, publish them, and complete that platform's activation step. Keep private keys with the signer. If someone proposes gateway-side signing instead, obtain current documentation for that exact product and licensed route before relying on it.

Microsoft 365 upstream

In Microsoft Defender's Email authentication settings > DKIM, select the custom domain and obtain its two CNAME targets. Publish the actual values, then enable Sign messages for this domain with DKIM signatures and confirm the enabled state. Microsoft assigns dynamic components to newer targets; do not reconstruct them from the tenant name or an old onmicrosoft.com example. Microsoft's current DKIM procedure.

An authorized Exchange Online administrator can read the required values with this command after replacing the example domain:

Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

The read command does not enable signing. Use the supported activation procedure after DNS is correct, and test a message that actually exits through Barracuda.

Google Workspace upstream

An appropriately authorized administrator uses Apps > Google Workspace > Gmail > Authenticate email, selects the domain, and obtains its generated public TXT record. For a new setup, follow Generate New Record, publish the exact owner/value, then select Start authentication. Do not regenerate an already working key just to follow this guide. Google also warns that outbound-gateway modifications can interfere with DKIM. Google Workspace DKIM setup.

DNS owner and record safeguards

For a signer-issued owner SELECTOR._domainkey.mail.example.com, enter SELECTOR._domainkey.mail in parent zone example.com, or SELECTOR._domainkey in a separately delegated zone mail.example.com. Use the real selector, not the word SELECTOR. The actual authoritative zone determines which administrator must publish it.

Match the supplied type: Microsoft uses the issued CNAME targets; Google supplies the public TXT key. Avoid duplicate suffixes and existing-selector conflicts. Keep signing CNAMEs DNS-only and unflattened where supported so the alias remains visible. Do not add TXT beside a CNAME at the same owner or publish a private key. DKIM DNS binding, CNAME verification safeguards.

Preserve signatures through gateway processing

Review Outbound Settings > Tagline/Footer before release. Barracuda explicitly warns that appending its outbound footer causes DKIM verification failure. The setting is global. Treat a footer change as a mail-flow change requiring both security and compliance review. Documented footer behavior.

If a footer is required, coordinate a supported design that inserts the required content before the final DKIM signing operation, or another documented solution agreed by the platform owners. Do not simply disable a mandatory disclaimer, bypass the gateway, or suppress security controls to obtain a green result.

Also inventory other post-signing content transformations in the actual route, such as approved subject/body changes or encryption wrappers. Their effect must be tested, not inferred from the footer result. An inbound “DKIM enabled” setting does not repair a modified outbound signature.

Keep DMARC policy and reporting safe

DMARC passes when at least one passing SPF MAIL FROM or DKIM d= identity aligns with the visible From domain. Relaxed alignment permits the same organizational domain; strict aspf=s or adkim=s requires exact equality for that mechanism. A valid provider signature for an unrelated domain is not aligned branded DKIM. RFC 9989 alignment.

Check _dmarc at the actual From domain and the applicable ancestor policy under RFC 9989. Preserve existing enforcement, subdomain policy, alignment and reporting recipients. An absent exact-domain record is not permission to override inherited protection with a weaker policy.

Only if no applicable policy exists, the domain owner approves monitoring, and the reporting mailbox is ready, a first-policy example for mail.example.com is:

Type: TXT
Full owner: _dmarc.mail.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use _dmarc.mail in parent zone example.com, or _dmarc in delegated zone mail.example.com. Substitute approved domains and mailbox values. Publish one valid DMARC record at the chosen owner, not a second policy beside an existing one. For an apex From domain of example.com, publish at full owner _dmarc.example.com using relative owner _dmarc in zone example.com when the editor appends the suffix.

External report destinations require owner approval for the recipient/data handling and the report receiver's DNS authorization. For policy domain mail.example.com and reporting host reports.example.net, that authorization is TXT v=DMARC1 at mail.example.com._report._dmarc.reports.example.net. Do not turn on forensic reports by default. Aggregate reporting authorization.

Do not use the removed pct tag for a current rollout. Review all legitimate and indirect paths before enforcement. RFC 9989 requires valid DKIM for domains publishing p=reject; a gateway route that passes DMARC only through SPF is not an adequate substitute for preserving DKIM. DMARC interoperability.

Validate DNS and the complete outbound message

Replace uppercase placeholders with your approved owner names and the authoritative server for each zone. These commands inspect public records; they do not change them.

dig +short NS AUTHORITATIVE_ZONE
dig @AUTHORITATIVE_NAMESERVER SPF_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NAMESERVER DKIM_OWNER CNAME +noall +answer
dig DKIM_OWNER TXT +noall +answer
dig _dmarc.FROM_DOMAIN TXT +noall +answer
dig SPF_OWNER TXT +noall +answer

Use a direct authoritative TXT query for a TXT-based signer such as Google. For CNAME-based DKIM, verify the exact target and the public key reachable through it. Query the applicable ancestor DMARC policy where needed. Compare authoritative answers with a recursive resolver after the relevant TTLs; an empty answer, timeout or SERVFAIL needs investigation.

After routing and upstream activation are confirmed, send a harmless new message from the actual platform through the intended gateway to a controlled external mailbox. Save raw source and correlate the gateway message log, timestamp and route. Do not treat a direct internal message or a connector validation email from a different sending domain as the acceptance test.

Use authentication results added by the final receiver or its known trusted inbound gateway. Earlier arbitrary Authentication-Results headers can be forged or refer to a different processing stage. Receiver-result trust boundaries.

The acceptance record should contain:

• Correct visible From, envelope domain, outgoing route and configured region.
• SPF result with any real error resolved or explicitly held for investigation.
• Each DKIM d=/s= pair and dkim=pass for the intended branded signer, aligned under the actual policy.
• dmarc=pass for the visible From domain.
• Expected recipient, reply behavior and any approved footer/encryption behavior.

If SPF is a documented nonaligned pass, aligned DKIM can still satisfy DMARC. If SPF fails or errors, investigate it even when DKIM passes. Conversely, an SPF-carried DMARC pass does not close a broken upstream DKIM requirement. Repeat for each materially different source, domain and transformation policy. Inbox placement remains a separate outcome.

Troubleshoot by result, not by product name

Rollback and maintain the route

Save before-state SPF/DKIM records, signing status, gateway settings and routing references. If the change fails, pause the affected rollout, retain message/log evidence and restore only the approved changed component. Coordinate a footer rollback with its compliance owner. Do not bypass gateway protection or disable unrelated filtering.

Keep old selectors and authorization while active routes or queued messages still require them. Recheck after a regional migration, upstream key rotation, new sending domain, connector change or content-policy update. Review aggregate reports for the relevant route over time; a lack of reports is not proof of error-free mail.