Smtp relay in office 365 environment troubleshooting scenarios - part 4#4

of 44 | SMTP Relay in Office 365 environment | Troubleshooting scenarios |Part
4#4
Written by Eyal Doron | o365info.com | Copyright © 2012-2015
SMTP Relay in Office 365 environment |
Troubleshooting scenarios |Part 4#4
The current article is dedicated the subject on – troubleshooting possible problems
when using an SMTP mail relay server for sending mail to the Office 365 mail
infrastructure.
Send mail to Exchange Online – Article Series
 Send mail to Exchange Online | Part 1#4
 Send mail to Exchange Online using standard SMTP session | Part 2#4
 SMTP Relay in Office 365 environment | Part 3#4
 SMTP Relay in Office 365 environment | Troubleshooting scenarios |Part 4#4

4#4
In the former article, we review the concept of how configure IIS SMTP server as a
mail relay in an Office 365 based environment.
When using the option of SMTP mail relay in an Office 365 environment, the mail
flow can be considered as complex because, there are a couple of elements that
are involved in this process and each of these elements has specific characteristics
or specific configuration settings.
In a scenario in which we have problem meaning, mail that is sent by the source
mail client (Hardware device, mail application and so on) doesn’t reach to his
destination (the Office 365 recipient or other external recipient), the ability to point
out the exact cause of the problem is not so simple.
For example, a scenario in which FAX device needs to send E-mail message to Office
365 recipient involved the following steps:
1. FAX device connects the IIS SMTP mail relay server (IIS server in our scenario).
2. The SMTP mail relay server is willing to accept the request from the mail client
(the fax device in our scenario).
2. The SMTP mail relay server connects the “destination mail server” (the EOP mail
server in our scenario).
3. The “destination mail server” is willing to accept the request from the SMTP mail
relay server.
4. The “destination mail server” (EOP) sends the E-mail message to the destination
recipient.

4#4
In reality, the mail flow includes additional steps that we didn’t mention such as
performing DNS resolution process and so on.
Because of this complexity, we need to be familiar with the different components
that are involved in the mail flow and what are the troubleshooting steps,
troubleshooting tools and the methods that we can use in a scenario that the mail
flow is not successfully completed.
Simulating mail flow | mail sent by internal mail client
via IIS SMTP mail relay server
After we have completed all of the required configuration, the best practice is to
implement some kind of “POC” (proof of concept) test, that will enable us to verify
that the mail flow is implemented correctly meaning the E-mail message
successfully reaches the destination recipient mailbox.
To be able to test and verify the mail flow when using an SMTP mail relay, we will
simulate a mail flow in which organization mail client tries to send E-mail message
to Office 365 mail recipient.
The “parameters” that we want to check and verify are:
 The ability of the mail client to contact the IIS SMTP mail relay server and the
ability of the IIS SMTP mail relay server to contact the Office 365 mail server.
 The ability of the IIS SMTP mail relay server to send E-mail on behalf of a different
mail client. As mentioned in the article –SMTP Relay in Office 365 environment |
Part 3#4, in a scenario in which the IIS SMTP mail relay server accepts requires

4#4
from different mail client and need to “forward” the E-mail message to the Office
365 mail server, the users account that is used by the IIS SMTP mail relay server
will need to have Send As permission for each of the “mail client” that addresses
him.
To verify these parameters, we will use two different tests.
Test 1 – a simple test in which we simulate mail client that uses the same E-mail
address as the user credentials that are used by the IIS SMTP mail relay server.
Test 2 – simulate mail client, which use the different E-mail address from the user
credentials that are used by the IIS SMTP mail relay server. In the case, we want to
verify if the required Send As permission was defined for the IIS SMTP mail relay
server user account.
How to simulate the mail flow.
In our scenario, the “real” mail client could be hardware devices such as FAX
machines, Scanner or Printer or a mail-enabled application.
The main problem is that most of the time, this “mail client” doesn’t have the option
for providing clear infrastructure in a scenario of failure, meaning a scenario in
which mail is not sent to the destination recipient.
To be able to get a clear view of the mail flow process, I recommended a very nice
SMTP mail client utility named: Basic SMTP Telnet Client.
The Basic SMTP Telnet Client utility enables us to simulate the mail flow and “see”
the content of the communication channel between the mail client and the mail
server (the IIS SMTP mail relay in our scenario). In addition, we can use the option
of “debug” (enable step by step sending) option to get information about the
specific cause for the problem.
Test 1 – using SMTP mail relay | Destination recipient = SMTP
mail relay credentials
In the first test, we want to verify that the mail flow can be completed successful,
meaning each of the different “elements” that are involved in the mail flow can
communicate each other.

4#4
In our scenario, the mail client will identify himself by using an E-mail address that
is identical to the user credentials that are used by the IIS SMTP mail relay.
Regarding the subject of the “destination recipient” to E-mail address of the
destination recipient doesn’t matter as long as we have the ability to access the
destination recipient mailbox and verify if he got our test mail.
The character of the current scenario is:
 Source recipient – John@o365info.com
 IIS SMTP mail relay credentials – John@o365info.com
 Destination recipient – John@o365info.com
In the following section, we will use the Basic SMTP Telnet Client utility for the
simulating mail flow of the internal mail client.
In use the Telnet properties tab, for configuring the communication setting with the
internal interface of the IIS SMTP mail relay server.
 Receive connector IP: add the IP Address of the IIS SMTP Server (in our specific
scenario, the IP address is – 10.13.137.2).
 TCP Port: This is the port number of the IIS SMTP mail relay “LAN interface”. The
default port which is used for “listing” to mail client is – 25
 Mail From: inside the text box, we will need to add E-mail address the “represent”
the internal mail client that wants to send an E-mail message via the IIS SMTP
mail relay. In our specific scenario, the source recipient is – John@o365info.com

4#4
Recipient To: in this text box, we will need to add the email address of the
“destination recipient” that is supposed to get the mail from the internal mail
client. In our specific scenario the destination Office 365 recipient is
– John@o365info.com
 Subject: this is an optional parameter that will create the “Subject header”. In our
specific scenario, the subject is Test 001
To send the E-mail message we need to choose the Telnet tab and click on
the SEND option
In the following screenshot, we can see that the “first part” in our mail flow, the part
in which the internal mail client addresses the internal interface of the IIS SMTP
mail relay was successfully completed.

4#4
The IIS SMTP mail relay “agree” to accept the E-mail message and he “inform” the
mail client that –
the E-mail message is Queued mail for delivery
The fact that the first part in the mail flow was successfully completed, doesn’t
mean that we can assume that the E-mail message was reached to the destination
Office 365 recipient mailbox.
To be able to verify that the E-mail message was sent by the IIS SMTP mail relay to
the Office 365 mail servers (the EOP that is represented by the host
name smtp.office365.com) we will need to access the destination recipient mailbox
(John in our example) in verifying if he got the E-mail message.
In the following screenshot, we can see that the E-mail message reaches John
mailbox.

4#4
Test 2 – Verify the ability of the SMTP mail relay to send email
on behalf of different mail clients.
In case that the first test was completed successfully and, we know that the mail
flow is configured correctly, the next step is to verify the ability of the IIS SMTP mail
relay to deliver an email message on behalf of different mail clients.
For example, the basic assumption is that each of the mail clients that will address
the IIS SMTP mail relay server will identify himself by using a unique E-mail address.
The IIS SMTP mail relay server identifies himself to the Office 365 mail servers by
using a specific user account (John@o365info.com in our scenario) and to be able to
deliver mail on behalf of another mail recipient; the IIS SMTP mail relay server user
account, will need to be configured with Send As permissions for each of the mail
clients that he will “forward” their requests to the Office 365 mail server.
The characters of the current scenario are:
 Source recipient – Fax@o365info.com
 IIS SMTP mail relay credentials – John@o365info.com
 Destination recipient – John@o365info.com
Pay attention that in this type of scenario, the IIS SMTP mail relay needs to have the
“Send As” permission that will enable him to send the E-mail message on behalf of

4#4
the source mail recipient (in our scenario Fax@o365info.com).
In the following section, we will use the Basic SMTP Telnet Client utility for the
simulating mail flow of the internal mail client.
In use the Telnet properties tab, for configuring the communication setting with the
internal interface of the IIS SMTP mail relay server.
 Receive connector IP: add the IP Address of the IIS SMTP Server (in our specific
scenario, the IP address is – 10.13.137.2).
 TCP Port: This is the port number of the IIS SMTP mail relay “LAN interface”. The
default port which is used for “listing” to mail client is – 25
 Mail From: inside the text box, we will need to add E-mail address the “represent”
the internal mail client that wants to send E-mail message via the IIS SMTP mail
relay. In our specific scenario, the source recipient is – Fax@o365info.com
Recipient To: in this text box, we will need to add the email address of the
“destination recipient” that is supposed to get the mail from the internal mail
client. In our specific scenario the destination Office 365 recipient is
– John@o365info.com
 Subject: this is an optional parameter that will create the “Subject header”. In our
specific scenario, the subject is Test 002.

4#4
To send the E-mail message we need to choose the Telnet tab and click on
the SEND option
In the following screenshot, we can see that the “first part” in our mail flow, the part
in which the internal mail client addresses the internal interface of the IIS SMTP
mail relay was successfully completed.
The IIS SMTP mail relay “agree” to accept the E-mail message and he “inform” the
mail client that –
the E-mail message is Queued mail for delivery.

4#4
The fact that the first part in the mail flow was successfully completed, doesn’t
mean that we can assume that the E-mail message was reached to the destination
Office 365 recipient mailbox.
In our scenario, we will see that the E-mail message was not successfully sent to the
Office 365 recipients.
The IIS SMTP mail relay “agree” to accept the E-mail message, but in the next
section, we will see that the destination mail server (the Office 365 EOP server)
didn’t agree to accept the
E-mail message.
When we access the destination recipient mailbox (John in our example) we
discover that the mail message did not reach John’s mailbox!
The questions that appear are:
Q1: What is the reason for the failure of the mail flow?

4#4
Q2: How can we find information about the cause of the failure of the mail flow?
Q3: How can we fix this mail flow problem?
Reading the IIS SMTP server Log file for getting more
information
A1: The cause of the mail flow failure is a permission problem, or if we want to be
more accurate – “Send As” permission problem. The user account that the IIS SMTP
mail relay users (John@o365info.com) doesn’t have the required permissions to
send E-mail on behalf of the mail recipient – Fax@o365info.com
A2: To be able to get more detailed information about the mail flow and the cause
of the failure, we will use the IIS SMTP mail server mail delivery report that is stored
in a folder named: Badmail.
The full path of the badmail folder is: C:inetpubmailrootBadmail

4#4
In the following screenshot, we can see the information that is saved in the badmail
folder. The IIS SMTP server generates three different files for each “mail delivery
failure”.
Two of the files that appear in the badmail folder or just a simple text file.
To get more information about the reason of the failure, we will try to read the
information in the file with the file extension – *.BDR
In the file, we can see the following error message:
The specific error code was 0xC00402C7.
The problem is that there is not much that we can understand from this error
message.

4#4
The more useful information about the reason of the failure, is located in the file
with the extension – *.BAD
When looking the content of the “BAD File” we can see
Delivery to the following recipients failed. – john@o365info.com
And in addition-
Final-Recipient: rfc822;john@o365info.com
Action: failed

4#4
Status: 5.7.60
Diagnostic-Code: smtp;550 5.7.60 SMTP; Client does not have permissions to send
as this sender
The meaning of this error message is that the IIS SMTP mail relay addresses the
Office 365 mail server (EOP server) and tries to “delver” the E-mail message to the
source mail recipient –Fax@o365info.com
Because the “cloud” identifies the IIS SMTP mail relay as – John@o365info.com and
because John doesn’t have the required “Send As” permission to send E-mail on
behalf of the “Fax recipient” the EOP server refuses to accept the E-mail message.

4#4
Assign the required Send As permission to the IIS SMTP server user
account
To be able to “fix” this issue, we will assign the user account that is used by the IIS
SMTP mail relay – John@o365info.com, Send As permission to the “FAX recipient.”
Note – The basic assumption is that we have already created a distribution group
that
represents” the Mail enabled FAX device entity.
To be able to assign the Send As permission, we will login to the Exchange Online
man agent interface.
 Choose the recipients menu and then the groups menu
 Double-click on the required distribution group (FAX group in our scenario).

4#4
 Choose the menu – group delegation. In the following screenshot, we can see we
can see that by default, no recipient has the Send As permission for this group.
Under the Send As section, click on the plus icon to add recipients that will have the
required Send As permission. In our specific scenario we want to assign this
permission to the recipient named: John, that mail recipient who is used by the IIS
SMTP mail relay.

4#4
After we have added the required permissions, we got to try to send again the E-
mail message.
In the following screenshot, we can see that at this time, the message was
successfully reached the destination recipient mailbox.

4#4
In case that you are a curious person, and you would like to view the information
about the E-mail message delivery that was implemented by the IIS SMTP mail
relay, we can look at the IIS SMTP mail relay log files.
By default, the IIS SMTP mail relay log files are located at the following path:
C:WindowsSystem32LogFilesSMTPSVC1
In the following screenshot, we can see that the SMTPSVC1 folder include many log
files.
We will need to choose the most updated log files.

4#4
When looking at the Log file, we can see a very detailed description for each of the
steps that was implemented in the mail flow between the IIS SMTP mail relay and
the Office 365 mail servers.
For example: we can see that the mail is composed from few phases:
 Phase 1 – the phase in which the IIS SMTP mail relay addresses the Office 365
mail server and the session is a TLS session based.
 Phase 2 – the authentication phase in which the IIS SMTP mail relay provides
his credentials to the Office 365 mail server
 Phase 3 – the phase in which the IIS SMTP mail relay “deliver” the E-mail
message to the Office 365 mail server and provide information about the
source + destination recipient.
 Phase 4 – the Office 365 mail server accept the E-mail message from the IIS
SMTP mail relay and store the E-mail message on the queue.

4#4
Verifying the ability to access office 365 mail server
using TLS protocol
In this section, we will review how to troubleshoot common “causes” for mail flow
problem when using IIS SMTP relay option.
Troubleshooting TLS based mail flow | The elimination concept

4#4
In a scenario in which we don’t manage to send E-mail to the destination recipient,
the most common reaction is: “something is wrong with the cloud”.
If we want to take a more effective approach, the troubleshooting process should
be implemented by eliminating specific components that are involved in the mail
flow process until we can clearly point out the specific element that are not
configured correctly.
For example, on a case that E-mail message that was sent by a mail client such as
FAX device did not reach her destination, we will need to verify if all the
components that involved in the process are configured correctly.
In the following diagram, we can see a standard mail flow when using the option of
SMTP mail relay for sending E-mail message to Office 365 mail infrastructure.
In the following section, we will demonstrate how to bypass the following
components:
1. Mail client (the FAX device in our example)
2. The IIS SMTP mail relay
Our main purpose is to verify that
 We can communicate with the “cloud” (the Office 365 mail server represented
by the hostname –
smtp.office365.com ) using the TLS protocol

4#4
 That the Office 365 mail server is willing to accept our request and deliver or
mail to the destination recipient.
The concept of “secure communication channel” in an Office 365
environment.
Just a quick reminder, the “secure communication channel” is implemented using
port 25 or 587. In our scenario, the basic assumption is that the mail flow will be
implemented as follow:
 The client will address the destination mail server (the EOP server)
 The EOP server will signal to the source client that he needs to use TLS
protocol + provide users credentials.
 The client will provide the required users credentials.
 “Secure communication channel” (TLS) will be created.
 The client will request from the EOP server to send E-mail message to a
destination recipient.
The mail client that will be used for the test purpose
In the following section, we will demonstrate how to test TLS communication with
the Office 365 mail server by using three different mail clients
1. Windows OS client

4#4
2. PowerShell script
3. Graphic mail client named – JBMail
Option 1 – verify communication to EOP server using Windows Telnet
client
One of the simplest ways of verifying a communication channel with a mail server
(the EOP server in our scenario) is by using a Telnet session.
In case that we manage to “Telnet” the destination host, we can know that:
1. We successfully manage to resolve the hostname (smtp.office365.com in our
scenario) into IP addresses.
2. That the network Firewall enables us to “get out” using the required port number
(25 or 587).
3. That the destination server (Office 365 mail server) is “up” and he can respond to
our communication request.
The only “catch” is that the communication with the Office 365 mail server –
smtp.office365.com , should be implemented by using TLS session and the
standard windows OS Telnet client, doesn’t support the use of TLS protocol.
Despite this limitation, I use the option if windows OS Telnet client because it’s easy
and simple, and it allows me to verify the basic elements that were mentioned
(resolve the hostname, etc.).
Using windows telnet client for communicating with the Office 365 mail
server
For example: open a command prompt and type the following commands:
Telnet smtp.office365.com 25
Helo
mail from:john@o365info.com
In the following screenshot, we can see that the communication test fails and the
EOP server sends the Error message:
530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during
MAIL FROM

4#4
The meaning of this Error message is that the “source client” (the Telnet client in
our example), doesn’t manage to successfully fulfill the mandatory requirement for
an encrypted communication channel (TLS in our scenario).
The reason for our failure is that we use the “wrong tools” for the specific task. A
“standard OS Telnet client” doesn’t know how to implement a secure
communication channel using TLS.
Additional reading
How to Use Telnet to Test SMTP Communication
Option 2 – using a PowerShell script for simulating a secure
communication channel with EOP server
To be able to simulate a secure communication channel (TLS channel) between a
specific host and the Office 365 mail server (the EOP -Exchange Online protection
server), we could use a PowerShell script.

4#4
To avoid from the need of typing complicated and strange PowerShell commands, I
have preferred a PowerShell script that is simple to use.
Download the PowerShell Script named:
SendMail.ps1
The SendMail.ps1 PowerShell script is based on a PowerShell code sample that
appear in the article: Send Email via Office 365
The code that included in the SendMail.ps1 PowerShell script
In the following screenshot, we can see the content of the SendMail.ps1 PowerShell
script.
The script includes predefined variable such as the SMTP server name and port
numbersmtp.office365.com and port 25 in our scenario).

4#4
To be able to successfully complete the TLS session with the EOP server, it’s
important to understand that the mandatory requirement for creating the secure
communication channel with the EOP server is by providing the required Office 365
user credentials (UPN name + password).
The first two parameters that we need to provide are the Office 365 username and
password.
The last parameter is the “destination recipient Email address”.
Using the SendMail.ps1 PowerShell script
Then send mail PowerShell script can be excited from the built-in OS PowerShell
console.
To be able to run a PowerShell, we will need to run a PowerShell policy command
that will enable us to run the PowerShell script (by default, the PowerShell policy
will not enable us to run a script).

4#4
In our scenario will be trying to create a secure communication channel between a
specific host and the Exchange Online protection server by using the credentials of
Office 365 users named:John@o365info.com
To simplify the test, we will use the E-mail of John as the “destination E-mail
address”.
Running a PowerShell script first-time configuration.
 Locate the PowerShell console
 Right click on the PowerShell icon and choose the option: Run as administrator
 On the PowerShell console run the following command:
Set-ExecutionPolicy Unrestricted -force

4#4
Run the SendMail.ps1 PowerShell script
To be able to excite the SendMail.ps1 PowerShell script we will need to “call” the
script from the PowerShell console.
In our example, the SendMail.ps1 PowerShell script was saved in the following path:
C:Script
To be able to excite a PowerShell script, we need to type the following charters: “.”
and then the script name.
In the following screenshot, we can see we can see an example of running
the SendMail.ps1PowerShell script:
In the following screenshot, we can see the mailbox of john. We can see the mail
was sent by John from the PowerShell script reach John’s mailbox.

4#4
Option 3 – Send E-mail message to Exchange Online using TLS | GUI
mail client
In the following section, we will demonstrate how to send E-mail message to
Exchange Online (EOP) using an encrypted communication link (TLS).
The mail client application that I found for the purpose of simulating the TLS
session named: JBMail
You download the mail client from the following link JBMail

4#4
The following demonstration is implemented by using two steps:
1. Configure the mail client profile – the step in which we define the user
credentials that will be used for connecting the Exchange Online server, the type
of communication protocol, etc.
2. Create (compose) a new E-mail message.
Scenario description
In our scenario will implement a very simple test: a recipient
named: John@o365info.com that will send mail to himself by connecting the EOP
server (smtp.office365.com) using TLS.
 Choose the Account TAB
 In the User name box, add the recipient credentials that will authenticate himself
to EOP server. In our example – John@o365info.com

4#4
 Choose the Send settings TAB
 In the SMTP host box, type the hostname of the EOP server
– smtp.office365.com (Number 1).
 In the Username box, type the recipient name whom the mail will send by him. In
our example –John@o365info.com (Number 2).
 In the Password box, type the recipient name password that the mail will send by
him (Number 3).
 In the Protocol section, choose the option of – SSL via STARTTLS (Number 4).
 Choose the option of – use SMTP AUTH (Number 4).
 In the Your address box, type the E-mail address of the recipient whom the mail
will be sent by him – In our example – John@o365info.com (Number 5).

4#4
 In the port box, type the port number. In our scenario port 25 (Number 6).
Create a new mail message by choosing the Account tab and click on the Compose

4#4
 In the TO field, add the E-mail address of the destination recipient. In our
example –John@o365info.com

4#4
 Click on the Send button to send the E-mail message

4#4
The following message will appear:
Choose the Accept option

4#4
In the following screenshot, we can see that the E-mail message was successfully
sent to the EOP server.

4#4
In the following screenshot, we can see that the E-mail message was accepted by
John.
In case that we want to be sure that the E-mail message was sent using a secure
communication channel (TLS), we can look at the E-mail message header.
 Double click on the E-mail message
 Choose the more options icon (the three dots)

4#4
 Choose the menu – View message details
In the following screenshot, we can see the mail header of the message that was
sent to John. We can see that the communication was implemented using TLS.

4#4
Verify TLS setting of the Mail server
The implementation of “secure communication channel” between the IIS SMTP mail
relay in the Office 365 EOP server is implemented by using the TLS protocol.
The IIS SMTP mail relay includes a built-it supports in the TLS protocol and gives
that we have created all the required configuration setting that was described in
the article – xxx, the communication channel between the IIS SMTP mail relay and
the Office 365 EOP server who is represented by the host
name: smtp.office365.com is created.

4#4
In some scenarios, in case that we suspect that the problem is related to the TLS
infrastructure, the mail issue is that the TLS communication channel is kind of a
“black box” and by default, we have no simple option to look at the TLS parameters.
In case that you are interested in getting more information about the content of the
TLS session, we can use a nice web site tool named – checktls that can help us to
test a TLS session between client and the mail server.
In the next example, we will look at the TLS session between Office 365 recipient
named:John@o365info.com and the Office 365 EOP server – smtp.office365.com
In the Address text we add the recipient E-mail message – John@o365info.com and
click on theTry it
In the following screenshot, we can see the results.
Number 1 – this is a summary of the whole TLS parameters that are involved in the
communication process. In our scenario, we can see that the TLS communication
channel complete successfully, and all the different parameters are correct.
Number 2 – the part that displays the E-mail address of the “destination recipient”.
Number 3 – the web test application finds the host name of the Office 365 mail
server. In our scenario – o365info-com.mail.protection.outlook.com

4#4
Number 4 – we can see that the TLS session “begin” by using the SMTP command –
STARTTLS
Number 5 – In this section we can see the content of the SSL certificate that the
“destination mail server” provides.
Number 6 – in this section we section we can see that the TLS communication
channel was successfully created.

4#4
Summery and Recap
I feel that we went together on a long journey in the “IIS SMTP World.”
I hope that this information will help you to implement the SMTP relay solutions in
an Office 365 environment.
See you in the next articles
Additional reading
 How to Allow a Multi-function Device or Application to Send E-mail through
Office 365 Using SMTP
 How to configure Internet Information Server (IIS) for relay with Office 365
 SMTP error 550 5.7.1 Client does not have permissions to send as this sender
 Video links

4#4
 Ignite Webcast – SMTP Relay in Office 365
 Everything You Need to Know about SMTP Transport for Office 365

Smtp relay in office 365 environment troubleshooting scenarios - part 4#4

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Smtp relay in office 365 environment troubleshooting scenarios - part 4#4

Similar to Smtp relay in office 365 environment troubleshooting scenarios - part 4#4 (20)

More from Eyal Doron

More from Eyal Doron (20)

Recently uploaded

Recently uploaded (20)

Smtp relay in office 365 environment troubleshooting scenarios - part 4#4