SMTP Relay in Office 365 environment | Troubleshooting scenarios |Part 4#4 5/5 (2) 25 min read

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

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 another external recipient), the ability to point out the exact cause of the problem is not so simple.

The different nodes that are involved in the mail flow

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.

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 completed successfully.

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 “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.

The different components that are involved in the mail flow
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 an E-mail 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 communicate with 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 from different mail client and need to “forward” the E-mail message to the Office 365 mail server, the user’s 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 utilized by the IIS SMTP mail relay server.

Test 2 – simulate mail client, which use the different E-mail address from the user credentials that utilized 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 precise information in a scenario of failure, meaning a scene in which mail does not send 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.

In our scenario, the mail client will identify himself by using an E-mail address that is identical to the user credentials that employed by the IIS SMTP mail relay.

Regarding the subject of the “destination recipient” to the E-mail address of the target, the recipient doesn’t matter as long as we have the ability to access the target 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

Testing mail flow in Office 365 environment using SMTP mail Relay – Test 1

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
    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

Test 1 – using SMTP mail relay - destination recipient -01

To send the E-mail message we need to choose the Telnet tab and click on the SEND option

Test 1 – using SMTP mail relay - destination recipient -02

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 completed.

The IIS SMTP mail relay “agree” to accept the E-mail message and he “inform” the mail client that –

the E-mail is Queued mail for delivery

The fact that the first part of the mail flow completed successfully doesn’t mean that we can assume that the E-mail message reached to the destination Office 365 recipient mailbox.

To be able to verify that the E-mail was sent by the IIS SMTP mail relay to the Office 365 mail servers (the EOP that is represented by the hostname 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.

Test 1 – using SMTP mail relay - destination recipient -03

In the following screenshot, we can see that the E-mail message reaches John mailbox.

Test 1 – using SMTP mail relay - destination recipient -04

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 underlying 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 particular 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 the source mail recipient (in our scenario Fax@o365info.com).
Testing mail flow in Office 365 environment using SMTP mail Relay – Test 2

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.

Test 2 – using SMTP mail relay - destination recipient -01

To send the E-mail message we need to choose the Telnet tab and click on the SEND option

Test 2 – using SMTP mail relay - destination recipient -02

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 successfully completed.

The IIS SMTP mail relay “agree” to accept the E-mail message and he “inform” the mail client that –

the E-mail is Queued mail for delivery.

The fact that the first part of the mail flow successfully completed doesn’t mean that we can assume that the E-mail message reached to the destination Office 365 recipient mailbox.

In our scenario, we will see that the E-mail was not successfully sent to the Office 365 recipients.

The IIS SMTP mail relay “agree” to accept the E-mail, 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.

Test 2 – using SMTP mail relay - destination recipient -03

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?

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.
IIS SMTP mail server – bad mail folder
The full path of the badmail folder is: C:\inetpub\mailroot\Badmail

In the following screenshot, we can see the information that 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
Troubleshooting flow using IIS server – bad mail folder -01

In the log 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.

Troubleshooting flow using IIS server – bad mail folder -02

The more useful information about the reason of the failure, is located in the file with the extension – *.BAD
Troubleshooting flow using IIS server – bad mail folder -03

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

Status: 5.7.60

Diagnostic-Code: smtp;550 5.7.60 SMTP; Client does not have permissions to send as this sender

Troubleshooting flow using IIS server – bad mail folder -04

The meaning of this error message is that the IIS SMTP mail relay addresses the Office 365 mail server (EOP server) and tries to “deliver” the E-mail 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.

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).
    Providing the required send as permissions – IIS SMTP mail relay -01
  • 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.Providing the required send as permissions – IIS SMTP mail relay -02

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.

Providing the required send as permissions – IIS SMTP mail relay -03

After we have added the required permissions, we got to try to send the E-mail message again.

In the following screenshot, we can see that at this time, the message was successfully reached the destination recipient mailbox.

Providing the required send as permissions – IIS SMTP mail relay -04

In case that you are a curious person, and you would like to view the information about the E-mail delivery that 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:\Windows\System32\LogFiles\SMTPSVC1

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.

Providing the required send as permissions – IIS SMTP mail relay -04

When looking at the Log file, we can see a very detailed description for each of the steps that 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 of 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.

looking at the IIS SMTP mail server log files -02

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.

Verifying the ability to access Office 365 mail server using TLS protocol

Troubleshooting TLS based mail flow | The elimination concept

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 practical 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 particular element that is not configured correctly.

For example, on a case that E-mail message that 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 configured correctly.

In the following diagram, we can see a standard mail flow when using the option of SMTP mail relay for sending an E-mail to Office 365 mail infrastructure.

The original involved components in the mail flow

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
  • That the Office 365 mail server is willing to accept our request and deliver or mail to the destination recipient.

Bypassing some of the original components in the mail flow

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 underlying assumption is that the mail flow will be applied 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
  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 straightforward, and it allows me to verify the essential 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 send the Error message:

530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM

The meaning of this Error message is that the “source client” (the Telnet client in our example), doesn’t manage to fulfill the mandatory requirement for an encrypted communication channel (TLS in our scenario) successfully.

Verify secure communication to EOP using telnet 01

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.

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.

Verify secure communication to EOP using PowerShell script

To avoid 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

download-button-02.png

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 number smtp.office365.com and port 25 in our scenario).

To be able to complete the TLS session successfully 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 a PowerShell script for simulating a secure communication channel with EOP -001

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 allow us to run a script).

In our scenario will be trying to create a secure communication channel between a particular 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 administratorUsing PowerShell console – first time -001
  • On the PowerShell console run the following command:
    Set-ExecutionPolicy Unrestricted -force

    Using PowerShell console – first time -002

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.ps1 PowerShell script:

Using a PowerShell script for simulating a secure communication channel with EOP -002

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.

Using a PowerShell script for simulating a secure communication channel with EOP -003

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

downlaod JBMail

The following demonstration 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

Send E-mail to Exchange Online using TLS encryption -01

  • 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).
  • In the port box, type the port number. In our scenario port 25 (Number 6).
    Send E-mail to Exchange Online using TLS encryption -02

Create a new mail message by choosing the Account tab and click on the Compose

Send E-mail to Exchange Online using TLS encryption -03

  • In the TO field, add the E-mail address of the destination recipient. In our example – John@o365info.com
  • Click on the Send button to send the E-mail message
    Send E-mail to Exchange Online using TLS encryption -04

The following message will appear:
Choose the Accept option
Send E-mail to Exchange Online using TLS encryption -05

In the following screenshot, we can see that the E-mail message was successfully sent to the EOP server.
Send E-mail to Exchange Online using TLS encryption -06

In the following screenshot, we can see that the E-mail accepted by John.
Send E-mail to Exchange Online using TLS encryption -07

In case that we want to be sure that the E-mail was sent using a secure communication channel (TLS), we can look at the E-mail header.

  • Double click on the E-mail message
  • Choose the more options icon (the three dots)
  • Choose the menu – View message detailsSend E-mail to Exchange Online using TLS encryption -08

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.

Send E-mail to Exchange Online using TLS encryption -09

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-in supports in the TLS protocol and gives that we have created all the required configuration setting that described in the article – xxx, the communication channel between the IIS SMTP mail relay and the Office 365 EOP server which represented by the host name: smtp.office365.com created.

In some scenarios, in case that we suspect that the problem is related to the TLS infrastructure, the E-mail issue is that the TLS communication channel is 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 an excellent website 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 the Try 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

Check TLS setting on the Office 365 mail server -01

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.

Check TLS setting on the Office 365 mail server -02

Summary 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 🙂

Send E-mail to Exchange Online | Article series index

Now it’s Your Turn!
It is important for us to know your opinion on this article

Print Friendly

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

2 Responses to “SMTP Relay in Office 365 environment | Troubleshooting scenarios |Part 4#4”

  1. What option do I use when I have no control over the sending email address of the device sending to the iis relay?

    • It looks to me that in this scenario, the preferred way will be to use that option which described in the second article in this article series –

      Send mail to Exchange Online using standard SMTP session | Part 2#4
      http://o365info.com/send-mail-to-exchange-online-using-standard-smtp-session-2-3/
      In this solution, the device is addressing the Exchange Online directly without the use of Intermediary such as a mail relay.
      Another flavor of this option is – using a mail relay, but this time, configure the mail relay to address the Exchange Online using the Exchange Online host name, that appears in the MX record without providing a user credentials .
      In this case you don’t have to provide send as permission to the account that is used by the mail relay.

Leave a Reply

Your email address will not be published. Required fields are marked *