SMTP Relay on Windows Server 2025: Setup Options, Security, and Testing

SMTP relay Windows Server 2025 setups look different from older Windows Server guides because the built-in SMTP Server feature is no longer available. The practical goal is still straightforward: let an application, device, or scheduled task send mail through a trusted service without turning your Windows server into an open relay.

This guide explains what changed, which architecture to choose, how to configure a real Microsoft 365 relay example, how to test it, and how to avoid the deliverability and security failures that make mail relays troublesome. It is aimed at administrators sending transactional mail: alerts, reports, password resets, scanner output, monitoring notifications, and application messages.

What changed in Windows Server 2025

Older Windows Server tutorials commonly begin with Server Manager, Add Roles and Features, and the SMTP Server feature. That guidance applies to older Windows releases that contained the legacy IIS 6 SMTP service. It does not apply to Windows Server 2025.

Microsoft lists SMTP Server among the features removed from Windows Server 2025. As a result, you cannot install the legacy Microsoft SMTP virtual server on a clean Windows Server 2025 installation through Server Manager, DISM, or PowerShell. If an article tells you to install SMTP-Server, it is either written for an earlier server release or assumes a server upgraded from an earlier environment.

That removal is important for more than installation convenience. The old service was designed in a different operational era. It lacked the modern authentication, auditability, reputation tooling, hosted redundancy, and policy controls expected of an internet-facing mail delivery system. Running a public-facing SMTP listener on a general-purpose Windows server also creates a high-value target for password attacks, relay abuse, and service misconfiguration.

For Windows Server 2025, separate the two jobs that people often call “SMTP relay”:

• SMTP client: Your Windows application or device connects outward to a relay host and submits a message. This is the usual and preferred pattern.
• SMTP relay server: A server accepts SMTP connections from other systems, then forwards messages onward. This is useful only when you have multiple internal clients that need one local endpoint, and should normally be supplied by a supported mail gateway or service.

In most cases, Windows Server 2025 should be the SMTP client. Microsoft 365, a transactional email provider, an existing Exchange environment, or a dedicated mail gateway should do the relay and delivery work.

Choose the right SMTP relay architecture

The correct configuration depends on who sends mail, which recipients receive it, whether the sender has a mailbox, and whether a static public IP address is available. Do not choose a method just because it uses port 25 or because an old script happens to support it.

Option 1: Microsoft 365 SMTP client submission

SMTP client submission is appropriate when the application can authenticate as a real Microsoft 365 mailbox. The client connects to smtp.office365.com on TCP port 587 and negotiates STARTTLS. The sender is typically the authenticated mailbox, or an address it has Send As permission to use.

Use this option for an application that can support modern authentication and has a specific service mailbox, such as alerts@contoso.com. Microsoft documents SMTP AUTH settings at both the organization and mailbox level. Whether SMTP AUTH is available also depends on tenant security settings and authentication policy, so verify rather than assuming a username-and-password script will work.

The key advantages are no dependency on a fixed public IP address and a familiar authenticated submission model. The trade-off is that older printers, monitoring appliances, and legacy applications often cannot use OAuth or modern authentication safely. Basic authentication should not be treated as a future-proof integration choice.

Option 2: Microsoft 365 SMTP relay through an inbound connector

Microsoft 365 SMTP relay is commonly the best fit for servers, appliances, and line-of-business applications that need to send as an accepted domain but cannot authenticate as a mailbox. The application connects to your Microsoft 365 Protection endpoint, usually in the form:

<your-domain-with-dashes>.mail.protection.outlook.com

It submits mail on TCP port 25. Exchange Online identifies the sender through an inbound connector that trusts either the sending server’s static public IP address or a TLS certificate name. The message sender must use an accepted domain in your Microsoft 365 tenant, such as alerts@contoso.com.

This method can send to internal and external recipients when correctly configured. It is not the same as Direct Send. It requires a connector and a controlled, stable identity for the sending system.

Option 3: Microsoft 365 Direct Send

Direct Send also uses your Microsoft 365 MX endpoint and port 25, but it does not use a connector. It is intended for messages to recipients inside your Microsoft 365 organization. It cannot deliver to arbitrary external recipients, and Microsoft’s documentation notes that messages can be subject to anti-spam checks.

Direct Send can fit a copier that only emails internal staff. It is a poor default for applications that send customers, suppliers, password-reset messages, or internet notifications. Do not confuse “the test email reached an employee” with a relay design that can send externally.

Option 4: Transactional email provider or SMTP gateway

A specialist provider can be the simplest option for application-generated mail, especially when mail is external-facing or volume matters. Examples include Amazon SES, Postmark, Mailgun, SendGrid, and Mailjet. Their exact ports, credentials, TLS requirements, regional endpoints, and sending limits are vendor-specific, so follow the provider’s current documentation rather than copying an endpoint from a generic tutorial.

These services generally offer SMTP credentials and often an HTTP API. An API is frequently preferable for new applications because it can provide structured status responses, event webhooks, templates, suppression handling, and scoped API keys. SMTP remains useful when the application only supports SMTP or replacing its mail subsystem is impractical.

Option 5: A dedicated internal relay or mail gateway

If dozens or hundreds of internal systems need one relay address, deploy a supported, intentionally managed relay product rather than trying to resurrect the Windows SMTP service. This can be an email-security gateway, a commercial Windows mail server, or a hardened Postfix-based relay on Linux. The right product depends on your support requirements, identity model, logging needs, and compliance controls.

A dedicated relay is justified when you need central allowlists, queue management, per-device controls, a local submission endpoint, or a single outbound egress IP. It is not justified merely because one application can only speak SMTP; that application can usually connect directly to a hosted relay.

Decision table: which method should you use?

Use this short comparison before configuring anything:

For most organizations, the decision is between Microsoft 365 SMTP relay and a transactional provider. Choose Microsoft 365 relay when messages are operational business mail from a Microsoft 365 accepted domain and you control a static outbound IP. Choose a transactional provider when application mail is a product feature, needs delivery events, or must work from changing cloud IP addresses.

Prerequisites for a secure Windows Server 2025 SMTP relay

Before changing Exchange settings or application code, collect the exact facts that determine whether the design can work. Missing one of these is a common reason for an apparently successful setup that later fails in production.

Network and identity checklist

For Microsoft 365 SMTP relay, confirm all of the following:

1. The Windows Server 2025 host has a known public egress IP address. If it sits behind NAT, this is the NAT gateway’s public IP, not its private 10.x.x.x, 172.16-31.x.x, or 192.168.x.x address.
2. The public egress IP is stable. A connector allowlisting a changing ISP address will fail as soon as it changes.
3. Your hosting company, ISP, firewall, and network security policy allow outbound TCP 25. Many cloud platforms restrict port 25 by default to reduce spam.
4. You know the Microsoft 365 MX endpoint for the sender domain. Find it in the Microsoft 365 admin center domain settings or with a DNS MX lookup; do not guess it from another tenant.
5. The envelope sender and visible From address use a domain that Microsoft 365 has accepted and verified, for example contoso.com.
6. The sender identity is allowed by the connector configuration and any tenant mail-flow rules.
7. DNS authentication records are correctly published for the domain.

For client submission through smtp.office365.com:587, replace the fixed-IP and port-25 requirements with a properly secured service identity. Confirm the mailbox, organization policy, app authentication method, and TLS support. Do not store a human administrator’s password in an application configuration file.

DNS records that affect delivery

An SMTP relay configuration answers “may this system submit mail?” DNS authentication answers “should recipients trust mail claiming to be from this domain?” They are separate controls.

At minimum, maintain:

• SPF: Authorizes the actual sending service. If Microsoft 365 is the only sender, the common baseline is v=spf1 include:spf.protection.outlook.com -all. If you also use a transactional provider, its documented authorization must be incorporated without creating multiple SPF TXT records.
• DKIM: Cryptographically signs messages. Enable it in the sending platform and publish the provider-specific CNAME records it supplies. Microsoft 365 DKIM configuration is tenant-specific.
• DMARC: States how receivers should handle messages that fail aligned SPF and DKIM checks and supplies reporting addresses. Start with monitoring if needed, then move deliberately toward enforcement after reviewing reports.

SPF has a limit of ten DNS-mechanism lookups during evaluation. That is one reason blindly appending include: mechanisms for every vendor is dangerous. Use a domain-authentication plan rather than treating a relay connector as a complete deliverability solution.

Worked example: relay a Windows Server application through Microsoft 365

This example uses a fictional domain, contoso.com, and a Windows Server 2025 application named InventoryReporter. The application must send a nightly stock report to both ops@contoso.com and supplier@example.net. The organization uses Microsoft 365 and has a fixed public egress IP address of 198.51.100.25 in this documentation example.

Because messages go to an external supplier and the application cannot use modern mailbox authentication, Microsoft 365 SMTP relay through a connector is the appropriate design.

Step 1: identify the Microsoft 365 MX endpoint

Find the MX record for contoso.com. In a real tenant it might look similar to:

contoso-com.mail.protection.outlook.com

Use the endpoint assigned to your domain, not the generic submission host and not an IP address copied from a DNS response. Microsoft can change service IPs; using the MX hostname preserves correct routing.

From the Windows server, confirm it resolves:

Resolve-DnsName contoso.com -Type MX
Resolve-DnsName contoso-com.mail.protection.outlook.com

The second command is not a mail-delivery test. It only confirms DNS resolution.

Step 2: create the inbound connector in Exchange admin center

In the Exchange admin center, create an inbound connector. The labels and navigation can change over time, but the intended settings are:

• Connection from: Your organization’s email server.
• Connection to: Microsoft 365.
• How to identify the partner: The sending server’s public IP address, 198.51.100.25, in this example; alternatively, identify it by a TLS certificate name if that is the chosen design.
• Security restrictions: Apply the TLS requirements that match your connector design and Microsoft’s current relay guidance.

The connector’s purpose is narrow: it tells Exchange Online that mail arriving from the defined source is permitted to relay as your accepted domain. Do not make it broadly trust every source or every sender address. If your setup contains multiple NAT gateways, list only the specific outbound addresses used by the approved systems.

Save the connector and allow configuration changes to propagate. If you manage Exchange Online with PowerShell, use the currently documented Exchange Online cmdlets and inspect the resulting connector rather than relying on old, copied commands. Admin-center configuration is less error-prone for a one-server setup.

Step 3: configure the application SMTP values

In InventoryReporter, configure these conceptual settings:

SMTP host: contoso-com.mail.protection.outlook.com
SMTP port: 25
Encryption: STARTTLS when offered/required by your connector policy
Username: none
Password: none
From address: alerts@contoso.com
To address: ops@contoso.com

The relay model is IP or certificate authenticated, not username-and-password authenticated. Adding a Microsoft 365 user name and password here does not improve security and can cause confusing failures if the application changes authentication behavior.

The application must submit a sender in an accepted domain. alerts@contoso.com is valid if contoso.com is accepted in the tenant. alerts@contoso-mail.example is not valid merely because the Windows server owns that hostname.

For an application that needs a code example, use a maintained SMTP library and make TLS behavior explicit. In .NET, MailKit is a widely used third-party library. The following simplified C# example illustrates the connection shape; store addresses and endpoints in protected configuration, not source code:

using MailKit.Net.Smtp;
using MailKit.Security;
using MimeKit;

var message = new MimeMessage();
message.From.Add(MailboxAddress.Parse("alerts@contoso.com"));
message.To.Add(MailboxAddress.Parse("ops@contoso.com"));
message.Subject = "Inventory report";
message.Body = new TextPart("plain") { Text = "Nightly report attached or generated." };

using var client = new SmtpClient();
client.Connect("contoso-com.mail.protection.outlook.com", 25, SecureSocketOptions.StartTlsWhenAvailable);
client.Send(message);
client.Disconnect(true);

Whether StartTlsWhenAvailable is sufficient depends on the connector’s TLS requirement and your security policy. If you require TLS, configure both sides to require it and fail closed rather than silently sending cleartext SMTP. The exact MailKit API can vary by library version, so validate against the version you deploy.

Step 4: test connectivity before testing the application

On Windows Server 2025, test whether the network can reach the endpoint on TCP port 25:

Test-NetConnection contoso-com.mail.protection.outlook.com -Port 25

A TcpTestSucceeded : True result proves a TCP connection can be established. It does not prove that Microsoft 365 trusts the source IP, accepts the sender, or delivers a message.

Next, send one uniquely identifiable application test message, such as a subject line containing InventoryRelayTest-2025-001. Send it to one internal and one external address. Avoid using a production distribution list during testing.

Step 5: verify the message path

Use Exchange message trace to search for the unique subject, sender, and recipient. A successful result should show that Exchange Online received the message, processed it, and delivered it or handed it to the destination’s mail system. For external messages, “sent” from Microsoft 365 does not guarantee the remote mailbox displayed it in the inbox; the recipient domain may still filter or quarantine it.

Inspect the received message headers at the destination. Look for the Authentication-Results header and check SPF, DKIM, and DMARC alignment. The exact header layout differs by receiving system, but a good outcome generally shows passing authentication for contoso.com and expected Microsoft 365 routing.

That combination—application log success, connector acceptance, message trace, and received headers—is the evidence that the relay works. A green TCP test alone is not.

How to configure client submission instead

If your application supports Microsoft 365 client submission and has an appropriate service mailbox, use the documented Microsoft 365 client submission settings:

Host: smtp.office365.com
Port: 587
Transport security: STARTTLS
Authentication: supported Microsoft 365 authentication method

Create a dedicated mailbox or appropriately licensed service identity where required by your licensing and tenant policies. Give it a meaningful name, limit administrative permissions, protect its credentials or tokens in a secret manager, and document the ownership and rotation procedure.

The recipient scope differs from Direct Send: authenticated client submission can send to internal and external recipients. The sending address must match the mailbox or be an address for which it has the needed Send As rights.

Do not use the old PowerShell Send-MailMessage cmdlet as a long-term validation or production integration approach. Microsoft marks it obsolete and recommends alternatives. It does not solve OAuth requirements and encourages password-centric designs. Test with the actual application, a supported SMTP library, or a vendor-supported integration.

Security controls that prevent open relay and abuse

The most dangerous SMTP mistake is an open relay: a service that accepts unauthenticated mail from untrusted networks and forwards it to arbitrary destinations. Spammers actively scan for it. Your public IP can be blocklisted, your mail service can be suspended, and incident response can become much more expensive than the original configuration work.

Windows Server 2025 reduces the risk by not providing the old SMTP server role, but a bad connector, an overbroad gateway rule, or exposed third-party relay can recreate the same problem.

Apply least privilege to every layer

Use these controls together:

• Allow only known source IP addresses or a verified client certificate on an SMTP relay connector.
• Restrict accepted sender domains and avoid allowing arbitrary envelope senders.
• Require TLS where the service and client support it; validate certificates instead of disabling certificate checks to “make it work.”
• Use a service account, scoped SMTP credential, or provider-specific API key—not a global administrator account.
• Store secrets in a managed secret store, protected application configuration, or an equivalent platform control; never in a batch file, source repository, or ticket comment.
• Limit outbound firewall access to the relay hostname or resolved, documented service destination where your firewall supports that model.
• Patch the Windows host, application runtime, SMTP library, and any self-hosted gateway.
• Log submitter, sender, recipients, response codes, message IDs, and failures, while protecting message contents and personal data appropriately.

If you run a local relay gateway, its listener should normally be reachable only from defined internal subnets or authenticated clients. Do not publish port 25 inbound to the internet “so the server can send email.” Outbound submission does not require an inbound internet SMTP listener.

Protect against spoofing and phishing misuse

A permitted relay source can still be abused if malware compromises the Windows host. Treat unusual volume, unexpected recipient domains, new sender addresses, and abnormal times of day as security signals. Alerting on failed authentication alone is insufficient; successful but anomalous submission is often more meaningful.

Microsoft and security vendors have documented phishing campaigns that exploit mail-routing assumptions and misconfigurations. Domain authentication, strict connector scoping, and message trace review help, but they do not replace endpoint security on the server that creates the mail.

Troubleshooting SMTP relay failures on Windows Server 2025

Troubleshooting is faster when you identify the layer at fault: DNS, network, TLS, connector identity, sender authorization, application behavior, or recipient filtering. Do not change several settings at once; it destroys the evidence needed to find the cause.

Port 25 timeout or connection refused

If Test-NetConnection fails, start with routing and egress policy. Check the Windows Defender Firewall outbound rules, perimeter firewall, NAT configuration, and the provider’s restrictions. Major cloud providers may block or throttle outbound TCP 25; their approved workaround may be a request to remove the restriction, port 587 with authenticated submission, or a provider-specific relay service.

A successful connection followed by an SMTP rejection is different. It means the network path exists and configuration—not firewall reachability—is the next place to look.

“Unable to relay” or sender rejected

This normally means Exchange Online did not match your source to the connector, the connector is not enabled, the public IP is wrong, or the sender domain is not accepted. Verify the egress IP from the actual Windows server path. Do not rely on what you believe the firewall uses; confirm it with your network team or a controlled external IP-check method.

Also compare the application’s envelope sender with its visible From header. Some applications use a separate return-path setting and may submit server@hostname.local even when the display From field says alerts@contoso.com. A .local or unverified domain will not satisfy an accepted-domain relay policy.

TLS handshake or certificate failures

Check that the server clock is accurate, the Windows certificate trust store is healthy, and no TLS-inspection device is presenting an untrusted certificate. Update the SMTP client library if it cannot negotiate modern TLS. Never permanently set a client to ignore certificate validation; that turns a configuration issue into a credential and message-interception risk.

With Microsoft 365 connector relay, ensure the connector’s TLS settings match the capability of the actual submitting application. If you identify the connector by certificate, the certificate name, issuance, private-key availability, and TLS presentation all matter.

Accepted by relay but missing at recipient

Use message trace first. If trace shows a delivery event to an external domain, obtain the final SMTP response and inspect the recipient system’s quarantine, junk, or filtering logs where available. A message can be technically accepted yet filtered because of domain reputation, missing DMARC alignment, suspicious content, a malformed message, or recipient-side policy.

For transactional providers, consult delivery events, suppression lists, bounce classifications, and webhook records. A hard bounce should not be repeatedly retried indefinitely. Repeated retries harm reputation and create unnecessary operational load.

Application says success but no trace exists

Inspect the application’s actual SMTP host, port, From address, and environment-specific configuration. It may be sending to a local development mail catcher, an old relay hostname, or a different tenant endpoint. Capture the SMTP response code in application logs, with credential and message-content redaction.

Operating a relay reliably after go-live

SMTP relay is not a one-time checkbox. Treat it as a small production integration with ownership, monitoring, and periodic review.

Create a runbook that records the relay host, port, sender domains, connector name, source egress IPs, owning team, authentication method, DNS records, alert thresholds, and test procedure. Include what must happen when the public IP changes, a domain is added, an application is migrated, or a service credential is rotated.

Monitor at least these outcomes:

• Submission attempts and success/failure rates by application.
• SMTP response codes and TLS failures.
• Message-trace rejections and connector mismatches.
• Bounces, complaints, suppressions, and unexpected recipient destinations.
• SPF, DKIM, and DMARC authentication results for representative external deliveries.
• Volume anomalies that might indicate a compromised server or runaway job.

Use a synthetic mail test sparingly and responsibly. A scheduled test message to a monitored mailbox can detect a broken connector, but it should have a unique subject and a clear owner. It should not become an uncontrolled stream of automated messages or a substitute for reviewing delivery telemetry.

For high-impact systems such as password-reset, invoicing, or security alerting workflows, plan a fallback. That may mean queueing messages in the application database, switching to a secondary provider after controlled failure criteria, or raising an operational incident rather than silently dropping mail. A fallback must preserve idempotency so recipients do not receive duplicate invoices or reset links.

Migration guidance for legacy IIS SMTP deployments

If you still operate the IIS SMTP service on Windows Server 2016, 2019, or 2022, do not attempt an in-place copy of its configuration onto Windows Server 2025. There is no corresponding Windows Server 2025 SMTP Server feature to receive it.

Inventory the legacy relay before migrating. Identify every client IP, application name, sender address, recipient scope, authentication rule, smart host, queue location, retry policy, and firewall rule. Legacy SMTP relays often serve forgotten copiers, backup software, and monitoring systems; turning one off without inventory creates delayed failures.

Then choose a destination per client category. Modern applications can use a provider API or authenticated submission. Devices that only support basic SMTP may use a controlled connector relay or a dedicated internal gateway. Systems that cannot support TLS may need replacement, an isolated gateway with compensating controls, or a vendor update; accepting unencrypted internet SMTP merely to preserve an old device is rarely a sound long-term decision.

Run parallel testing with a small set of clients, verify external delivery and authentication headers, then migrate in batches. Keep the old relay available only for a defined rollback window, monitor its queue and logs, and remove allowlists once clients have moved. An indefinite “temporary” legacy relay becomes an unmanaged security dependency.

Conclusion: the safest path for SMTP relay Windows Server 2025

The best SMTP relay Windows Server 2025 design does not try to reinstall a retired Windows component. Make Windows Server 2025 an authenticated or explicitly trusted SMTP client, and use Microsoft 365, a transactional mail provider, or a dedicated gateway as the supported relay.

For a Microsoft 365 organization with a stable egress IP, an inbound connector plus the tenant MX endpoint on port 25 is a practical choice for servers and devices that need external delivery. For modern applications with a service mailbox, authenticated submission on smtp.office365.com:587 can fit. For product and high-volume mail, a transactional provider or API often provides better visibility and deliverability controls.

Whichever route you choose, define a narrow trust boundary, use TLS, authenticate your sending domain, test the whole delivery path, and monitor the system after it passes its first test.

FAQ

Can I install the IIS SMTP Server feature on Windows Server 2025?

No. Microsoft lists SMTP Server as removed from Windows Server 2025. Use an external relay service, Microsoft 365 connector relay, authenticated submission, or a dedicated supported mail gateway instead.

What port should Windows Server 2025 use for SMTP relay?

Microsoft 365 SMTP relay through an inbound connector uses port 25 to your tenant’s Microsoft 365 MX endpoint. Authenticated Microsoft 365 client submission uses smtp.office365.com on port 587 with STARTTLS. A transactional provider’s supported port depends on that provider.

Can Microsoft 365 SMTP relay send to external recipients?

Yes, Microsoft 365 SMTP relay through a properly configured inbound connector can send externally. Direct Send is different: it is intended for recipients within your Microsoft 365 organization and is not an external-relay replacement.

Do I need a static public IP for Microsoft 365 SMTP relay?

Usually, yes, when the connector identifies your sending server by IP address. Microsoft also supports connector identification using a TLS certificate name in applicable designs. Client submission on port 587 does not rely on a static IP in the same way because it authenticates the client identity.

How do I know my SMTP relay is working correctly?

Confirm TCP connectivity, send a uniquely identified test to an internal and external recipient, review Exchange message trace or provider events, and inspect received headers for SPF, DKIM, and DMARC results. Successful application submission alone is not complete proof of delivery.