Years go by and we continue to see customers still relying on the IIS 6.0 SMTP virtual server feature, which has been out of support for a looong time. To give you an idea just how old this component is, the built-in IIS SMTP virtual server stack was tied to Windows Server 2003. This blog post aims to present practical options to help you retire IIS SMTP and replace it with supported Microsoft solutions (because IIS SMTP virtual server is long unsupported).
Historically, we have encouraged customers to retain their last Exchange on‑premises server in certain scenarios. One of the most common scenarios is on‑premises applications still depend on Exchange for email relay, even after all mailboxes have been migrated to Exchange Online.
Then there are also cloud‑only Exchange Online customers who have already decommissioned their last on‑premises Exchange server (or never had one at all) and, for various reasons, are unable to configure their applications, Fax and printers to relay email directly through Exchange Online. When this scenario applies, the most straightforward and supported way to eliminate the use of IIS SMTP is to replace it with a standalone Exchange Edge Transport Server. This also helps with centralized administration of one or few Edge servers instead of several applications and devices individually.
You might not know this, but running a standalone Exchange Edge Transport server can be done with minimal overhead.
It’s important to clarify what “standalone” means in this context. A standalone Edge Transport server is not subscribed to an Active Directory site. Whether or not the server is domain‑joined is irrelevant here; what truly matters is that the Edge Transport server is not Edge‑subscribed to Active Directory. In this configuration, Active Directory is effectively unaware of this Exchange server’s existence.
Why does this matter? Because subscribing an Edge Transport server to an AD site introduces additional complexity such as EdgeSync, dedicated certificates for Direct Trust, and extra operational considerations. The goal of this blog post is to provide a simple, low‑effort, and supported solution that allows you to finally retire use of legacy IIS 6.0 SMTP server without introducing unnecessary complexity into your environment.
Let’s see the following flowchart to understand the big picture of options you have:
¹ It is important to consider if the application and devices send email to only Exchange online mailbox or also send to external domains. Based on the requirement, you will need to evaluate your options mentioned in this article. If you want to send emails to external domains which essentially is relaying through Exchange online, you can:
- Configure a TLS certificate-based connector for SMTP relay - this is a secure way to relay email. You need a certificate where the Subject or Subject Alternate Name (SAN) fields contain an accepted domain in Microsoft 365.
Or you can
- Configure an IP address-based connector for SMTP relay - this is a less secure way to relay and is not recommended. With this method, the sender domain mentioned in the MAIL FROM must match one of the accepted domains of the tenant.
Whether you use Certificate based or IP Based connector, make sure you meet the requirements mentioned in this article.
Is it feasible to redirect all on-premises applications to Exchange Online?
There may be multiple blockers, such as:
- Applications that are not allowed to perform outbound external connectivity
- Legacy applications with unknown ownership or configuration
- Limited ability to update or reconfigure existing applications
There are several challenges to send or relay email directly from Application and devices. Applications and devices may not support TLS/STARTTLS, and managing certificates across multiple endpoints – such as printers in branch offices – can introduce significant operational complexity and potential security risks.
A more suitable solution in this case is to deploy a standalone Edge Transport server. This allows you to centralize SMTP relay functionality and securely send messages to Exchange Online or external domains without requiring individual devices or applications to meet strict TLS and certificate requirements.
What type of authentication is used by these applications?
For example, Basic Authentication or NTLM. If either is in use:
- SMTP Basic Authentication is being deprecated in Exchange Online
- NTLM is not supported with Exchange Online for SMTP scenarios
As a result, reliance on these authentication methods may prevent Exchange Online use.
IIS 6.0 SMTP Assessment
Once you decide to replace your IIS SMTP server, one of the first and most critical steps is to perform a thorough assessment of its current usage.
If logging is not already enabled, ensure it is configured by navigating to:
IIS → SMTP Virtual Server → Properties → Enable Logging → Properties → Advanced
From there, select all relevant extended logging fields that will help you identify which applications and systems are relying on the IIS SMTP server.
It is recommended to allow logging to run for a sufficient period to capture a representative volume of data. This ensures that intermittent or less frequently used applications are also identified.
Additional aspects that should be assessed include:
Access tab → Authentication
Verify which authentication methods are enabled, such as:
- Anonymous access
- Basic Authentication
- Integrated Windows Authentication
Access tab → Relay Restrictions
Confirm whether relay access is restricted to a defined list of IP addresses and review the scope of those restrictions.
Delivery tab → Advanced
Determine how outbound email is being routed:
- Whether the server uses a smart host or performs direct DNS lookups
If a smart host is configured:
- Go back to Access tab → Outbound Security
- Verify whether authentication is required and which method is being used to connect to the smart host
To map these configurations to Exchange Edge Transport, keep the following in mind:
- Settings configured under the “Access” tab in IIS SMTP will typically correspond to the Receive Connector on the Edge Transport server.
- Settings configured under the “Delivery” tab will map to the Send Connector on the Edge Transport server.
Once IIS SMTP logging has been enabled and sufficient data has been collected, the next step is to analyze the logs to identify key usage patterns, such as:
- Source IP addresses of applications relying via the IIS SMTP server
- Sender SMTP addresses
- Recipient SMTP addresses
- Email volume per application and per day
IIS SMTP logs are not particularly user-friendly for analysis, especially at scale. As a result, you have few options to process and extract meaningful insights from this data:
- Develop your own SQL query using Log Parser and Log Parser Studio or
- Share your IIS SMTP logs with Copilot and ask it to parse according to your needs
Another important aspect to assess is how applications are configured to connect to the IIS SMTP server:
- Do applications reference the IIS SMTP server via a hard-coded IP address, or via a DNS alias? The alias could be either a CNAME or a host (A) record.
If applications are using a DNS alias, the transition to Exchange Edge Transport is typically straightforward. In this case, you can redirect mail flow by simply updating the IP address associated with the alias in DNS. However, if applications are configured with a hard-coded IP address, the transition becomes more complex. In this scenario, you have two main options:
- Update each application individually: Replace the IIS SMTP server IP with the Exchange Edge Transport IP. This is the cleanest approach; however, it is often the most time-consuming and operationally challenging.
- Reuse the existing IIS SMTP IP address: Assign the same IP address to the Exchange Edge Transport server as a secondary IP. While Microsoft generally discourages IP reuse in Exchange environments, this guidance primarily applies to AD-integrated Exchange roles. In this case, since the Edge Transport server is standalone and does not store objects on Active Directory, IP reuse can be acceptable if carefully planned and executed.
Once all relevant IIS SMTP data has been collected and analyzed, you can proceed with the Exchange Edge Transport deployment.
If additional details are required for the assessment phase, refer to the FAQ section, where common caveats and IIS SMTP-specific considerations are covered.
Exchange Edge Transport considerations
Assuming you have decided to decommission IIS SMTP and use the Exchange Edge Transport role for email relay, the next key decision is whether the Edge Transport server should be deployed on a domain-joined machine.
Microsoft generally recommends deploying the Edge Transport role on a non-domain-joined server. However, this guidance applies primarily to traditional Exchange environments where Edge Transport is installed in the perimeter network and is subscribed to an Active Directory site that includes Mailbox servers.
In a scenario where no Exchange Mailbox role is present, the decision should be driven by your authentication, security, and management requirements. To help guide this choice, consider the following questions:
- Do you need to enforce Basic Authentication or Integrated Windows Authentication using domain service accounts? If yes, deploying the Edge Transport on a domain-joined server is needed.
- Can you rely on local accounts for authentication (e.g., Basic Authentication without domain dependencies)? If yes, a non-domain-joined server is sufficient.
- Do you need to apply Group Policy Objects (GPOs) or centralized security baselines? If yes, consider a domain-joined deployment to enable centralized management and compliance enforcement.
Note that whether you install Edge on a domain joined machine or not, because you are not creating a subscription to Active Directory, installation of Edge will not require extending the schema and preparing AD for Exchange Server.
Requirements
Once the decision has been made, proceed with the installation of the Exchange Edge Transport role on an up-to-date server. Follow the official prerequisites documentation to prepare the environment. Note that only a limited set of components is required:
- .NET Framework
- Visual C++ 2012 Redistributable
- Active Directory Lightweight Directory Services (AD LDS)
No additional Exchange roles or dependencies are needed.
Network and security:
- TCP port 25 must be permitted between the Edge server and applications or devices that will use Exchange Edge Transport for email relay. Typically, it should not be exposed to internet assuming that these applications or devices are placed within the internal network.
- Outbound TCP port 25 must be permitted between the Edge server and external networks to enable SMTP mail flow.
- Ensure the server is properly hardened, following standard security best practices.
- Refer to this article for Antivirus running on Exchange Server. The “Servers” column can be used to distinguish the necessary exclusions related to Edge Transport.
If high availability is required, consider deploying two standalone Edge Transport servers behind a load balancer, or DNS round-robin. This approach helps minimize service disruption during maintenance activities such as Windows or Exchange patching.
Accepted domain
Since the installation of the Exchange Edge Transport role is relatively straightforward, it will not be covered in this article. At this stage, we assume that the Edge Transport server has already been successfully deployed and is fully operational.
The first step is to configure the Accepted Domains on the Edge Transport server. You can refer to the relevant documentation for the exact command syntax and parameters required.
It is important to note that a standalone Edge Transport role does not have Resolve engines (e.g., no recipient or sender validation against Active Directory or ADAM). Because of this behavior, the distinction between Authoritative and Internal Relay domains does not have a functional impact on the Edge Transport server in this scenario.
Receive connector
Once the Edge Transport is installed, it will automatically create a Receive Connector as described in this article.
To customize the Receive connector to satisfy your needs, you will need to understand how the IIS SMTP was used by your application for email relay. Assuming that your only Accepted Domain is contoso.com:
- If your applications are sending unauthenticated to contoso.com recipients (app1@contoso.com sends to john@contoso.com): Use the default connector, no need to create a new one.
- If your applications are sending authenticated emails through Basic Auth or Integrated Windows using contoso.com as sender SMTP address to any recipient (app1@contoso.com sends to john@contoso.com and adele@fabrikam.com):
- Create a new Receive Connector with ExchangeUsers Permission Group, assign the Authentication mechanism as BasicAuth and/or Integrated and add the IP or range of your applications to RemoteIPRanges:
New-ReceiveConnector -Name "BasicAuth" -AuthMechanism BasicAuth -RemoteIPRanges "192.168.0.1" -PermissionGroups ExchangeUsers -Custom -Bindings 0.0.0.0:25
- And add the permission ms-Exch-SMTP-Accept-Authoritative-Domain-Sender to the connector. As mentioned before, since Edge Transport doesn’t have Resolve engine, it cannot validate the primary SMTP address of the authenticated user, otherwise you will get the “550 5.7.60 SMTP; Client does not have permissions to send as this sender” error.
Get-ReceiveConnector BasicAuth | Add-ADPermission -User "NT AUTHORITY\Authenticated Users" -ExtendedRights "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender"
- If your applications require an open relay, although not recommended, you can follow the steps described in this article.
Send connector
In a fresh Exchange Edge Transport installation, no Send connector is created by default. Therefore, you will need to configure it from scratch.
As highlighted earlier, it is essential to first understand how your existing IIS SMTP server handles outbound relay. This includes determining whether it uses:
- Direct DNS resolution, or a smarthost (and any associated Basic authentication)
- Whether you want to have different routes per domain
This information will directly influence the configuration of your Send connector on the Edge Transport server. You can refer to the relevant documentation for detailed guidance on the required commands and parameters to properly create and configure the Send Connector.
Switch the mail flow
At this stage, the IIS SMTP assessment should already be complete, and you should understand how applications connect to it – a DNS record or a hard-coded IP address.
- If a DNS alias is used (e.g., CNAME or A record):
The transition is typically straightforward. You can redirect mail flow by updating the DNS record to point to the Exchange Edge Transport server. - If applications use a hard-coded IP address:
Consider reusing the existing IIS SMTP IP address. The process is relatively simple:- Disable the network interface (NIC) on the IIS SMTP server
- Assign the IIS SMTP server IP address as a secondary IP on the Exchange Edge Transport server
- Update the existing DNS A record associated with the IIS SMTP server to point to the Exchange Edge Transport server
As a best practice, always validate mail flow with a subset of applications before performing the full cutover. This helps identify potential issues early and ensures a smooth transition.
(Optional) Setting Exchange Online as a smarthost
If you have Exchange Online tenant, you can use your standalone Edge Transport to relay emails through Exchange Online by configuring your tenant MX as a smarthost in the Edge’s Send connector. Although not required, we encourage you to bind a certificate with the same domain name that you have in your Exchange Online as Accepted Domain. This would ensure a proper message attribution process and your emails coming from Edge Transport will be marked as Originating.
- First, you need to figure out what is the MX record of your tenant, please follow this appendix to get this information.
- Add the value to your Send connector as a smarthost
- Import the certificate to the Personal computer container and assign the SMTP service to it
- Bind the certificate to the Send connector
$Cert = Get-ExchangeCertificate -Thumbprint "<new certificate thumbprint>"
$TLSCertificateName = "<i>$($Cert.Issuer)<s>$($Cert.Subject)"
Set-SendConnector -Identity "Send Connector Identity" -TlsCertificateName $TLSCertificateName
- Set the following properties on the connector:
Set-SendConnector -Identity "Send Connector Identity" -RequireTLS $True -TlsAuthLevel DomainValidation -TlsDomain mail.protection.outlook.com
- Now we need to create the Inbound connector in Exchange Online to attribute these messages coming from the Exchange Edge Transport:
New-InboundConnector -Name "FromEdgeTransport" -ConnectorType OnPremises -SenderDomains * -RequireTls $True -TlsSenderCertificateName "Your Certificate CN"
Lastly, ensure to add the EOP and your Edge Transport public IP to the SPF record in the public DNS as described here. This is an important step to avoid either external recipients marking your emails as spoofing or the EOP itself marking emails from your Edge as spoofing. If you want to increase your security posture, you can also enable DKIM and create your DMARC policy for your domains.
FAQ
How to figure out domain or local accounts being used on IIS SMTP to send using Basic Authentication?
Unfortunately, the IIS SMTP logs will not show what account has been used to perform basic authentication when sending emails. The following XML query can be used to filter Security event viewer logs:
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[System[(EventID=4624)]]
and
*[EventData[Data[@Name='LogonType']='3']]
and
*[EventData[Data[@Name='ProcessName']='C:\Windows\System32\inetsrv\inetinfo.exe']]
</Select>
</Query>
</QueryList>
What’s the benefit of getting rid of IIS 6.0 SMTP and moving to an Exchange Edge Transport?
IIS 6.0 is no longer supported, and therefore you should not expect any security updates or assistance from Microsoft Support. From a technical perspective, the Exchange Edge Transport role provides significantly more capabilities and control over mail flow, including:
- Enhanced logs such as message tracking logs and pipeline tracing
- Improved security and control mechanisms
- The ability to implement transport rules (although more limited compared to a full Exchange Mailbox role)
Overall, Exchange Edge Transport represents a more modern, secure, and manageable solution compared to legacy IIS SMTP.
Can we use Address Rewrite feature in a standalone Edge Transport?
Yes, but there are important caveats to consider.
Inbound Address Rewrite is supported and works as expected on a standalone Edge Transport. You can safely follow the standard procedure described in the documentation to implement it.
The Outbound Address Rewrite has some limitations that you should be aware of. This feature depends on the Address Rewriting Outbound Agent, which is only triggered when the MAIL FROM is treated as authenticated. Specifically, the agent relies on the presence of the header: X-MS-Exchange-Organization-AuthAs: Internal.
At first glance, you might assume that using Basic Authentication or Integrated Windows Authentication would satisfy this requirement. However, this is not the case for a standalone Edge Transport deployment. Regardless of the authentication method used when submitting messages to a standalone Edge Transport, the header X-MS-Exchange-Organization-AuthAs is always stamped as Anonymous.
As a result, the Outbound Address Rewrite agent is never triggered under normal conditions.
The only supported workaround to force the standalone Edge Transport to treat messages as internal – and therefore enable outbound address rewriting – is to configure the receive connector with the ExternalAuthoritative authentication mechanism. This effectively promotes the AuthAs value to Internal.
Enabling ExternalAuthoritative effectively turns the receive connector into an open relay. You must therefore implement appropriate restrictions (such as IP scoping and strict access controls) to secure the connector and prevent abuse. Refer to this article for further information.
How does Microsoft 365 IP throttling deal with messages coming from a standalone Edge Transport?
In the same way as it handles in Hybrid mail flow if you followed our recommendation stated on “Setting Exchange Online as smarthost” section. If you had a Hybrid Exchange on-premises and are moving to a standalone Edge Transport, our advice is to keep the same public IP used by your previous Exchange Server on the new Edge Transport since this IP will have a sending history and clean reputation.
Can we deploy a standalone Edge Transport as an Azure VM?
You can but consider that outbound SMTP on Azure VMs is only supported if you have Enterprise Agreement or Microsoft Customer Agreement for enterprise (MCA-E) subscriptions. For more information see this article. Additionally, you may need to establish proper network connectivity from your applications to the Azure VM. This typically requires configuring network routing – such as Azure ExpressRoute – to enable your on-premises traffic to reach the Edge Transport VM securely and reliably.
Edge Transport is configured to use Exchange Online as smarthost but emails are being received as “AuthAs:Anonymous”. Can we change this behavior marking messages as Internal?
The Edge Transport role does not perform header promotion regardless if Edge is subscribed to a Mailbox Exchange Server or standalone. It is up to the Mailbox role to promote Organization headers to CrossPremises and then the Edge just honors the promotion. Refer to this article to find more information about header promotion. The only way to enforce “AuthAs:Internal” on messages coming from an Edge Transport is enabling TreatMessagesAsInternal attribute on Exchange Online Inbound connector. This option works only if sender domain matches an accepted domain in Exchange Online.
Thanks to Arindam Thokder for his support and review of this article.
Denis Vilaça Signorelli
Cloud Solution Architect
