One of the most common questions among Office 365 customers is: how to implement a scenario in which on-Premises device or application, sends mail via the Exchange Online infrastructure.
The main reason for the uncertainty regarding this process arises from two main factors:
- The Office 365 and Exchange Online environment is unknown territory for many IT managers versus the on-Premises mail infrastructure.
- The formal information that exists in this scenario is difficult to understand and doesn’t include an explicit reference to different a kinds of mail flow scenarios, troubleshooting scenarios and so on.
The primary purpose of the current four article series is to expose and explain the two main options that are available to us for implementing mail delivering via Exchange Online and provide a “how to“ description of the required steps and configuration settings.
Send mail to Exchange Online – Article Series
Send E-mail to Exchange Online | The article series
The subject of: “Send E-mail to Exchange Online” will be reviewed in a four-article series.
- Send E-mail to Exchange Online – an introduction to the special characters of the Exchange Online and EOP (Exchange Online Protection) mail environment.
Review the two most important mail flow scenarios which can implement – un-authenticated, standard SMTP communication channel versus authenticated + encrypted TLS communication channel and, what the main characters of each of these options.
- Send E-mail to Exchange Online using Exchange Online MX record – a step by step description of how to send E-mail via Exchange Online, using a standard SMTP session by addressing the Exchange Online server using the MX record hostname.
- SMTP Relay in Office 365 environment – a step by step description of how to send E-mail via Exchange Online using a secure communication channel (TLS) and addressing the Exchange Online server using the generic hostname – smtp.office365.com.
- SMTP Relay in Office 365 environment – Troubleshooting scenarios – Article that is dedicated the subject of – troubleshooting possible problems when using a SMTP mail relay server for sending mail to the Office 365 mail infrastructure.
I need to send mail to the cloud! – Who is the “cloud”?
Let’s start with the definition of the most basic terms.
When we say that we need to send mail to the “cloud,” what is the meaning?
Who is this “cloud” that we want to address?
In the Office 365 environment, the mail infrastructure is implemented by using the Exchange Online architecture.
In the Office 365 environment, when we say that we want to send a
E-mail to the “cloud,” we mean – sending E-mail to Exchange Online based server.
If we want to be more accurate, in an Office 365 environment the “representative” of the Office 365 mail infrastructure that “talks” to elements of the public network is the EOP – Exchange Online Protection.
The EOP serves as the mail security gateway that protects the Office 365 mail infrastructure.
Exchange Online server’s responsibility is to host the Office 365 user mailboxes, and the EOP responsibilities are to handle mail security and communication with the public network.
Most of the time we relate to EOP server as a “single entity” but if we want to be even more accurate, the term “EOP” does not refer to a particular Exchange mail server, but instead, to tens and maybe even hundreds of “hosts” (EOP mail servers).
I need to send mail to the cloud! – Who is me?
An additional term that we need to clarify is the term “I” or “me.
When we say that we need to send E-mail to Exchange Online, what is the object that serves as the “source mail client”?
In reality, the “source mail client” can be translated into a number of options such as:
- Hardware device such as a printer or scanner which needs to send an E-mail message to our users by addressing Exchange Online as “his mail server”.
- A particular application such as mail application or application that has “client capabilities” that needed for sending an E-mail message by connecting to a mail server that will forward the E-mail to the required recipients.
- On-Premise mail server or a mail security gateway that needs to forward or delivers E-mail messages to Exchange Online (this scenario doesn’t relate to Exchange hybrid environment).
- The external website that needs to send an E-mail to the recipient via Exchange Online.
It’s important that we understand that there is a different type of “source mail client” because each of the specific mail clients has different characters and capabilities.
- Most of the hardware devices such as printers and scanners, don’t support, the option of using a protocol such as TLS that enables to create an encrypted communication channel between the mail client and the server.
- In case that we deal with a scenario of communication failure between the mail client and the mail server (EOP in our scenario), not all the mail clients include an error log that will help us to find the particular case of the mail flow problem.
Office 365 Public mail infrastructure | Two interfaces
When we want to address the “Public mail server” of Office 365, we can relate to the EOP (Exchange Online Protection) server by using two different “entities.”
- EOP Entity 1 – the EOP entity that represented by a generic name: smtp.office365.com
When we address the EOP server by using this host name, the EOP server places a mandatory requirement before the mail client – the need for authentication (provide Office 365 user credentials) and, to need for supporting the option of secure communication channels (using the TLS protocol).
- EOP Entity 2 – the EOP entity that is represented by MX record hostname. Office 365 provides a dedicated MX record for each of the public domain name names who registered by Office 365 tenants.
When we address the EOP server by using the hostname who appears the domain MX record or, by using the public IP address that is “mapped” to the MX record, the mail client can address the EOP server by using a “standard SMTP communication channel”.
In this scenario, the mail client doesn’t need to implement encryption and authentication.
EOP – Two interfaces
In the following diagram, we can see a representation of the EOP server “two interfaces.”
At first glance, an obvious question could appear in our mind: Why does the EOP need to have two different interfaces (entities)?
The general answer to this question is that – each of the EOP “identities” created for answering different mail flow scenario.
In the following diagram, we can see a summary table that compares the two “EOP identifies” and the characters of each scenario.
Implementing – “secure mail flow.”
The “formal identity” or interface of EOP is defined as a secure communication channel.
When we chose to implement secure communication channel with EOP, we address the EOP server by using the generic hostname: smtp.office365.com
I use the term “generic hostname” because this hostname is not related to a particular Office 365 tenets or a specific public domain but, to all the Office 365 tenants that use a mail client, that need to address a “mail server.”
I use the term: “secure communication link” because when we address the EOP hostname: smtp.office365.com the mandatory requirement is that the mail client will be able to provide user credentials + use an encrypted mail protocol – the TLS protocol.
Advantages of using a “secure communication link” with EOP
The main benefits of using a “secure communication link” are:
- Data privacy and protection – the information (mail flow) that is traveling on the communication channel via public network infrastructure is protected.
- The ability to send E-mail to the external recipient – the secure communication link is based on a step, in which the mail client will need to identify himself by providing Office 365 user credentials.
After the authentication, process is completed, the mail client will be able to send
E-mail message to internal Office 365 recipients or external recipients.
The ability of a recipient to address a mail server and ask it to deliver email messages to an external recipient (recipient who has a domain name that the mail server is not authoritative for it) considered as a “relay.”
The “relay operation” will be implemented by the EOP and Exchange Online only if the mail client considered as an “authenticated user.”
In case that we want to enable a particular device such as a printer which is represented by the E-mail address: [email protected]
To send an E-mail to an external recipient, who uses the E-mail address: [email protected], the mail client (the printer in our scenario) will have to consider as an “authenticated user.” Only then the EOP server will “agree” to forward the E-mail message to the external recipient.
Disadvantages of using a “secure communication link” with EOP
The main disadvantages of using a “secure communication link” are:
- In case that the mail client such as the hardware device, doesn’t support TLS, we will need to install and configure a mail relay that supports TLS communication.
The purpose of the mail relay is to represent the mail client that doesn’t support TLS in front of the EOP server.
- In case that we use mail relay and, we need to use the option of delegation (the option in which the mail client uses different identity -E-mail address from the mail relay credentials), we will need to provide “Send As” permission to the mail relay user account. The Send As permissions will enable the mail relay to send E-mail on behalf of the mail client.
Note – you can read more information about this subject in the article – SMTP Relay in Office 365 environment
- In a troubleshooting scenario in which we try to configure a particular mail client to implement a secure communication channel (using TLS protocol) with the EOP server, and the connection with EOP fails, most of the time it’s not easy to get details about the reason or the cause of the problem, that prevents the creation of the secure communication link with EOP.
Implementing – “non-secure mail flow.”
The need to create a TLS communication channel with the EOP server and provide a user’s credentials could be considered as “problematic” in some scenarios.
For example, a scenario in which the mail client (application or hardware device) doesn’t support, the option of using the TLS protocol.
In this case, the available options that we can use are:
- Using Intermediary element, such as a mail relay that supports TLS based communication, which will mediate between the mail client (that doesn’t support TLS communication) and the EOP server.
- Addressing the “other identity” of EOP by using the EOP Hostname, which used for representing our domain name (the Hostname, who appears in the domain MX record).
Advantages of using a “non-secure communication link” with EOP
The main advantage of using mail flow that considers as a “non-secure communication link” is that in case that our device or application doesn’t support TLS and, we don’t have the option to use an Intermediary element; such as a mail relay, we can enable the mail client to communicate directly with the EOP server.
In other words: the mail client will need to provide user credentials and support the use of the TLS protocol.
Disadvantages of using a “non-secure communication link” with EOP
- The Inability to send E-mail to the external (non-Office 365 recipients) recipient.
- Data (mail flow) that transferred over a non-secure network (the public network infrastructure) is not protected.
- The need to add a configuration setting in the Exchange Online server that will prevent the phenomenon in which the E-mail message sent by the “Anonymous mail client” will be classified as spam.
It is important for us to know your opinion on this article