Example Error Message

Delivery has failed to these recipients or groups:

zixvpmgateway@zixvpm.domain.com

A prolem occurred while delivering this message to this email address. Try sending this message again. If the problem continues, please contact your help desk.

The following organization rejected your message: xxxxxx.ess.barracudanetworks.com. 

Overview 

This post is intended to provide a high-level overview of the routing and delivery between two companies who utilize a ZixGateway and the Barracuda Email Security Service to encrypt and scan their messages. In addition, this document will cover a common delivery issue between these same companies. [more]

Prerequisites

  • Both companies have a ZixGateway Email Encryption virtual or physical appliance
  • Both companies use Barracuda Email Security Service for antispam/antimalware scanning
  • The sending company has configured the Barracuda Email Security Service to scan all outbound email

Procedure

When a ZixGateway customer sends an email to another ZixGateway customer, the sending appliance is aware that both customers use Zix encryption and will automatically encrypt the email before delivering it. This is seamless to end users on both sides and makes email delivery between the two automatically secure.

As an email is encrypted, the sending ZixGateway wraps the entire email up as an encrypted attachment and redirects the message to zixvpmgateway@zixvpm.recipientdomain.com. Looking at this email after it has been encryption will only reveal the sender’s email address, the subject line of the message, and the modified recipient’s email address.

At this point, any mail gateway will look up MX records for zixvpm.recipientdomain.com and deliver it normally until the message reaches the destination ZixGateway. This recipient gateway will unwrap the encrypted attachment (i.e. decrypt the email), and deliver it as normal to the original recipient.

 

Because of this, a significant number of ZixGateway and Barracuda customers may set up two sets of MX records like below:
 
;; ANSWER SELECTION:
fabrikam.com. 3600 IN MX 10 d12345a.ess.barracudanetworks.com.
fabrikam.com. 3600 IN MX 20 d12345b.ess.barracudanetworks.com.
 
;; ANSWER SELECTION:
zixvpm.fabrikam.com. 3600 IN MX 20 Zixgateway.fabrikam.com.
 
This method is acceptable and fairly common from a ZixGateway point of view. From the ZixGateway, the appliance is listening to all IP addresses for incoming email, but if the incoming email is not encrypted, it will be silently dropped. This protects the ZixGateway from being overrun by spam and malicious attempts. Plus, there's no reason to send the encrypted email through a spam filter - Barracuda is unable to see inside the encrypted attachment.
 
The Barracuda Email Security Service utilizes a feature to improve the efficiency of mail routing inside their network. For mail sent between two BESS customers, instead of performing an MX record lookup for every email that passes through their system, they perform an internal lookup inside their customer database and deliver it according to the settings there. In addition, if a subdomain doesn't exist under the account, BESS will look up the root domain for delivery settings.
 
This means that in the case of the example above, mail will bypass the ZixGateway entirely, because BESS will intercept the message and deliver it to the fabrikam.com domain setting. At this point, the internal mail server will reject the message as undeliverable.
 
 
 

 
Workaround
 
The solution to this problem is a simple workaround for the recipient domain. Inside Barracuda, set up a new domain for the zixvpm.domain.com subdomain that delivers to the ZixGateway and add the zixvpmgateway@zixvpm.domain.com user to that subdomain.
 
However if outbound email routing does not flow through Barracuda and SPF is enabled on the email domain, you will need to add the Zix hostnames to the SPF exempt list.
 
Despite Barracuda not being able to scan the encrypted email, this ensures that mail delivered between BESS customers reaches its intended destination while not altering mail flow for all other email traffic.