Barracuda Email Protection with Exchange Server: connectors, smart host and 550 rejections

Barracuda filters mail in front of Exchange in two ways: Email Gateway Defense, the cloud service in the Barracuda Email Protection plans, or a Barracuda Email Security Gateway appliance. When mail stops, the first question is which side refused it. In this post I'll cover the Exchange-side setup both products need, the rejections you'll meet, and how to combine Exchange message tracking with Barracuda's Message Log to prove where a message stopped. Commands apply to Exchange Server SE, 2019 and 2016.

Symptoms#

• External senders get an NDR from a Barracuda host. The wording admins commonly report is 550 permanent failure for one or more recipients (user@contoso.com:blocked); it isn't in the reply list Barracuda publishes for the Email Security Gateway, so treat it as a block verdict and look up the reason in the Message Log. The appliance's documented replies are more specific, for example 554 Service unavailable; client host [IP or hostname] blocked using Barracuda Reputation for a sender on the Barracuda Reputation Block List. Your users see the same NDRs when writing to other Barracuda customers.
• Inbound mail is delayed or missing, and your SMTP receive protocol log shows Exchange answering Barracuda's delivery attempts with 550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain or 452 4.3.1 Insufficient system resources.
• Outbound mail queues on Exchange with 441 4.4.1 Error encountered while communicating with primary target IP address and Failed to connect. Winsock error code: 10060, Win32 error code: 10060.
• Outbound mail leaves Exchange but never shows up in Barracuda's outbound log, or Barracuda refuses it because it doesn't recognize the sending server.

Why it happens#

Both products sit in the same places: your MX record points at Barracuda, which filters mail and delivers it to the mail server configured for each domain, and an Exchange send connector hands outbound internet mail to Barracuda as a smart host. The reply text tells you which side made the decision:

The other classic cause is address drift. Email Gateway Defense delivers from documented IP ranges per region, and both products relay outbound mail only from sending servers they've been told to trust. A firewall that allows outdated ranges, or a NAT change that gives Exchange a new public IP, breaks one direction while the other keeps working.

How to fix it#

1. Let Barracuda deliver to Exchange, and nobody else#

Take the delivery ranges for your Email Gateway Defense region from Barracuda's documentation (for an appliance, use its own address). Allow inbound TCP 25 only from those addresses at the firewall, and give them a dedicated receive connector on every Mailbox server Barracuda delivers to:

New-ReceiveConnector -Name "Inbound from Barracuda" -Server EX01 -TransportRole FrontendTransport -Custom `
    -Bindings 0.0.0.0:25 -RemoteIPRanges 192.0.2.0/24,198.51.100.0/26 -PermissionGroups AnonymousUsers
Set-ReceiveConnector "EX01\Inbound from Barracuda" -ProtocolLoggingLevel Verbose

The ranges are placeholders. Keep the connector anonymous; making it Externally secured would let spoofed internal senders through as if they were authenticated users.

2. Keep domains and recipients in sync#

Every domain you protect in Barracuda must be an accepted domain in Exchange, or Exchange answers 5.7.54:

Get-AcceptedDomain | Format-Table Name, DomainName, DomainType
New-AcceptedDomain -Name "fabrikam.com" -DomainName fabrikam.com -DomainType Authoritative

If Barracuda verifies recipients, the check must see every address Exchange accepts, including aliases, groups and contacts. Verification over SMTP only works when the server being asked rejects unknown addresses. Exchange Mailbox servers don't do that by default, and Microsoft says not to configure the Recipient Filter agent on them (details in the FortiMail guide), so prefer a directory-based check where your Barracuda product offers one.

3. Route outbound mail through Barracuda#

New-SendConnector -Name "Outbound via Barracuda" -Internet -AddressSpaces "*" -DNSRoutingEnabled $false `
    -SmartHosts "outbound.barracuda.example" -SourceTransportServers EX01,EX02
Test-NetConnection outbound.barracuda.example -Port 25

Replace the placeholder with the outbound host name Barracuda provides for your account (Email Gateway Defense) or with the appliance's address, register the public IP your Exchange servers send from as an outbound sender in Barracuda, and disable the old internet send connector. If Test-NetConnection returns TcpTestSucceeded : False from a source server, fix the firewall first; the 441 4.4.1 errors clear on the next retry.

4. TLS, SPF and back pressure#

If Barracuda must use TLS when it delivers to Exchange, Exchange has to present a valid certificate on that connector (see Event ID 12014); to require TLS outbound, add -RequireTLS $true to the send connector. Update SPF, since Barracuda's servers now send your mail to the internet: for Email Gateway Defense, Barracuda's Sender Policy Framework for Outbound Mail page gives the include for your region, such as include:spf.ess.barracudanetworks.com in the US or include:spf.ess.de.barracudanetworks.com in Germany. And if Barracuda shows deliveries to you as deferred while your receive log shows 452 4.3.1, Barracuda is queuing correctly and the fault is Exchange back pressure: see 452 4.3.1 explained and fixed.

5. When your users are the ones blocked#

If your mail to other Barracuda customers bounces this way, check your public IP's reputation and your SPF, DKIM and DMARC records, then ask the recipient's administrator for the Message Log reason; only they can see which check or policy matched.

Verify the fix: prove which side stopped a message#

Start with Exchange message tracking:

Get-TransportService | Get-MessageTrackingLog -Start (Get-Date).AddHours(-4) -Sender sender@fabrikam.com |
    Sort-Object Timestamp | Format-Table Timestamp, EventId, Source, ConnectorId, ClientIp, RecipientStatus -AutoSize
$log = Join-Path $env:ExchangeInstallPath "TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive"
Select-String -Path "$log\*.LOG" -Pattern "Inbound from Barracuda" | Select-Object -Last 20

• A RECEIVE event through "Inbound from Barracuda": Barracuda delivered the message, so any problem is inside Exchange. Follow the later DELIVER or FAIL events.
• No RECEIVE event: find the message in Barracuda's Message Log. If it was blocked or quarantined, the reason there (for example Barracuda Reputation, Sender Policy Framework (SPF), DMARC or Intent Analysis) tells you what to change, in Barracuda or on the sender's side. If Barracuda tried to deliver, the protocol log shows the connection and Exchange's reply.
• Outbound: a SEND event through "Outbound via Barracuda" with a 250 reply means Exchange handed the message over; the rest of the story is in Barracuda's outbound log.

Good looks like this: inbound tests arrive through your Barracuda connector from a documented Barracuda address, outbound tests show SEND with a 250 reply, and Get-Queue shows no Retry queue for the smart host.

Prevent it next time#

• Recheck Barracuda's published ranges whenever you review firewall rules, and update the receive connector at the same time.
• Tell whoever runs Barracuda before you change public IPs, add Exchange servers or add accepted domains.
• Check the Message Log reason before adding an exemption, and keep exemptions narrow.
• Use the vendor-neutral checklist in putting any email security gateway in front of Exchange Server. Journaling to Barracuda's archive is covered in journaling Exchange Server mail to a third-party archive.

References#

• Message Actions: Message Log actions and reasons (Barracuda Campus, Email Gateway Defense)
• Recommended Configuration Settings for Barracuda Networks Cloud Products (Barracuda Campus; lists the Email Gateway Defense SMTP ranges per region)
• Create a Send connector to route outbound mail through a smart host (Microsoft Learn)
• Send connectors in Exchange Server (Microsoft Learn)