When you run Exchange on-premises servers, you can use the Exchange servers as an SMTP relay. The default Receive Connector can send messages to internal recipients and a dedicated Receive Connector can be created to relay messages to external recipients. I cover this topic in Exchange 2019 SMTP Relay Services.

When moving to Exchange Online, you must plan what to do about SMTP Relay. If you have one or more Exchange hybrid servers, you can continue using these on-premises servers to relay messages, but if the organization wants to decommission the on-premises servers, you must come up with a plan on how to handle SMTP relay. In this article, I explain the available options for SMTP relay when moving to Exchange Online.

SMTP Relay Options

In an Exchange Hybrid environment, one or more Exchange on-premises servers are active. These servers are used for management purposes. They can also be used for SMTP relay, so no action is needed at this point.

If the organization is moving to Exchange Online, multiple options exist for SMTP Relay:

  • Install a dedicated SMTP server.
  • Use authenticated SMTP in Exchange Online.

Installing a Dedicated SMTP Server

Installing a dedicated SMTP server is the easiest solution. Any operating system that supports an SMTP server can be used. For this article, I use a Windows 2019 server with the IIS SMTP service installed. Be aware that there has not been any development in the SMTP stack since Windows Server 2012 and Microsoft is deprecating this service.

The easiest way to install the SMTP server and its management tools is with PowerShell. For test purposes, install the telnet client as well. Use the following PowerShell command to install the SMTP server on a Windows server:

Install-WindowsFeature -Name SMTP-Server,Telnet-Client -IncludeAllSubFeature -IncludeManagementTools -Restart

When installed, use the Services MMC snap-in to change the startup mode of the SMTP service from manual to automatic.

Unfortunately, it is not possible to configure the SMTP server using PowerShell, so the Internet Information Server (IIS) 6.0 manager must be used. Open the IIS 6.0 manager to configure the SMTP server and navigate to the SMTP virtual server.  Open the server properties and configure the following settings:

  • Enable logging
  • Connection control, who can access this SMTP server
  • Relay restrictions, who can relay through this SMTP server
  • Outbound Security, for setting TLS encryption
  • Advanced delivery, for setting a smarthost when needed.

On the Access Page (Figure 1), you can see that TLS is not available on this server.

Practical Exchange: Understanding SMTP Relay in Exchange Online
Figure 1: SMTP Virtual Server properties in the IIS 6.0 Manager

Out of the box, no certificate is installed on a Windows SMTP server. You can use the Internet Information Server Manager MMC snap-in to create a self-signed certificate. Open the IIS Manager, select the server, and in the actions pane select the Create Self-Signed Certificate option and follow the wizard to create a self-signed certificate. When running the wizard, make sure you select ‘personal’ to store the certificate and not ‘webhosting.’ When the latter is selected, the SMTP service cannot access the certificate. When finished, open the SMTP virtual service properties again and check the Require TLS encryption checkbox.

You can now configure your device or application to use this SMTP server to relay messages to external recipients, providing of course that the IP address of the device or server is added to the allowed list on the SMTP server.

After sending a message from a device, in my example from a Synology NAS in my office to a Gmail mailbox, check the headers of the email to validate that it is relayed through the SMTP server and that the connection to Gmail uses TLS. This is shown in Figure 2.

Practical Exchange: Understanding SMTP Relay in Exchange Online
Figure 2: Header information when using a Windows SMTP Server.

When examining the header information, you can see that the SPF alignment is good. The public IP address of the NAS device is added to the domain’s SPF record. There’s no DKIM signing option in the Windows SMTP service and there’s no open source module available for this. Using a smarthost instead of direct delivery is a better solution.

To configure a smarthost in the SMTP service in Windows, open the IIS 6.0 Manager MMC snap-in, open the properties of the SMTP Virtual Server and navigate to Delivery, then Advanced, and enter the smarthost in the correct textbox. This is shown in Figure 3.

Practical Exchange: Understanding SMTP Relay in Exchange Online
Figure 3: Configuring a smarthost in the Windows SMTP Server

The smarthost you must use is in the form or <yourdomain-tld>.mail.protection.outlook.com.

This configuration won’t work out of the box because the inbound connection to Exchange Online is not authenticated and thus is not allowed to relay messages. To fix the problem, create a new inbound connector in the Exchange Online admin center and set the connection to be from ‘your organization’s email server’ or ‘partner organization.’ Make sure that the inbound connector is secured by your public IP address.

With the configuration in place, when I send a message from the device in my office to Gmail, it is relayed through the Windows 2019 server via Exchange Online to the Gmail account. When checking the header information of the message, I can see confirmation of the correct mail flow and that the message passed the SPF and DKIM check (Figure 4). The ‘DKIM Authenticated’ error is caused by a copy-and-paste error in the MXTOOLBOX tool, which is a known issue.

Practical Exchange: Understanding SMTP Relay in Exchange Online
Figure 4: Relaying a message via Windows 2019 and Exchange Online.

Move SMTP Relay to Exchange Online (SMTP AUTH submission)

Instead of installing, configuring, and maintaining a dedicated SMTP server, it is also possible to relay SMTP messages directly via Exchange Online. In this scenario, the device signs into an Exchange Online mailbox to send email messages, both internal and external.

To do this, you must configure your device or application using the properties as shown in Table 1.

Device settingValue
smarthostSmtp.office365.com
port25 or 587 (recommended)
TLS/STARTTLSEnabled
Username/passwordCredentials of Exchange Online mailbox
Table 1: Settings when using SMTP AUTH client submission.

There are some things you should be aware of when using SMTP AUTH client submission:

  • An Exchange Online mailbox must be used. This mailbox can have the lowest-cost license available, like an Exchange Online P1 license.
  • Make sure the mailbox is not secured by MFA.
  • The device or application must support TLS/STARTTLS.
  • Authenticated client SMTP submission must be enabled. This can be enabled on a tenant level or on a mailbox level. For more information on how to do this please check out this Microsoft post.

When SMTP AUTH is configured and a testmail is sent, the headers of the email can be analyzed to check the mail flow. This is shown in Figure 5.

Practical Exchange: Understanding SMTP Relay in Exchange Online
Figure 5: Header information when using SMTP Auth client submission

As with the SMTP Relay through Exchange Online, the SPF check and DKIM check passes and the message is delivered successfully to the Gmail mailbox.

Weighing the Options

When moving to Exchange Online and decommissioning on-premises Exchange servers, you must have a solution for SMTP relaying from applications or devices.

In this article, I explained three possible solutions:

  1. Relay through a dedicated SMTP server with direct delivery.
  2. Relay through a dedicated SMTP server using Exchange Online as a smarthost.
  3. Relay through Exchange Online using SMTP client submission.

The first option just works, as long as the receiving mailserver does not perform a DKIM check. The second option is better since it uses the security features of Exchange Online. A dedicated SMTP server on-premises is used, but all the devices and applications in your organization are centralized in this SMTP server.

The third option is to not use an SMTP server, but all applications and devices need to be configured with SMTP Submission credentials. This configuration must be maintained to ensure that mailboxes can continue to send email.

About the Author

Jaap Wesselius

Jaap is an independent consultant based in The Netherlands. Starting with Exchange 5.0 in 1997, he has been working with Exchange for almost half of his life. After leaving Microsoft as an employee, Jaap started as an independent consultant in 2006, continuing to work with Exchange and later on with Exchange Online. Besides consulting work, Jaap is an author of several books (some coauthoring with Michel de Rooij), blogger, presenter, and these days part-time (kids leaving the house) dad. Besides working with Exchange, Jaap is also a motorcycle enthusiast, owning several motorcycles. For his work in the community, Jaap received the MVP award back in 2007, an award that was constantly re-awarded up to this day, something he is very proud of.

Comments

  1. Jaap Wesselius

    Thanks everyone for all the comments.
    Overall it’s a bad story here from Microsoft. Customer want to get away from their Exchange servers, but there’s not really a good alternative here. Yes, you can use the SMTP service in Windows 2019 and Windows 2022 (the MMC issue turned out to be an entry in the Metabase.xml file) but despite it is in Windows 2022, it was part of IIS6 and as such not supported. HVE is on the horizon, but only targeted for internal recipients and ACS is a paid service.
    SMTP AUTH is still available in Exchange Online and widely used. Millions of applications and devices can only do this, so I don’t see this going away anytime soon (that’s my personal opinion). So yes, it’s a bad story.
    And about my time… I’m not a professional writer, I’m a consultant and working full time with customers on all sorts of Exchange things and I write about things I see in real life (and which I can repro in my lab) in my spare time.
    And if you think you can do better (no pun intended) feel free to contact us to become an author as well, you are more than welcome.
    I will try to make some changes to the article regarding the things I just mentioned and the comments that are left here.
    Thanks all.

    1. Cyril

      I posted my comments to warn some community members, that would chose a path, maybe consume time to make a long-term configuration, with some options that will sadly be deprecated. Unless they are, they can be used obviously, but don’t spend to much time configuring a state-of-the-art relay system that won’t work in a few months.
      The problem here is, many messaging admins are missing solutions from Microsoft. Microsoft deprecating old products or auth protocols is indeed a good news, but we need alternatives. Especially as some companies already got rid of their Exchange Servers. With Microsoft deprecating SMTP AUTH online, we still need to relay emails from old appliances, we need a non-Exchange Server working and above all supported SMTP relay solution, that’s the situation in the current world, whether Microsoft likes it or not. I think it’s therefore a sensitive subject for Messaging admins at this time, and when we see this kind of title in an article, we all hope to see the miraculous announcement or solution we are all waiting for, therefore creating some disappointment. But this situation is Microsoft’s fault, not yours, thanks for sharing your knowledge and solutions to the community, it’s as precious as the time you’re saving us with clear explanations.

      1. Avatar photo
        Tony Redmond

        Unfortunately, Practical365.com cannot create a solution out of thin air. We also cannot report information that Microsoft has shared with our authors under NDA. I think it is fair to say that all of the folks here who work with Exchange Server and Exchange Online are intensely aware of the issue around SMTP relay. Microsoft is as well, but again, we cannot report what doesn’t exist today and what might not exist if development plans fail. If you want to read about aspirational delivery of software, read Microsoft’s blogs where they can describe future plans and dates. If you want to read what’s available and can be implemented today, read our articles.

  2. Miriam

    I was excited to see an article about SMTP Relay in Exchange Online, but I’m disappointed to see only obsolete or soon-to-be-obsolete options (Server 2019, SMTP AUTH, Basic Auth, ERR) without pointing those out and relying on readers’ comments to bring up that these features are short-lived or have limitations?

    Is the audience of this article subject matter experts that can read between the lines and already know what works and what doesn’t or is the audience less-experienced admins trying to learn about technologies to use in their environments? I would have thought the latter and for those, this article is misleading.

    And what is it with “I was not able to get the MMC snap-in working and I didn’t have enough time to figure out what was wrong there.” If someone doesn’t have enough time to figure out a problem, should they just omit details from their post or should they spend the time figuring it out before they post? I think that’s a no brainer.

    Lastly, why not mention HVE or Azure Communication Services in an article about Exchange Online and SMTP relay?

    Is the quality of this post representative of other articles on this site?

    1. Avatar photo
      Tony Redmond

      AFAIK, Exchange Server 2019 is the current version and will not be replaced untl Exchange Server Subscription arrives Edition arrives in Summer 2025. I think it is perfectly acceptable to discuss Exchange 2019 at this point.

      SMTP AUTH and Basic AUTH are still available in Exchange Server. SMTP AUTH will be removed from Exchange Online, but it’s still there.

      ERR won’t be in Exchange Online until 2025. HVE is still in preview and it and ACS will incur additional cost. I would like to write about HVE but I cannot because Microsoft cannot resolve a problem in my tenant (expected in previews). I don’t write about stuff until I have tested it thoroughly and I suspect that’s the same for Jaap.

      The audience for Practical 365 is formed largely of people who need practical, hands-on advice for running online or on-premises environments. As it happens, the author of this piece is a highly experienced Exchange MVP who has huge knowledge of solving customer problems. Whether or not he didn’t care to spend time figuring out why an MMC snap-in failed is immaterial if his advice is sound and accurate.

      If you care to read the articles on this site, I think you’ll find that they cover real-life topics with a very practical perspective. I think we’re well ahead of any other site writing about Microsoft 365 and Exchange Server today. If you can point to other sites that have published hundreds of articles about different topics in these areas that does better, I am all ears because I have not found one. There are always one-off articles that document invaluable nuggets of information that cannot be found elsewhere, but the value of a site is measured over time and not by individual articles.

      1. Avatar photo
        Tony Redmond

        By the way, it’s always easy to criticize writers. If you’re up to the challenge, try writing for Practical 365 and see how it goes…

  3. Jaap Wesselius

    I know where you’re coming from, but what you say is not true.
    IIS is supported, but the SMTP stack is part of the old IIS6 bits and that’s not supported for a long time now. But the bits are still in Windows (how odd, I think nobody cares to remove it from the source) and still usable. But officially the SMTP stack is not supported.

  4. Manpreet Singh

    IIS is no longer Supported by MS

  5. Jaap Wesselius

    Yes, Windows 2019. The SMTP stack is included in Windows 2022, but I was not able to get the MMC snap-in working and I didn’t have enough time to figure out what was wrong there. On the other hand, the SMTP strack is deprecated for a long time, so I’m not sure if Microsoft is willing to help here.

  6. John

    SMTP Auth is going away also so both solutions here are dead ends.

  7. Fabio

    What operating system are you using for the IIS SMTP server?

    1. Fabio

      I see , win 2019. Work in Windows 2022?

      1. Max

        SMTP daemon doesn’t work in Windows Server 2022. The MMC snap-in crashes when you want to make configuration changes. And in Windows SErver 2025 the feature will be completely removed.

        1. Jaap Wesselius

          Thanks for the information

  8. Cyril

    “Make sure that the inbound connector is secured by your public IP address.” I understand that in this tutorial it’s the quickest and simplest way to make it work, but a certificate-based connector is the best practice, right ?

    Regarding SMTP AUTH on Exchange Online, Microsoft announced its end of life in September 2025.
    https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-retire-basic-auth-for-client-submission-smtp/ba-p/4114750.
    Still works and can be used, but good to know if you start using it now.

Leave a Reply