Category Archives: 17441

SMTP Firewall Requirements for Exchange Online

Most of my Office 365 engagements are hybrid projects connecting Office 365 with Exchange on-premises, and most are with larger companies concerned with securing the hybrid deployment.

Exchange Online Protection servers send SMTP emails using a TLS connection usually to the hybrid or Edge Transport server to enable mail flow between cloud and on-prem users. Microsoft does not support any sort of SMTP gateway or appliance between EOP and the Edge or hybrid server. For this reason, customers normally have to open TCP port 25 on the firewall to the hybrid server from the Exchange Online Protection servers.

Companies can secure this SMTP traffic by configuring the perimeter firewall to allow inbound TCP 25 traffic only from Exchange Online Protection servers to the hybrid or Edge servers.

I’ve seen a number of articles that list the public IP addresses used by EOP to send SMTP emails to on-prem customers, but the one true list is maintained in the article, Exchange Online Protection IP Addresses. Currently, this article lists seven IPv4 blocks and one IPv6 block for SMTP delivery to on-prem:

  • 2a01:111:f400:7c00::/54
Microsoft tries hard to not make changes to this list, but if they do they will update the article. It’s important for firewall admins to know that EOP does not use URLs for root domain routing (also known as Top-Level Domains, or TLDs). You must use the IP addresses listed in the article above.

Up until April 2014, Microsoft used many other IP addresses to send emails from Office 365 tenants to on-prem customers. This is because they maintain another set of IP addresses for something called the High Risk Delivery Pool, which is used to protect the production Exchange Online namespace from “spammy” senders. EOP no longer uses the High-Risk Delivery Pool when sending emails between the customer’s tenant and their on-prem servers.

It’s nice to know that we now have a single source to point to when configuring firewalls for Office 365.

Troubleshooting TLS SMTP Connections to Exchange Online Protection

By default Office 365 uses Transport Layer Security (TLS) to send encrypted SMTP emails between Exchange Online and Exchange on-prem. This provides end-to-end encryption of emails between your on-prem Exchange Hybrid Server and Exchange Online Protection (EOP), just like they were the same organization.

TLS utilizes x.509 (SSL) certificates to encrypt the email in transport. Exchange Online and Exchange 2013’s implementation of TLS differs from previous implementations of TLS in several important ways:
  • The certificates used for TLS must be issued by a trusted third-party CA (Digicert, Godaddy, Verisign, etc.)
  • The CRL for the certification authority must be available. If Exchange or O365 can’t read the CRL it will not trust the certificate.
  • The FQDN that the Receive Connector provides in response to EHLO must match the subject name or a subject alternative name on the certificate. SAN certificates and wildcard certificates are both valid for TLS use. If you use a wildcard cert the FQDN used on the connector can be any name that is valid for the wildcard cert’s domain.
  • In previous versions of TLS any certificate could be used to encrypt SMTP traffic, even expired or self-signed certificates. This is not the case with Office 365 and Exchange 2013.
As previously mentioned, TLS is required by default for SMTP communication between Hybrid servers and Exchange Online Protection (EOP). When you run the Hybrid Configuration Wizard it will configure forced TLS for all Send and Receive Connectors. Note that this configuration is updated whenever you run the HCW, so if you reconfigure the connectors for opportunistic TLS or turn it off completely, the HCW will reconfigure them to use forced TLS again.

The following options are available for TLS encryption in Office 365:

  • Force TLS – Email sent across this connector must use TLS. If TLS is unavailable messages will queue until they are delivered or expired.
  • Opportunistic TLS – The connector tries to setup a TLS connection using the STARTTLS verb. If a TLS connection cannot be made the connector falls back to regular ESMTP or SMTP. This is functionally equivalent to turning TLS off.
Normally the use of TLS is configured on Receive or Inbound Connector. You do this to control how email is accepted by your domain and it can be easily configured using the Exchange Admin Console. 
Office 365’s Inbound Connector from Hybrid Server
Send Connectors can also be configured to require TLS. This is used to enforce that email is sent by this connector must only use TLS, and is configured in the shell using the RequireTLS property:
Outbound Connector TLS Settings to Office 365
Using this configuration if the corresponding Receive Connector does not offer or require TLS, messages will queue on the sending server until they are finally delivered or expire.

You can easily tell if a receiving SMTP server is configured to use TLS using Telnet. Install the Telnet Client feature, Telnet to the server using TCP port 25, and look for the STARTTLS verb after issuing the EHLO command. For example:

Telnet servername 25
If you see that the STARTTLS verb is missing, the server is not offering TLS. If your Send Connector is configured to require TLS, the messages will queue on the sending server with the error,

451 4.4.0 Primary target IP address responded with: “451 5.7.3 STARTTLS is required to send mail.”

There are several reasons that the STARTTLS verb might be missing:
  • The receiving server is not configured to Force TLS or use Opportunistic TLS.
  • The sending server’s IP is on an SMTP block list (aka SMTP blacklist or SMTP blocklist). Office 365 will not attempt to send TLS traffic with a server it can’t trust.
  • The receiving server is configured to only respond to SMTP (not ESMTP) commands. TLS is part of the ESMTP protocol.
  • Your firewall is doing some form of email inspection and is filtering “unsafe” verbs from the SMTP conversation. Some examples of firewalls that do this are:
Office 365 uses internal and external SMTP blocklists to protect the network. If the sending server is on one of these black lists the EOP servers will not offer TLS. You can test this by sending a non-TLS email to EOP using Telnet. See Brian Reid’s article, “Cannot Send Emails to Office 365 or Exchange Online Protection Using TLS“. The response from the EOP server will tell you which block list you’re on and how to request removal.

If the receiving server requires TLS, but the sending server is not configured to use a TLS certificate messages will queue on the sending server with the error,

451 4.4.0 Primary target IP address responded with: “451 5.7.3 Must issue a STARTTLS command first.”

The fix here is to configure the Send Connector to use TLS and a valid certificate using the Enable-ExchangeCertificate cmdlet, such as:

Enable-ExchangeCertificate -Thumbprint 5DC5902752816FD2FC51D5564C363F68D8F7FFC4 -Services SMTP

Make sure to use Get-ExchangeCertificate to get the correct certificate’s thumbprint for the command above.

Hopefully this information will help you understand TLS and will assist you with troubleshooting.

Exchange 2013 Client Access Coexistence with Exchange 2007

I do a lot of coexistence migrations for customers. The following guide explains how Exchange 2013 Client Access coexists with Exchange 2007 during a long-term migration.

Greg Taylor had a fabulous session on Microsoft Exchange Server 2013 Client Access Server Role at TechEd 2013. I highly encourage you to watch it. For reference I’ve noted the time in the presentation that relates to each Exchange protocol below.  So, off we go…

The Key to Enlightenment

All client access services should point to the Exchange 2013 Client Access Server role (CAS2013). CAS2013 redirects to
for OWA and proxies everything else. Specific
URLS are used if set, otherwise CAS2013 proxies.


Internal and external DNS must be configured to point to
Exchange 2013 CAS.  MBX2013 delivers Exchange 2007
XML for the correct AD site.

Client à CAS2013 (proxyà MBX2013

Outlook Anywhere (OA) (20:00)

CAS 2007 must be enabled for Outlook Anywhere. If OA2007 authentication is
already set to NTLM you’re set, but if you’re using Basic authentication:

CAS2007 – OA Client authentication: Basic / OA IIS authentication: Must include NTLM

  • Get-OutlookAnywhere
    -Server <server> | Set-OutlookAnywhere
    -ExternalClientAuthenticationMethod Basic -InternalClientAuthenticationMethod
    Basic -IISAuthenticationMethods NTLM
CAS2013 – OA Client authentication: Basic / OA IIS authentication: Basic

  • Get-OutlookAnywhere
    -Server <server> | Set-OutlookAnywhere
    -ExternalClientAuthenticationMethod Basic -InternalClientAuthenticationMethod
    Basic -IISAuthenticationMethods Basic

Client à CAS2013 (proxy)à CAS2007 à MBX2007

Outlook Web App (OWA) (25:50)

Set CAS 2007 ExternalUrl to  Make sure that resolves to CAS2007 in internal and external DNS.

Client à CAS2013 (redirect)à CAS2007 (legacy.contoso.comà MBX2007

ActiveSync (33:15)

Convoluted path caused by limitations in CAS2007 code, but it works.

Client à CAS2013 (proxy)à MBX2013 (proxy)à CAS2007à MBX2007

Exchange Web Services (EWS) (36:15)

EWS settings always come from autodiscover.  If a mailbox is on 2007 has to get EWS from CAS2007. Set the CAS2007 InternalURL and ExternalURL to use

Client à CAS2007 (à MBX2007

How to Share Free/Busy Information Without Using Federated Delegation

If you have a two-way forest trust in place between two organizations, such as during a merger, you can share calendar free/busy information between two Exchange organizations without having to configure federated delegation.

Federated delegation is usually the way to go since it offers more than just free/busy sharing.  With federation using the Microsoft Federated Gateway Server service you can share limited details between business partners.  In addition to free/busy information you can share meeting subjects, attendee, and location information.
Federated delegation works by brokering a trust between two different SMTP domains. The following diagram shows how this brokered trust works between and
Federated delegation between and
To see more information about federated delegation see my articles, How to Configure Exchange 2010 SP1 Federation and Exchange Federated Free/Busy doesn’t work in one direction.
Because federated delegation relies on different SMTP domains, it won’t work during a merger/migration where both companies share the same SMTP domain (  The answer is to use the Add-AvailabilityAddressSpace cmdlet in both orgs.  
Be aware that the TechNet documentation for the Add-AvailabilityAddressSpace cmdlet is inaccurate/incomplete. It says this cmdlet is only supported on Exchange 2010 SP2 and Exchange 2010 SP3 when it’s actually supported on all versions of Exchange 2007 through Exchange 2013.  It also misses some crucial steps, which I’ve added below.
Here’s how to configure simple free/busy sharing information when both orgs share the same SMTP domain. For the examples below, the source domain is the one retrieving the free/busy info from the target domain. It is assumed that both domains already have a two-way forest trust configured and DNS forwarding is configured.
  • Run the following cmdlet in the target domain:

Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights “ms-exch-epi-token-serialization” -User “sourcedomain\Exchange Servers”

  • Run the following two cmdlets in the source domain:

Add-AvailabilityAddressSpace -ForestName -AccessMethod PerUserFB -UseServiceAccount $true

Export-AutodiscoverConfig -TargetForestDomainController -TargetForestCredential $Target -MultipleExchangeDeployments $true

After these steps are performed the users in the source domain can see free/busy information for users in the target domain.  Repeat these steps, switching the the source and target domains, to allow bidirectional free/busy look-ups.

Be aware that the source domain relies on Autodiscover and Exchange Web Services (EWS) in the target domain.  If Autodiscover is not configured properly (i.e., missing the record in DNS) it will not work.  It also relies on the externalUrl property of the WebServicesVirtualDirectory in the target domain.  That must be set to a valid URL and the SSL certificate used by this EWS URL must be trusted by the source domain.

Inbox Rules Do Not Work on Unity Connections 8.5.1 Messages

I ran into this with a customer recently and wanted to document what I found.  The customer is using Cisco Unity Connections 9.1 for voicemail with Single Inbox and Exchange 2010 SP3.

Cisco’s Single Inbox provides a UM experience similar to Exchange Unified Messaging, where voicemails are delivered to the user’s Inbox as emails with attached WAV files.  The voicemail messages are linked by Unity Connections so that if a user deletes a voicemail in Unity, the email message is also deleted.  Likewise, if the user deletes the voicemail email message in Exchange the voicemail is deleted in Unity.

Unity Connections 8.5.x and later uses Exchange Web Services (EWS) for connectivity to Exchange 2007 and Exchange 2010 mailboxes using a service account.  How Unity programmatically does this is a mystery since it is not documented anywhere in Cisco’s documentation.

The issue here is that the way Unity Connections Single Inbox creates the message in the recipient’s mailbox bypasses the rules table associated with the mailbox.  The result is that rules don’t fire for these messages.  For example, it’s common for users to create an Inbox rule that moves messages from Unity Connections to a custom folder like “Voicemails”.  If you manually run the rule it works as expected.

This issue is documented somewhat in the Cisco Community Forums here:  A comment in this forum post implies this is an Exchange bug, but I’ve confirmed that Inbox rules fire correctly when messages are sent via EWS in a normal manner.  Fellow Exchange MCM, Mike Pfeiffer, has a great post on Sending Email with PowerShell and the EWS Managed API.  I used this PowerShell function to send emails using EWS and test Inbox rules, which worked perfectly.

I’ve tried every creative trick I know to work around this issue, to no avail.  In the end, there’s really nothing that can be done to fix this until Cisco changes to the way it sends Single Inbox messages using EWS.

Configuring Unique Receive Connector SMTP Banners in Exchange Server

My best practice is to create dedicated receive connectors
in Exchange for each receive purpose.  For
example, I’ll create one receive connector for inbound SMTP email from the Internet
or from inbound gateway servers and another for internal application
servers that relay email though Exchange.  Each connector has different
properties, such as source networks, authentication and permission group
settings.  By doing this you have better
control over these connectors and can apply different behaviors, such as
throttling settings.   It also allows you
to disable individual connectors if necessary without affecting other SMTP
Since receive connectors are server-specific, you will
probably create the same connectors on most or all of your hub transport
servers.  When you have a number of
receive connectors spread across several hub transports, it’s useful to know
which server and receive connector is accepting the traffic.  I do this by configuring the banner property
of each receive connector to match the connector name and enable verbose
The SMTP banner property specifies the string that Exchange answers
with on SMTP connections to the specific connector.  By default, Exchange answers with the FQDN of
the server, the Microsoft ESMTP MAIL service string, and the date and time,
like this:

Default SMTP banner

I wrote a two-line script that configures each receive
connector to reply with the server and connector name, like this:

New SMTP banner showing server name and connector name
Run the following script from EMS to change the receive
connector SMTP banners to match the server\connector name:

$rc = Get-ReceiveConnector$rc | % {Set-ReceiveConnector $_.Identity -ProtocolLoggingLevel
Verbose  -Banner “220 $_”}

This script will configure the SMTP banner for all of the receive
connectors in the organization.  It also
enables verbose logging for each connector, which creates receive connector log
files in C:\Program
Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive
.  These log files are useful to see how your receive
connectors are operating.  They also show
the connector name for each connection.

As you can see above, the SMTP Receive log is taking
connections using the
HUB01\Internal Relay receive