SMTP Relay O365: Configure Microsoft 365 Relay the Right Way

SMTP relay O365 usually means one thing: you need a printer, monitoring system, server, or legacy application to send mail through Microsoft 365 without storing a mailbox password in that device. The correct setup is connector-based SMTP relay—not smtp.office365.com with a username and password—and it depends on your public IP address or a TLS certificate.

What SMTP relay O365 actually is

Microsoft 365 offers several ways for devices and applications to send mail. The terms are often used interchangeably, but the host name, port, authentication method, and delivery scope differ. Choosing the wrong method is the most common reason a scanner can email internal users but not customers, or why a supposedly configured relay returns “relay access denied.” (learn.microsoft.com)

Microsoft 365 SMTP relay is Exchange Online mail flow for a device or application that acts like an email server. Your system connects to your tenant’s Microsoft 365 Protection MX endpoint over TCP port 25. Exchange Online accepts that connection because it matches an inbound connector you configured using the sender’s static public IP address or a TLS certificate. It can then relay the message to recipients inside and outside your organization. (learn.microsoft.com)

This is different from SMTP AUTH client submission. SMTP AUTH normally uses smtp.office365.com, port 587, a mailbox identity, and either OAuth or—where still available for the application—basic username/password authentication. It is a mailbox-submission method, not connector-based relay. (learn.microsoft.com)

For most organizations, SMTP relay O365 is appropriate when all of the following are true:

• The sender is on a network you control, such as an office, data center, warehouse, or branch site.
• Its outbound traffic has a stable, dedicated public IPv4 address, or the sender can present a suitable TLS certificate.
• It must send alerts, scan-to-email messages, reports, or transactional notices to external recipients as well as internal users.
• The device cannot safely or reliably use OAuth-based SMTP AUTH.
• You want to avoid embedding a licensed mailbox’s password in a printer, appliance, or old application. (learn.microsoft.com)

The model is simple: Microsoft 365 trusts the connection source, not an SMTP username. That makes the IP address, connector scope, envelope sender, DNS authentication, and network controls central to a secure design.

SMTP relay vs SMTP AUTH vs Direct Send

Before changing any settings, identify the result you need. A configuration can be technically valid and still be the wrong architecture.

Microsoft documents SMTP relay as connector-authenticated and Direct Send as unauthenticated. Direct Send can deliver to recipients in your own Microsoft 365 accepted domains, but it cannot relay onward to internet recipients; SMTP relay can do both. (learn.microsoft.com)

Use SMTP relay when external delivery matters

A copier that scans invoices to customers, an ERP platform that sends purchase orders, or a monitoring server that emails an external managed-service provider all need SMTP relay if they must use Exchange Online for delivery. Direct Send is insufficient because Microsoft 365 will not use it as an open relay for external destinations. (learn.microsoft.com)

Use SMTP AUTH only when the application supports modern authentication

SMTP AUTH is usually more practical for a cloud-hosted app because it does not depend on a fixed on-premises public IP. But it requires a mailbox or appropriately authorized application identity and an OAuth-capable implementation for a durable setup. Exchange Online supports OAuth for SMTP AUTH, using the https://outlook.office.com/SMTP.Send delegated scope in applicable user-delegated flows. (learn.microsoft.com)

Do not confuse the retirement of Basic Authentication across Exchange Online protocols with connector-based SMTP relay. Connector-based relay does not authenticate by SMTP username/password in the first place. The concern is different: whether the connector’s source IP/certificate and envelope-sender domain meet Exchange Online’s relay requirements. (learn.microsoft.com)

Use Direct Send only for internal mail

If a device sends only to employees whose mailboxes are in your tenant—for example, a building alarm that emails facilities@yourdomain.com—Direct Send may be simpler. It uses the same family of MX endpoint names as relay, but you do not create the connector and it cannot send to external destinations. (learn.microsoft.com)

Requirements for Microsoft 365 SMTP relay

SMTP relay is deliberately stricter than anonymous internet mail because Exchange Online needs a trustworthy way to identify an allowed sender. Collect the following before opening the Exchange admin center.

1. A static public IP address or TLS certificate

For the common IP-based design, you need the public egress IP address Microsoft 365 will see—not the device’s 192.168.x.x, 10.x.x.x, or other private LAN address. It must be static and not shared with another organization. A firewall or NAT gateway often owns that address, so ask the network team for the actual outbound public IP. (learn.microsoft.com)

A certificate-based connector is an alternative for a mail server that can present a certificate during SMTP TLS negotiation. The certificate subject or subject alternative name must include an accepted domain in Microsoft 365. For ordinary printers and appliances, IP-based authentication is usually the practical route because many cannot present and manage the required certificate. (learn.microsoft.com)

2. An accepted sender domain

The domain used for relay must be an accepted domain in your Microsoft 365 tenant. More specifically, Exchange Online evaluates the SMTP envelope sender—the address supplied in the MAIL FROM: command, also called the P1 or 5321.MailFrom sender—not merely the friendly From address people see in their mail client. (learn.microsoft.com)

This distinction matters for applications that generate bounces or use a separate return-path domain. A visible header such as From: Alerts <alerts@contoso.com> does not repair a relay configuration if the application actually transmits MAIL FROM:<bounce@vendor-example.net> and that envelope domain is not accepted in your tenant. Exchange Online changed its relay conditions on November 1, 2023: matching the visible From domain is no longer one of the accepted-domain conditions. (learn.microsoft.com)

3. Outbound TCP port 25

Connector-based Microsoft 365 SMTP relay requires TCP port 25. Your device, local SMTP server, firewall, ISP, and hosting environment must allow the outbound connection to your MX endpoint. Port 587 is for SMTP AUTH client submission, not Microsoft 365’s IP/certificate connector relay pattern. (learn.microsoft.com)

This requirement creates a practical limitation: some ISPs and cloud environments restrict outbound port 25 to reduce abuse. Do not spend hours changing Exchange settings if your network cannot establish a TCP connection to port 25. First prove reachability from the actual sending network.

4. Your tenant MX endpoint

The relay smart host is your Microsoft 365 MX record target, typically in this form:

contoso-com.mail.protection.outlook.com

The exact host is tenant- and domain-specific. Retrieve it from the Microsoft 365 admin center’s domain DNS details or query the MX record for the accepted domain you will use. Do not substitute smtp.office365.com; that host belongs to SMTP AUTH client submission. (learn.microsoft.com)

5. A clear sender policy

A connector that allows any application behind a public NAT to submit arbitrary mail is risky. Decide in advance which systems will use the relay, which domains they can send from, who owns them, and which alert address receives delivery failures. If multiple unrelated systems share a NAT address, consider placing a local relay server between them and Exchange Online so you can apply authentication, rate limits, logging, and per-application sender restrictions.

SMTP relay O365 configuration: the exact setup

The following IP-authenticated walkthrough uses a fictional company named Contoso. Replace every sample value with your own.

Worked example

Contoso has:

• An on-premises monitoring server at 10.20.30.40.
• A firewall whose outbound NAT address is 198.51.100.24.
• An accepted Microsoft 365 domain, contoso.com.
• An MX target of contoso-com.mail.protection.outlook.com.
• An application sender of monitoring@contoso.com.

The goal is to send alerts to ops@contoso.com and afterhours@outside-partner.example without using a Microsoft 365 mailbox password.

Step 1: Confirm the sending public IP

From the monitoring server’s network, identify its egress IP using your firewall logs, NAT configuration, or a controlled external “what is my IP” check. It must return 198.51.100.24 in this example.

Do not enter 10.20.30.40 in the Exchange connector. That is a private RFC 1918 address and is never visible to Exchange Online across the public internet. Also confirm that the firewall always translates this system’s outbound port-25 traffic to the same public IP; a different NAT rule will cause the connector match to fail.

Step 2: Create the connector in Exchange admin center

In the Exchange admin center, go to Mail flow and then Connectors. Add a connector that describes mail flowing from your organization’s email server to Microsoft 365. Microsoft’s connector interface describes this as a mail-flow configuration; older documentation and PowerShell terminology may still call the relevant object an inbound connector because the SMTP connection arrives into Microsoft 365. (learn.microsoft.com)

Give it a purpose-specific name, such as:

SMTP relay - monitoring server - HQ NAT

For the connector’s sender verification, choose the option that verifies mail by the sender’s IP address. Add:

198.51.100.24

Do not add a broad CIDR block merely for convenience. Every permitted address is a system that can potentially submit mail through your tenant as an allowed relay source. Keep the connector narrow, document the owner, and remove old addresses after ISP or firewall migrations.

Step 3: Configure the application or device

In the device’s SMTP or email settings, enter these values:

SMTP server / smart host: contoso-com.mail.protection.outlook.com
Port:                    25
SMTP authentication:     Disabled / None
Username:                Leave blank
Password:                Leave blank
From address:            monitoring@contoso.com
TLS / STARTTLS:          Enable if the device supports it

For connector-based relay, an SMTP username and password are not part of the authentication mechanism. If your device insists on credentials, you are likely in an SMTP AUTH setup screen or using hardware that cannot perform the relay configuration you need. (learn.microsoft.com)

TLS is optional for this relay method in Microsoft’s method comparison, but use STARTTLS when the sender supports it. It protects the message transmission in transit between your infrastructure and Microsoft 365. TLS support, certificate management, and configuration labels vary by device manufacturer, so treat the device UI as vendor-specific rather than assuming every printer exposes the same controls. (learn.microsoft.com)

Step 4: Ensure the envelope sender uses your accepted domain

Set both the visible From address and, if your software exposes it, the return-path/envelope sender to a Contoso domain:

Header From:     monitoring@contoso.com
Envelope sender: monitoring@contoso.com

If the application cannot control the envelope sender and sends from a vendor, cloud, or localhost domain, it may fail Exchange Online relay validation. In that case, use a local SMTP relay that can rewrite or control the envelope sender, use SMTP AUTH with OAuth if supported, or choose a purpose-built transactional email provider.

Step 5: Send two controlled tests

Send one message to an internal mailbox and another to an external mailbox. Use a unique subject that includes the device name and time, for example:

Subject: SMTP relay test - monitor01 - 2026-08-15T14:30Z

The internal test proves Exchange Online accepted and processed the message. The external test proves you did not accidentally configure Direct Send instead of SMTP relay and reveals deliverability issues that internal delivery can hide.

DNS and deliverability: make relay mail believable

Getting a 250 2.0.0 response from an SMTP server is not the same as reliably reaching an inbox. SMTP relay O365 gives Microsoft 365 a way to accept and forward your message; it does not exempt your mail from spam filtering or replace email authentication.

SPF: authorize every legitimate source

SPF is a DNS TXT record that identifies authorized mail sources for the envelope-sender domain. Microsoft recommends SPF as part of broader email authentication, alongside DKIM and DMARC. (learn.microsoft.com)

A cloud-only Microsoft 365 domain commonly begins with this record:

v=spf1 include:spf.protection.outlook.com -all

If the on-premises device sends directly to Microsoft 365’s MX endpoint and then Microsoft 365 relays it outward, your SPF design needs to reflect the actual mail path and envelope sender. Do not publish a second SPF TXT record; SPF permits one record per domain, so merge all valid senders into one policy. For a domain that also authorizes an on-premises sending IP, a shape might look like this:

v=spf1 ip4:198.51.100.24 include:spf.protection.outlook.com -all

The exact policy must include every legitimate sender for that domain—Microsoft 365, your relay IP if applicable, and any other approved services—without exceeding SPF’s DNS lookup limits. Validate it against your actual message headers rather than copying an example blindly. Microsoft’s guidance notes that SPF validates the SMTP MAIL FROM domain and that SPF alone is not sufficient protection. (learn.microsoft.com)

DKIM and DMARC: protect the visible From domain

DKIM adds a cryptographic signature to outbound mail, while DMARC lets a domain owner publish how recipients should treat mail that fails aligned SPF or DKIM checks. Microsoft recommends configuring SPF, DKIM, and DMARC together for custom domains. (learn.microsoft.com)

Start carefully with DMARC reporting before enforcing a rejecting policy, especially if the same domain is used by employee mail, Microsoft 365 relay, marketing software, ticketing systems, and cloud applications. A strict DMARC policy can expose forgotten senders quickly—which is useful—but it can also block legitimate mail if you have not inventoried every path.

Keep application traffic distinct where possible

For a large or operationally important system, use a dedicated subdomain such as alerts.example.com or notify.example.com, assuming your application and Microsoft 365 accepted-domain design support it. This separates sender reputation, simplifies SPF/DKIM/DMARC analysis, and makes it clearer that a message is machine-generated. Microsoft specifically recommends subdomains for email services outside your direct control so problems with those services do not affect the main employee-mail domain’s reputation. (learn.microsoft.com)

How to test and prove SMTP relay works

A successful deployment has evidence at three layers: network connectivity, Exchange Online acceptance, and final delivery.

Test the network path

From the actual sending host or relay server, test whether your MX endpoint accepts TCP port 25. On Windows PowerShell:

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

On Linux systems with a suitable tool installed:

nc -vz contoso-com.mail.protection.outlook.com 25

A failed TCP test points to DNS, firewall, routing, ISP, or cloud-egress restrictions—not an incorrect Exchange connector. A basic SMTP conversation can also be tested with Telnet in controlled troubleshooting environments, although application logs and message trace are generally safer evidence for production systems. (learn.microsoft.com)

Test the mail transaction

For a manual SMTP diagnostic, use a non-sensitive test message and never paste real customer data into a terminal session:

EHLO monitor01.contoso.local
MAIL FROM:<monitoring@contoso.com>
RCPT TO:<ops@contoso.com>
DATA
Subject: SMTP relay diagnostic

This is a controlled relay test.
.
QUIT

The important signals are the server replies after MAIL FROM, RCPT TO, and final DATA. A successful submission response means the SMTP service accepted the message, but it does not guarantee the recipient inbox has received it. Continue with message trace and recipient-side checks.

Use Exchange message trace

In the Exchange admin center, open Mail flow > Message trace and search by sender, recipient, subject, or a narrow time window. Message trace can show whether Exchange Online received, rejected, deferred, or delivered the message, as well as processing actions taken before final status. (learn.microsoft.com)

For the worked example, search for monitoring@contoso.com and the unique subject line. A healthy test should show that Exchange Online received the message and either delivered it internally or handed it off for external delivery. If trace has no record at all, focus on the device, NAT address, port 25, MX host, and connector match.

Validate the connector itself

Connector validation is part of Microsoft’s connector setup process and can be rerun from the connector workflow. Use it after changing firewall addresses, certificates, routing, or the connector configuration. Connector validation is useful, but a real application-generated message remains the final test because it exercises the exact envelope sender, recipient pattern, attachment behavior, and device SMTP implementation you will run in production. (learn.microsoft.com)

Common SMTP relay O365 errors and what they mean

“Relay access denied” or a 5.7.x rejection

This normally means Microsoft 365 did not treat the connection as an authorized connector relay. Check these items in order:

1. The device is sending to your *.mail.protection.outlook.com MX endpoint, not smtp.office365.com.
2. The device uses port 25.
3. The connector permits the actual public source IP observed after NAT.
4. The connector is enabled.
5. The MAIL FROM domain is an accepted Microsoft 365 domain.
6. A network security appliance is not relaying or rewriting traffic through a different public IP.

Microsoft’s current relay rules require both a matching OnPremises-type connector source—IP or certificate—and an accepted domain based on the certificate domain or envelope sender domain. A visible From header by itself is not enough. (learn.microsoft.com)

Internal recipients work, external recipients fail

This is the signature of Direct Send or a relay policy that is not matching. Direct Send can send to recipients inside your Microsoft 365 organization but does not relay to the internet. Confirm that the connector exists, is active, and trusts the sending public IP. (learn.microsoft.com)

Timeout or connection refused on port 25

Exchange settings cannot fix a blocked network path. Verify outbound TCP 25 from the actual host, then inspect the local firewall, corporate egress firewall, ISP, virtual-machine provider, and DNS resolution. If port 25 is unavailable and cannot be opened, use an architecture that supports authenticated submission over port 587, such as SMTP AUTH with OAuth, a local relay that has permitted egress, or a transactional provider.

The device asks for a username and password

That screen may only support SMTP AUTH. Connector relay does not require mailbox credentials, so do not create a shared mailbox merely to satisfy a UI that cannot do the required setup. Check whether the device firmware offers a no-authentication SMTP mode; otherwise, send through an intermediate local SMTP relay or migrate to an OAuth-capable application design. (learn.microsoft.com)

The email is accepted but lands in spam

Inspect the received message headers at the destination. Look for SPF, DKIM, DMARC, and authentication-results fields, then compare the envelope sender and visible From domain. Also check whether the system sends repetitive, low-context alerts, uses misleading display names, or includes URLs and attachments that security filters distrust. Microsoft notes that SMTP relay mail can still be filtered as suspicious and recommends an SPF record entry. (learn.microsoft.com)

The public IP changed after an ISP or firewall migration

This is a common operational failure. The relay may work until a circuit replacement, SD-WAN failover, firewall update, or NAT redesign changes the egress address. Treat connector IPs as production configuration items: include them in change management, monitor relay failures, and update the connector before cutover.

Security controls that prevent an accidental open relay

Connector-based relay replaces mailbox-password risk with network-trust risk. A compromised system behind an allowed NAT address could attempt to send unwanted mail through your tenant, so protect the sending side as seriously as the Microsoft 365 side.

Use these controls:

• Restrict the connector to individual static public IPs wherever possible.
• Permit outbound TCP 25 only from the relay host or named devices, not every workstation VLAN.
• Use a dedicated internal SMTP relay for many devices; require devices to authenticate locally or segregate them by network.
• Restrict local relay permissions by source IP, sender domain, and recipient policy.
• Use TLS/STARTTLS where supported and keep firmware and certificates current.
• Monitor Exchange message trace and application logs for unexpected sender addresses, recipient volumes, failures, and external destinations.
• Use alert-specific From addresses such as monitoring@, printer@, or noreply@ rather than impersonating executives or user mailboxes.
• Maintain SPF, DKIM, and DMARC for every sending domain and subdomain. (learn.microsoft.com)

Microsoft 365 applies anti-abuse controls and can restrict sending when service limits are exceeded or behavior resembles spam. Connector relay is for legitimate application and device mail, not bulk marketing campaigns. If your workload is marketing, newsletters, or very high-volume customer messaging, choose infrastructure designed for that purpose and evaluate transactional email pricing before treating an employee collaboration platform as a bulk delivery engine. (learn.microsoft.com)

When SMTP relay is the wrong solution

SMTP relay is not a universal “Microsoft 365 SMTP server.” It has a narrow but useful fit.

Cloud-hosted applications

Microsoft’s SMTP relay method is intended for on-premises systems with a static IP or certificate and does not support applications hosted by third parties in the same way. A cloud application may have changing outbound IPs, provider-controlled networking, or no practical way to present the expected certificate. SMTP AUTH with OAuth, an email API, or a dedicated provider is usually the better path. (learn.microsoft.com)

Internal-only high-volume messages

Microsoft’s High Volume Email service is specifically designed for automated, transactional, and operational mail to internal recipients, using dedicated HVE accounts rather than user or shared mailboxes. It is not an external-recipient replacement for SMTP relay. (learn.microsoft.com)

Applications that support APIs

A modern application is often better served by an email API because it can use scoped credentials, structured templates, delivery events, and clearer application-level observability. SMTP is still valuable for legacy compatibility, but API-capable systems should not default to a protocol chosen for 1980s mail clients.

Devices with no TLS, no static IP, and no secure controls

If an old printer only supports weak encryption, cannot use no-auth SMTP, cannot reach port 25, and sits behind a changing residential IP, forcing it into a connector architecture creates an unreliable security exception. Place a modern local relay between it and Microsoft 365, update the hardware, or use a service compatible with the network constraints.

SMTP relay O365 deployment checklist

Use this checklist before calling the work complete:

• The sender is on-premises or otherwise has a stable, dedicated public egress IP.
• You recorded the real public IP after NAT, not the device’s LAN address.
• The sender domain is accepted in Microsoft 365.
• The application’s MAIL FROM domain is accepted in Microsoft 365.
• A connector exists from your organization’s email server to Microsoft 365.
• The connector is enabled and limited to the required public IP address or certificate.
• The app uses your exact *.mail.protection.outlook.com MX endpoint.
• The app uses TCP port 25 and no SMTP username/password.
• Outbound port 25 works from the actual sender.
• A test message reaches an internal recipient.
• A separate test reaches an external recipient.
• Exchange message trace shows the expected processing result.
• SPF, DKIM, and DMARC are reviewed for the envelope and visible From domains.
• The connector IP, device owner, sender address, and change process are documented.

Conclusion

The reliable SMTP relay O365 pattern is straightforward once you separate it from SMTP AUTH: create a narrowly scoped Exchange Online connector, point the on-premises sender at your Microsoft 365 MX endpoint on port 25, authenticate by public IP or certificate, and ensure the envelope sender belongs to an accepted domain.

Most failures come down to one of five mismatches: wrong host, wrong port, wrong public IP, no connector match, or a MAIL FROM domain Exchange Online does not accept. Test internal and external delivery separately, verify the message in Exchange trace, and protect the sender path with DNS authentication and network restrictions. That turns a fragile scan-to-email workaround into a supportable mail-flow service.

FAQ

What is the SMTP relay O365 server name?

For connector-based Microsoft 365 SMTP relay, use your tenant’s MX endpoint, which normally ends in .mail.protection.outlook.com, such as contoso-com.mail.protection.outlook.com. Do not use smtp.office365.com unless you are configuring SMTP AUTH client submission. (learn.microsoft.com)

What port does Microsoft 365 SMTP relay use?

Microsoft 365 connector-based SMTP relay requires TCP port 25. SMTP AUTH client submission typically uses port 587, which is a different configuration method. (learn.microsoft.com)

Does SMTP relay O365 require a Microsoft 365 mailbox?

No. Connector-based SMTP relay authenticates the sending connection by its configured static public IP address or TLS certificate, rather than by a cloud mailbox’s SMTP username and password. (learn.microsoft.com)

Can Microsoft 365 SMTP relay send to Gmail and other external recipients?

Yes. SMTP relay through a matching Exchange Online connector can relay to both internal and external recipients. Direct Send cannot relay to external recipients, so it is not a substitute when you need to email Gmail, customer domains, or other internet addresses. (learn.microsoft.com)

Why does my Microsoft 365 relay work internally but not externally?

You are likely using Direct Send, targeting the wrong SMTP host, or failing the connector match. Confirm that a connector is enabled for the sender’s actual public IP and that the device is sending to your Microsoft 365 MX endpoint on port 25. (learn.microsoft.com)