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 2022 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 that the SMTP stack itself is not supported.
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. If you run into issues with a crashing MMC snap-in for the SMTP service, this can be quickly solved by editing the IIS MetaBase.xml file.
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.
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. Of course, you can also use a valid 3rd party certificate with the FQDN as its common name. This is what I used for this article.
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.
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.
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.
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 setting | Value |
| smarthost | Smtp.office365.com |
| port | 25 or 587 (recommended) |
| TLS/STARTTLS | Enabled |
| Username/password | Credentials of Exchange Online mailbox |
There are some things you should be aware of when using SMTP AUTH client submission:
- Microsoft is planning to remove basic authentication with client submission (SMTP AUTH) in September 2025. More information can be found here. Keep in mind that Microsoft does not have a good track record when it comes to planning the removal of features.
- 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.
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:
- Relay through a dedicated SMTP server with direct delivery.
- Relay through a dedicated SMTP server using Exchange Online as a smarthost.
- 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. In this article I used the SMTP stack in Windows 2022, this works fine but the SMTP stack in itself is not supported. However, you can also use another SMTP server for this, like a Postfix server for example.
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.
Not mentioned in this article are the new Microsoft High Volume Email solution (HVE) and the Azure Communication Services (ACS). The first one is still in public preview (did you notice this uses basic authentication as well?) and the second one is a paid service. These might well be topics for a future blog.
The Real Person!
The Real Person!
Well said Tony. Been a fan for many years and the Practical365 site is a great resource – thank you for all that you and your team have done for the community!
This article caught my eye because anyone who is trying to remove all on-premise servers will need to consider the very issues discussed in this article. I have a couple of general comments that I hope are relevant.
1) IIS6 has little to no PowerShell support. But there are visual basic scripts around for bulk adds, bulk removes and exporting the list of IP’s being relayed.
2) Microsoft, at one point, was pointing people to SendGrid (which turns out to be a rather good solution.) The authentication limitations however may limit its use in some situations. What we ran into were a) no login flexibility; it always must be APIKey as the authentication login and b) the password length is 69 characters. Many older printers and other devices don’t support passwords longer than ~40 characters.
3) We tried using Smtp.office365.com initially (this was years ago.) It was not consistent and failed to authenticate intermittently. That may have been fixed. But it was not a stable alternative at the time we considered it.
I have been scouring the exchange blogs and other resources for quite some time for relay alternatives. This is the most comprehensive and detailed discussion I have seen yet. Bravo for addressing this!
Anyone use a 3rd party provider like SMTP2GO for this? I’m trialing it out now and to be honest for $10/mo it was pretty easy to setup.
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.
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.
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.
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?
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.
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…
The Real Person!
The Real Person!
Would you mind to elaborate on Azure Communication Services as SMTP relay solution?
You seem to know something about it, otherwise you wouldn’t have mentioned it I guess.
Does https://practical365.com/ecs-email-communication-services/ help?
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.
Exchange Online to retire Basic auth for Client Submission (SMTP AUTH) in September 2025 :
https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-retire-basic-auth-for-client-submission-smtp/ba-p/4114750
IIS is no longer Supported by MS
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.
SMTP Auth is going away also so both solutions here are dead ends.
What operating system are you using for the IIS SMTP server?
I see , win 2019. Work in Windows 2022?
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.
Thanks for the information
Be aware that SMTP AUTH is about to be deprecated…
https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-retire-basic-auth-for-client-submission-smtp/ba-p/4114750?WT.mc_id=M365-MVP-9501
“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.
Be aware that MS will introduce External Recipient Rate Limit.
https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-introduce-external-recipient-rate-limit/ba-p/4114733
So, all your options will be very limited soon when sending to external recipients.