Immediate answer
Server 2025 needs a planned SMTP replacement.
The IIS 6-era SMTP Server feature is listed as removed from Windows Server 2025. Microsoft’s current removal notice says there is no replacement in the operating system and points administrators toward Exchange Server or a non-Microsoft SMTP server.
This removal statement is specific to Windows Server 2025. It does not mean the feature was retroactively removed from Windows Server 2022. Inventory each host and plan within the support lifecycle of the version you actually run.
A replacement does not have to mimic the old server exactly. Start by deciding whether each sender can be modernized, whether mail must reach external recipients, and whether you still need local queueing when Microsoft 365 is temporarily unavailable.
The dependency
Why IIS SMTP stayed in so many environments.
Organizations commonly used the Windows SMTP service as a local compatibility layer. Printers, line-of-business applications, scheduled scripts, monitoring systems, and appliances submitted ordinary SMTP to a nearby Windows host. That host centralized outbound routing and sometimes absorbed short outages in its queue.
The feature’s removal changes the server upgrade plan, not the protocols spoken by those clients. A printer still unable to perform OAuth will not become modern merely because its relay host moves. Likewise, replacing the host with a raw forwarder does not settle identity, recipient scope, TLS, abuse controls, or retry behavior.
Read-only diagnostics
Inventory the role, service, and clients before migrating.
On each candidate server, these read-only PowerShell commands show whether the feature is available or installed and whether the SMTP service exists. Run them from an elevated PowerShell session where Server Manager cmdlets are available.
Get-WindowsFeature -Name SMTP-Server
Get-Service -Name SMTPSVC -ErrorAction SilentlyContinueFeature presence is only the start. Record the current smart host, accepted source networks, sender domains, external-recipient requirement, message size, daily volume, peak burst, retry expectations, and every client IP. Review firewall or flow logs rather than trusting an old spreadsheet.
- 01
Find every submitter
Include multifunction devices, applications, task-scheduler jobs, monitoring platforms, storage systems, UPS cards, and forgotten test systems.
- 02
Classify each mail path
Note whether it sends internally only or externally, needs a recognizable mailbox identity, and can be changed to OAuth or an API.
- 03
Capture operational behavior
Measure bursts and determine what happens during an upstream outage. A replacement without durable retry may be a functional regression.
Neutral alternatives
Choose a successor by capability, not resemblance.
Native OAuth in the device or application
Prefer a vendor-supported Microsoft 365 OAuth integration when the exact product and version provide one. It removes the compatibility relay from that sender’s path.
Microsoft Graph or an application API
For software you can rewrite, Graph sendMail or an appropriate service API can provide a modern application integration. Graph is not SMTP and is not a drop-in change for appliances.
Exchange Online mail-flow options
Authenticated client submission, SMTP relay through a connector, Direct Send, and High Volume Email have different identity, recipient, network, and volume boundaries. Use the Microsoft 365 SMTP options comparison to screen them.
Exchange Edge Transport
Microsoft's May 2026 guidance describes a standalone Exchange Edge Transport server as a supported Microsoft option for centralizing relay from applications, fax systems, and printers while retiring IIS SMTP. It carries Exchange licensing, servicing, certificate, connector, and mail-server operations responsibilities.
Postfix or another local MTA
An organization already comfortable operating a mail transfer agent can build a controlled local relay. That also means owning configuration, authorization, patching, queue monitoring, and upstream compatibility.
SaaS SMTP relay
A managed relay can reduce local operations and may suit transactional mail. Review data path, privacy, sender-domain controls, availability, cost, and vendor lock-in.
A purpose-built local SMTP bridge
A local bridge is useful when the old clients must retain SMTP but the Microsoft-facing connection needs modern authentication and managed retry behavior.
Decision matrix
Match the option to the constraint.
| Situation | Strong starting point | Important boundary |
|---|---|---|
| Rewriteable application | Graph, application API, or a current SMTP library with OAuth | Requires engineering and application identity design |
| Modern device | Vendor-native Microsoft OAuth | Verify the exact model, firmware, and tenant requirements |
| Microsoft-supported centralized relay server | Standalone Exchange Edge Transport | Requires Exchange licensing, lifecycle management, connectors, certificates, and mail-server expertise |
| Existing mail team | Supported Exchange path or administered local MTA | Operations and queue ownership stay with your team |
| Many Windows-local legacy clients | Purpose-built local compatibility bridge | Must not become an unrestricted relay |
| Cloud-managed preference | SaaS relay | Mail traverses another provider and cost scales by service |
Product fit
Where RelayBridge fits—and where it does not.
RelayBridge is designed for legacy clients that can reach a local Windows service but cannot authenticate to Exchange Online themselves. It accepts explicitly authorized local SMTP, persists messages in a durable local queue, and uses Exchange Online SMTP OAuth for Microsoft-facing delivery. It is not a RelayBridge-operated cloud mail relay.
The RelayBridge-owned application source is publicly reviewable under MPL-2.0. RelayBridge is independent: it is not a Microsoft product, endorsement, certification, or official Server 2025 replacement. Review the architecture and current Microsoft 365 security model before considering it.
Do not add RelayBridge when native vendor OAuth works, an application can cleanly move to Graph or an API, your organization already operates a suitable MTA, or another supported Microsoft mail-flow model fits better.
Migration checklist
Move the dependency without creating a relay risk.
- 01
Freeze an evidence-based inventory
Record client owners, source addresses, mail identity, recipient scope, volume, burst, message size, and outage tolerance.
- 02
Select per-client paths
Modernize capable applications and devices first. Do not force every sender through one replacement merely for architectural symmetry.
- 03
Design least-privilege intake
Restrict listeners by interface, firewall, allowlist, sender policy, and destination. Never reproduce an open or broadly reachable relay.
- 04
Test normal and failure behavior
Exercise internal and external recipients, attachments, peak bursts, Microsoft throttling, network interruption, restart, and persisted retry.
- 05
Cut over in observable groups
Migrate owners in batches, monitor both queues, retain a rollback window, then retire the legacy service only after silent clients are accounted for.
Authoritative sources
References.
- Microsoft Learn: Features removed or no longer developed starting with Windows Server 2025
- Microsoft Exchange Team: Replacing IIS SMTP virtual server with Exchange Edge Transport
- Microsoft Learn: Get-WindowsFeature
- Microsoft Learn: How to set up a multifunction device or application to send email using Microsoft 365
- Postfix official documentation: Basic configuration