Quorum Tech - Notes from the field

Office 365 Exchange Connector / Symantec Email

March 3, 2016

Summary

Occurs when combining the Office 365 Exchange connector with existing or new Symantec Email Security.cloud (Symantec.cloud) implementations.

When creating the Inbound Partner Connector via Exchange EAC for Symantec.cloud “Reject Email messages if they aren’t sent over TLS” is checked by default. TLS Encryption is enabled by default

Exchange Online Connector

Office 365 Exchange Connector and TLS option

Recently TLS encryption was made available to Email Security.cloud customers.

http://www.symantec.com/connect/blogs/self-serve-tls-encryption-now-available-email-securitycloud-customers

For existing and new Security cloud customers TLS Encryption is disabled by default in the Symantec Email Security.cloud management portal.

 

Symptoms

1)              Some emails are not received by Exchange Online mailboxes.

2)              Symantec.cloud Track and Trace Email function reports “454 4.7.0 Failed to establish appropriate TLS channel: Access Denied.” for emails in question.

Symantec.cloud trace

Symantec trace showing the 454 4.7.0 Access Denied Error

 

Solution

Enable TLS for all mail receiving Office 365 domains in Symantec.cloud Management Console.

http://www.symantec.com/connect/videos/self-serve-tls-enforcing-tls-encryption-between-you-and-email-security-service

 

Workaround

Reconfigure the Inbound Connector without TLS / TLS opportunistic and lock it down to the Symantec.cloud public ranges.

The following Exchange Online Powershell command came in handy when we had to recreate the Inbound Partner as Office 365 will only let you put in /24 -/32 subnets.

http://www.mowasay.com/2015/08/office365-creating-an-inbound-connector-for-office-365-to-symantec-cloud-ip-ranges-cidr/

 

Good Luck!

Quorum Team

Share this post
Back