Send messages through Office 365 using devices which don’t support TLS

You are here:
< Back

Goal / Scope

When moving to cloud services, challenges will always be present.  Office 365 is no exception.  Aside from potential compatability issues (see this link for more details), other issues like sending email messages from a printer / scanner device can also be problematic if the printer / scanner doesn’t support TLS for example.  The following provides a workaround to resolve the inability to send messages to mailboxes with a device that doesn’t support TLS.


If on-premises devices or Line of Business applications need to send email via Office 365 but do not support TLS, an IIS SMTP relay can be setup to provide a gateway to allow these devices or application to send messages without the need of TLS.

Requirements: An available server capible of running IIS, IIS SMTP relay services installed, an account on Office 365 with a mailbox for authentication.

Solution / Action

General SMTP Relay settings for Office 365

  • A licensed User with mailbox on Office 365
  • Outbound SMTP Port will need to be set to 587
  • TLS Encryption is required
  • SMTP smart host server is
  1. Sign into Outlook Web App
  2. Navigate to Options, then select See All Options
  3. Under Account, My Account, Account Information, click the link Settings for POP, IMAP, and SMTP access…
  4. Information provided will be your SMTP settings

Configuring IIS

1. Create a user with an Exchange Online mailbox

  • You can either create the user in your Active Directory, run Directory Synchronization, Activate user with Exchange Online license. (The user must not have an on-premise mailbox)
  • Or you can create the user using Microsoft Online Portal or via Microsoft Online Services PowerShell Module and assign the user an Exchange Online license.

2. Configure the IIS SMTP Relay server.

  1. Install IIS onto an internal server, selecting to install the SMTP components
  2. Expand the Default SMTP Virtual Server and click the domains node
    1. Right-click Domains and select New > Domain > Remote
    2. In the Name line enter “*.com” and click Finish
  3. Double-click the newly created domain
    1. Ensure “Allow incoming mail to be relayed to this domain is checked
    2. In the “Forward all mail to smart host“, type


4. Click Outbound Security and configure the following settings:

    1. Select Basic Authentication
    2. For User, type the user name and password of the user created on Office 365 above
    3. Check the TLS encryption option
    4. Click OK


5. Right-click the Default SMTP Virtual Server node and select Properties

1. Click the Delivery tab

2. Click Outbound Connections

      1. Change TCP Port to 587
      2. Click OK


3. Click Outbound Security

    1. Select Basic Authentication
    2. For User, type the user name and password of the Office 365 mailbox user
    3. Check the TLS encryption option
    4. Click OK


4. Click the Access tab

a. Then select Authentication tab, select Anonymous access, Then click OK


b. Then select Relay tab, then select Only the list below, Add the IP address(es) of any devices and / or any servers with Line of Business appications which will be sending the email messages.


Restart IIS and the devices given access should now be able to send messages via this relay.

Known Issues / Troubleshooting

This section is for the issues that have well defined and tested solutions or are known issues with a specific product or service.

Problem: | Email messages appear to be sent, but no messages are ever recieved using a Windows 2003 server as the relay

Solution: | This is a known issue with Windows Server 2003.  The following steps can be taken to resolve this issue, or upgrading to Windows Server 2008 would also be an option.

The resolution is to apply the following registry changes to the system.  This .reg file will modify the default settings of AES128 and TLSv1 to use SSL 3.0.  AES128 is still supported, but not in combination with TLSv1.  If the relay fails, before performing the steps to modify the registry, perform the following.

  1. Double check the configuration
  2. Reboot the server
  3. test the configuration again

If the test is still unsuccessful, the following steps should insure proper installation of the changes.

  1. Stop the SMTP service
  2. Backup the “mailroot” folder (the default location is C:\inetpub\mailroot)
  3. Remove all files in the subfolders of the mailroot directory (IMPORTANT: leave the folders themselves)
  4. Create a backup of the following registry key:  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
  5. Delete all the keys under SCHANNEL
  6. Import the registry file located here (NOTE:  The file extension will need to be changed from .txt to .reg)
  7. Reboot the server
  8. Test the configuration again A great utility for testing in such situations is called SMTP Prober
  9. Watch the mailroot\Queue folder for activity.  (The message will dissappear from this location once successful transmition of the message is complete)
  10. If pending message transactions were in the system prior to these steps, copy the files from the mailroot\Queue and mailroot\Pickup folders from the backup copy of your mailroot completed in step 2 above.

Problem: |  Messages are not received as expected when using a Windows 2008 server relay

Solution: |  Double check the configuration.  Verify the smart host and forwarding options.  Enable logging, and review them for possible information related to the failure.  There are no known issues with Windows Server 2008 and communication with Office 365 at this time.


How to set up an SMTP relay in Office 365 |

SMTP relay has stopped working |

IIS6 – SMTP Virtual Server – Mails stuck in queue |

Last Updated On October 24, 2017