Microsoft 365 SMTP Relay: Complete Setup, Settings, and Troubleshooting Guide

Microsoft 365 SMTP relay lets a printer, server, or line-of-business application send mail through Exchange Online without storing a Microsoft 365 mailbox password. The important part is that it is not configured like ordinary SMTP login: Microsoft 365 trusts a connector that identifies your sending system by its public IP address or TLS certificate.

If you are searching for Microsoft 365 SMTP relay, you are probably trying to make a scanner, monitoring platform, ERP system, website, or application send email to both internal and external recipients. This guide shows the exact architecture, settings, connector choices, DNS requirements, tests, and troubleshooting steps needed to make that work reliably.

What Microsoft 365 SMTP relay is

SMTP relay is a mail-flow method in Exchange Online. Your device or application sends an SMTP message to your Microsoft 365 tenant's inbound mail endpoint, and Exchange Online relays that message onward to recipients inside or outside your organization.

Unlike SMTP AUTH client submission, SMTP relay does not authenticate with a mailbox username and password. Instead, Exchange Online accepts the connection because it matches an inbound connector you create. That connector can identify the sender through one or more static public IP addresses or through a TLS certificate presented by the sending mail server.

That distinction matters operationally:

• A shared mailbox password does not need to be embedded in a printer or application configuration.
• The sending application does not need a licensed mailbox merely to submit relay mail.
• The application can usually use multiple sender addresses in an accepted domain, provided its envelope sender meets Exchange Online's relay requirements.
• The application can send to internet recipients, not only recipients in your Microsoft 365 tenant.

SMTP relay is commonly used by on-premises systems with a stable internet connection and a predictable outbound public IP address. Examples include multifunction printers, monitoring systems, building-management controllers, backup servers, database jobs, on-premises web applications, and internal business software.

Microsoft 365 SMTP relay vs SMTP AUTH vs Direct Send

The phrase “SMTP relay” is often used loosely, which causes incorrect configurations. Microsoft 365 supports several different ways for devices and applications to send mail. They have different hosts, ports, authentication models, recipient scopes, and security trade-offs.

SMTP relay: the connector-based option

Use Microsoft 365 SMTP relay when your application is on a network with a static public IP address or can present a suitable TLS certificate, and it needs to send to external recipients.

The defining settings are:

• SMTP host: your tenant-specific Microsoft 365 MX endpoint, such as contoso-com.mail.protection.outlook.com
• Port: TCP 25
• Authentication: an Exchange Online inbound connector, validated by public IP address or TLS certificate
• External recipients: supported
• Mailbox credentials: not required

The tenant MX endpoint is not a generic name you should guess. Look up the MX record for an accepted domain in your Microsoft 365 tenant and use the hostname returned there.

SMTP AUTH client submission: the mailbox-login option

SMTP AUTH client submission is a different design. The application connects to smtp.office365.com, normally on port 587 with TLS/STARTTLS enabled, then authenticates as a mailbox. Microsoft documents support for OAuth with SMTP AUTH; it also recommends disabling SMTP AUTH organization-wide and enabling it only where needed because it creates another credentialed mail submission path.

Use SMTP AUTH when the application supports modern authentication and cannot use a static-IP connector. It is often the practical choice for a cloud-hosted application, a remote device with changing IP addresses, or software that only supports smtp.office365.com.

Do not configure smtp.office365.com:587 with a username and password and call it “SMTP relay.” That is SMTP AUTH client submission.

Direct Send: internal-recipient-only delivery

Direct Send also uses the tenant MX endpoint and port 25, but it does not use an authenticated connector. It is designed for sending to recipients in your Microsoft 365 accepted domains. It does not relay mail to internet recipients.

Direct Send can look like SMTP relay during a basic printer test because internal messages arrive. The difference becomes obvious when you send to a customer, personal mailbox, vendor, or external service: the message cannot be relayed to the internet.

High Volume Email: internal operational mail at scale

Exchange Online also has High Volume Email (HVE), a dedicated service for automated internal messages such as alerts, payroll notifications, security notices, and device-generated mail. HVE is internal-recipient-only and uses dedicated HVE accounts rather than normal user or shared mailboxes.

HVE is not a substitute for Microsoft 365 SMTP relay if your application needs to send invoice copies, status alerts, appointment messages, or notifications to customers outside your tenant. It is appropriate when the sending workload is high-volume and entirely internal.

A simple selection rule

Choose based on the system's location and destination list:

1. On-premises application with static public IP, external recipients required: use Microsoft 365 SMTP relay.
2. Application needs external delivery but has no stable public IP: use SMTP AUTH with OAuth, or use a dedicated email delivery provider.
3. Internal Microsoft 365 recipients only, simple device: consider Direct Send.
4. Large volumes of internal automated messages: assess HVE.
5. Product emails, customer notifications, marketing automation, or high-volume external transactional mail: evaluate a dedicated transactional sender rather than forcing a business mailbox platform to act as an application mail service. Compare the operational model and transactional email pricing before choosing a route.

Requirements before you configure Microsoft 365 SMTP relay

Most relay failures are not caused by an incorrect SMTP port. They happen because the sender lacks a stable identity, the wrong MX hostname is used, or the sender domain fails Exchange Online's accepted-domain checks.

Before opening the Exchange admin center, collect the following information.

1. A Microsoft 365 accepted domain

The domain used in the SMTP envelope sender must be an accepted domain in your Microsoft 365 tenant. For a message sent as alerts@example.com, the relevant SMTP value is generally the envelope sender:

MAIL FROM:<alerts@example.com>

This is not necessarily identical to the human-visible From: header in the message body. Exchange Online changed its SMTP relay requirements so that relying only on the visible From: domain is not enough. The accepted domain needs to be present in the SMTP certificate domain or in the MAIL FROM envelope address, while the source IP address or TLS certificate must also match the connector.

This is especially important for bounce messages, third-party applications, and systems that set a blank return path (MAIL FROM:<>). If you do not control the envelope sender, test the actual SMTP conversation or inspect the application’s mail logs before designing the connector.

2. A static public outbound IP address or a TLS certificate

When you configure IP-based relay, Exchange Online sees the public IP address after NAT, not the private address assigned to the server or printer. An application at 10.20.30.40 may leave the office through 198.51.100.25; the connector must contain the latter.

Verify this with your network team or firewall configuration. Do not assume the WAN address shown in an office router is the address used by all VLANs, guest networks, VPN routes, or cloud egress points.

A certificate-based connector is useful when you operate a proper SMTP server that can establish TLS and present a certificate for a domain you control. It is usually not realistic for a basic printer or legacy appliance, which is why IP-based connectors are more common for device relay.

3. Outbound TCP port 25 connectivity

Microsoft 365 SMTP relay receives mail on TCP port 25 at your tenant MX endpoint. Your firewall, ISP, cloud provider, and application host must allow outbound connections to port 25.

This requirement is a major reason relay works from an office but fails from a cloud VM, residential broadband connection, hotel network, or cellular connection. Many networks restrict outbound TCP 25 to reduce spam abuse. If port 25 is blocked, changing the Microsoft 365 connector will not fix the network path.

4. An SMTP-capable application

The application must support a configurable SMTP host, port, sender address, and preferably TLS. It should also let you specify a return-path or envelope sender. If it only allows authenticated SMTP on port 587 and insists on a username and password, it may not support connector-based SMTP relay at all.

5. DNS ownership for the sending domain

For dependable external delivery, control the DNS records for the sender domain. At minimum, maintain a valid SPF record. If Microsoft 365 is the only sender for example.com, Microsoft's standard SPF pattern is:

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

If other providers also send mail for the same domain, combine their authorized mechanisms into one SPF TXT record. Publishing multiple SPF TXT records for a domain is invalid and can cause receivers to return an SPF PermError.

Microsoft 365 SMTP relay settings at a glance

Use these values as your configuration baseline. Replace the examples with values from your own tenant and network.

Two settings deserve emphasis. First, use the MX endpoint, not smtp.office365.com. Second, do not add mailbox credentials to the application. If the device asks for a login, look for settings such as “SMTP authentication,” “SMTP AUTH,” or “login required” and disable them for relay mode.

How to find the correct Microsoft 365 MX endpoint

Your relay host is tenant-specific. It is normally the MX value published for an accepted Microsoft 365 domain, and it commonly ends in .mail.protection.outlook.com.

Find it in DNS

From a command prompt on Windows, use:

nslookup -type=mx example.com

From macOS or Linux, use:

dig MX example.com +short

Look for the Microsoft 365 MX record. A typical result resembles:

0 example-com.mail.protection.outlook.com.

Remove the trailing period if your device rejects fully qualified DNS names ending with a dot. Enter the resulting hostname as the SMTP server or smart host.

Avoid two common MX mistakes

Do not use an MX record belonging to a third-party secure email gateway unless that gateway is intentionally your outbound smart host. Many organizations point their public MX record at a filtering provider while Microsoft 365 receives mail through a separate routing design. In that situation, follow the documented mail-flow architecture for your tenant rather than assuming the public MX record is the correct relay endpoint.

Also do not point the device at an IP address returned by DNS. Microsoft can change service IP addresses. Use the hostname so normal DNS resolution can keep pace with Microsoft 365 infrastructure changes.

Step-by-step: create the Exchange Online relay connector

The exact wording in the Exchange admin center can change, but the connector design is stable: mail originates at your organization’s SMTP server or device and terminates in Microsoft 365.

Step 1: confirm the source public IP

Identify the public IP that the sender uses for outbound SMTP traffic. If several devices use different sites, cloud regions, or NAT gateways, list every public egress IP that should be permitted.

Keep the scope narrow. Do not add an entire provider address range, a broad office subnet, or an IP range that includes untrusted devices simply to get the test working. An overly broad connector can create an abuse path where an unauthorized machine sends mail that Microsoft 365 treats as trusted organization mail.

Step 2: open the Connectors page

Sign in to the Exchange admin center with a role authorized to manage mail flow. Go to:

Mail flow > Connectors

Choose Add a connector. In the setup wizard, define the connection as:

Connection from: Your organization's email server
Connection to: Microsoft 365

The portal may use slightly different labels, such as “on-premises” rather than “your organization’s email server.” What matters is that this is an inbound connector into Exchange Online that identifies mail coming from your environment.

Step 3: name and describe the connector

Use a name that explains the source and purpose. For example:

Relay - HQ monitoring server - 198.51.100.25

A useful connector name makes incident response much easier. Months later, an administrator should be able to identify whether the connector belongs to a scanner, an application relay host, an old migration server, or an active production integration.

Step 4: select the verification method

For most printers and applications, select verification by the sending server’s IP address and enter the static public outbound IP address.

For a managed SMTP relay server that supports TLS certificates, you can instead verify by certificate. This path requires the server to negotiate TLS and present a certificate whose domain matches the connector configuration. Certificate relay can provide a stronger identity model, but it introduces certificate lifecycle work: issuance, installation, renewal, private-key protection, and monitoring before expiry.

Step 5: save, validate, and enable the connector

Complete the wizard, then ensure the connector is switched on. Exchange Online has built-in connector validation workflows; use them where available rather than treating “saved successfully” as proof that live mail flow works.

Validation confirms the connector configuration, but it does not replace an end-to-end test from the actual application. A server can pass a connector check while a particular printer still has an incorrect host, bad DNS resolver, unsupported TLS option, or stale NAT route.

Configure the application, server, or printer

After the connector exists, configure the sending system. The labels vary by vendor, but the underlying settings should map cleanly to the same values.

Worked example: relay an alert from an on-premises monitoring server

Assume a company uses the accepted domain northwind.example. Its server monitor01 sends backup alerts to employees and an external IT provider.

The network team confirms that monitor01 exits through the static public IP 198.51.100.25. DNS returns this Microsoft 365 MX endpoint:

northwind-example.mail.protection.outlook.com

The Exchange administrator creates this connector:

Name: Relay - monitor01 - 198.51.100.25
From: Your organization's email server
To: Microsoft 365
Verification: Sender IP address
Allowed IP: 198.51.100.25
Status: On

The monitoring platform receives these SMTP settings:

SMTP server: northwind-example.mail.protection.outlook.com
Port: 25
SMTP authentication: Off
Username: blank
Password: blank
Encryption: STARTTLS enabled if supported
From address: alerts@northwind.example
Return-path / envelope sender: alerts@northwind.example

Then send one test message to an internal mailbox and one external mailbox:

To: administrator@northwind.example
Cc: external-test@another-domain.example
Subject: SMTP relay test - monitor01
Body: This is a connector-based Exchange Online SMTP relay test.

If both messages arrive, the infrastructure is working. If the internal message arrives but the external message fails, re-check whether the application was actually configured for Direct Send rather than connector-based relay, and inspect Exchange Online message trace for the final disposition.

A raw SMTP example

An application or relay server will normally perform a conversation similar to this:

EHLO monitor01.northwind.example
MAIL FROM:<alerts@northwind.example>
RCPT TO:<administrator@northwind.example>
RCPT TO:<external-test@another-domain.example>
DATA
From: Backup Alerts <alerts@northwind.example>
To: administrator@northwind.example
Subject: SMTP relay test - monitor01

This is a connector-based relay test.
.
QUIT

The MAIL FROM command is operationally important. It is the envelope sender used for delivery status notifications and SPF evaluation. Do not assume that setting only the visible From: header is sufficient for relay acceptance.

Vendor settings that often need translation

A printer may label the same settings as “SMTP server,” “outgoing mail server,” “smart host,” or “mail transfer agent.” It may label authentication as “SMTP authentication,” “POP before SMTP,” “SMTP user authentication,” or “login.”

For Microsoft 365 SMTP relay, the desired configuration is usually:

• Smart host points to the tenant MX hostname.
• Port is 25.
• SMTP login is disabled.
• Sender address belongs to an accepted domain.
• TLS is enabled if the device supports current TLS versions.
• DNS servers are correctly configured on the device.

Do not use a personal administrator address as the sender merely because it is easy to test. Create a purpose-specific sender such as scanner@, alerts@, noreply@, or invoices@ within an accepted domain. That makes logs, DMARC reporting, user expectations, and incident investigation clearer.

DNS, SPF, DKIM, and DMARC for relay mail

A connector makes Exchange Online accept mail from your server. It does not eliminate the need to authenticate your domain to the rest of the internet.

SPF: authorize Microsoft 365 as a sender

SPF evaluates the envelope sender domain against the IP or infrastructure that actually sends the message to the recipient. Because Exchange Online relays the message outward, receivers should see Microsoft 365 as an authorized sender for your domain.

For an Exchange Online-only domain, this record is the standard starting point:

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

If the same domain also sends through a website provider, help desk, CRM, payment platform, or another outbound service, merge the required authorization mechanisms into one record. Do not publish separate records such as one SPF TXT record for Microsoft 365 and another for the application provider.

DKIM and DMARC: verify alignment, not just delivery

SPF alone is not the whole deliverability strategy. Enable DKIM for Microsoft 365-managed sending domains and publish a DMARC record that matches your organization’s policy and monitoring maturity.

After relay is live, send a test to an external mailbox where you can inspect full headers. Confirm these outcomes:

• SPF passes for the envelope sender domain.
• DKIM passes for the expected signing domain, where applicable.
• DMARC passes and aligns with the visible From domain.
• The message is not categorized as spam or quarantined.

A successful SMTP response only means the message was accepted for processing. Authentication alignment and recipient-side filtering determine whether it reaches the inbox.

How to test and prove the relay works

A good test has three layers: connection, Exchange Online processing, and recipient delivery. Do not stop at “the printer says sent.”

1. Test TCP connectivity

From a Windows server, you can test whether the destination port is reachable:

Test-NetConnection northwind-example.mail.protection.outlook.com -Port 25

A successful TCP test proves only that a network connection can be opened. It does not prove the connector trusts your IP, your sender domain is valid, or Exchange Online will relay the message.

2. Send controlled internal and external messages

Send one message to an internal Microsoft 365 mailbox and one to a mailbox outside the tenant. Use a distinctive subject line and include the sending host name, timestamp, and test identifier in the body.

Test more than a single recipient domain if email is business-critical. One external provider may accept a message while another filters it because of different authentication, reputation, attachment, or content policies.

3. Use Exchange Online message trace

In the Exchange admin center, go to:

Mail flow > Message trace

Search by sender, recipient, subject, and the time window of the test. Message trace can show whether Exchange Online received, rejected, deferred, or delivered the message and can reveal policy actions taken during processing.

Message trace is the authoritative place to distinguish these cases:

• The application never reached Microsoft 365.
• Microsoft 365 rejected the message during SMTP submission.
• Microsoft 365 accepted it but filtered, deferred, or routed it differently.
• Microsoft 365 delivered it externally and the receiving system made the final inbox decision.

4. Inspect message headers at the destination

At an external test mailbox, inspect the received headers. Check the Received chain, Authentication-Results, envelope sender, visible From address, and any spam verdict headers.

The goal is not merely “email appeared.” You want evidence that the message traveled through the intended Microsoft 365 route and passed the authentication checks that matter to recipient systems.

Common Microsoft 365 SMTP relay errors and fixes

The device connects but gets a 5.7.x relay or access error

This generally means Exchange Online did not match the connection to an allowed connector or did not accept the sender identity.

Check the following in order:

1. Confirm the connector is enabled.
2. Confirm the connector contains the device's actual public egress IP, not its private LAN address.
3. Confirm the sending server is using the tenant MX endpoint and port 25.
4. Confirm the MAIL FROM domain is an accepted domain in Microsoft 365.
5. Confirm the application is not rewriting the envelope sender to another domain.
6. If using certificate-based verification, verify the TLS certificate subject and TLS negotiation.

Internal delivery works but external recipients fail

This is the classic symptom of Direct Send being used instead of SMTP relay. Direct Send supports delivery to recipients in accepted domains but does not relay through Microsoft 365 to the internet.

Verify that an inbound connector is configured from your organization's email server to Microsoft 365 and that the sending source matches it. Then repeat the external test and review message trace.

The application is configured with smtp.office365.com and fails

That host belongs to SMTP AUTH client submission, not connector-based Microsoft 365 SMTP relay. It normally expects TLS and mailbox-based authentication, commonly on port 587.

If you intended to use relay, replace it with your tenant MX hostname and port 25, remove mailbox credentials, and configure the connector. If the application only supports authenticated submission, use OAuth-capable SMTP AUTH or select another sending method.

It worked before the ISP, firewall, or cloud migration

The public egress IP likely changed. This happens after a firewall replacement, WAN failover, office move, VPN change, cloud region move, NAT gateway replacement, or provider migration.

Identify the new public egress IP and update the connector deliberately. Avoid leaving the previous IP allowed indefinitely unless it is still an approved redundant route.

The server cannot connect on port 25

Check local firewall rules, upstream firewall policies, ISP restrictions, cloud-provider egress controls, and DNS resolution. A connector cannot overcome a port-25 block before the SMTP session reaches Microsoft 365.

If the host is a cloud application, assess whether SMTP relay is the wrong architecture. A service using dynamic egress addresses or a provider that blocks port 25 will usually be better served by an OAuth-capable submission path or an email API.

The mail sends but lands in spam

Relay acceptance does not guarantee inbox placement. Check SPF, DKIM, and DMARC alignment, the sender domain's reputation, the content, attachments, URLs, recipient engagement, and whether the message looks like automated bulk mail.

Avoid using Microsoft 365 relay as a shortcut for marketing blasts. Exchange Online applies outbound protection and sending limits to protect the service. Use a sending platform designed for customer messaging when volume, deliverability controls, suppression handling, event webhooks, and campaign separation are requirements.

Security and operational best practices

A relay connector effectively grants a source system permission to submit mail as your organization. Treat it as a security boundary, not a convenience setting.

Restrict the connector tightly

Allow only known public IP addresses or a carefully managed certificate identity. Maintain an owner, system name, business purpose, source location, and decommission date in the connector description or an internal inventory.

Review connectors after migrations and retire unused ones. A forgotten relay connector tied to an old public IP can become a security risk if that address is reassigned, repurposed, or no longer controlled as expected.

Use dedicated sender identities

Use addresses that represent the system and purpose:

• alerts@example.com for monitoring notifications
• scanner@example.com for scan-to-email
• billing@example.com for invoice workflow notices
• noreply@example.com for application events

This makes recipient filtering, sender reputation monitoring, message tracing, and DMARC analysis easier than using a named employee mailbox.

Prefer TLS where the device supports it

Port 25 does not mean plaintext should be your target configuration. Enable STARTTLS or TLS on the device where it is supported, and keep device firmware current enough to support modern TLS.

Legacy devices that only support obsolete encryption should not be forced into insecure internet email paths. Put a maintained internal SMTP relay server in front of them, replace the device, or move the workflow to a supported service.

Monitor delivery, not just application logs

Application logs often stop at “submitted to SMTP server.” Build an operational check around failed jobs, non-delivery reports, Exchange Online message trace, and destination inbox results.

For critical systems, alert on a sustained absence of expected mail too. A backup system that silently stops sending success or failure alerts is often more dangerous than one that generates a visible SMTP error.

When Microsoft 365 SMTP relay is not the right tool

Microsoft 365 SMTP relay is excellent for controlled operational mail from known networks. It is less suitable when you need modern application-email capabilities.

Consider another delivery architecture when you need any of the following:

• A cloud application with dynamic or unknown outbound IP addresses.
• OAuth-only authentication without port-25 egress.
• Per-message API credentials instead of network trust.
• Large-scale external customer email.
• Delivery, bounce, complaint, open, or click webhooks.
• Templates, idempotency, suppression lists, scheduled sends, or granular API audit logs.
• Independent sender identities for multiple products or customers.

In those situations, an email API can be easier to secure and operate than a connector based on network location. The appropriate choice depends on the application architecture, recipient type, volume, compliance obligations, and whether email is a core product feature rather than an internal notification channel.

Final checklist before you go live

Use this checklist to validate a Microsoft 365 SMTP relay deployment:

• The sender domain is an accepted domain in Microsoft 365.
• The application uses the tenant MX hostname, not smtp.office365.com.
• The application uses TCP port 25.
• SMTP username and password fields are blank or authentication is disabled.
• An enabled Exchange Online connector exists from your organization's email server to Microsoft 365.
• The connector permits the actual public NAT or egress IP address.
• The application uses an accepted-domain address in MAIL FROM.
• STARTTLS/TLS is enabled when the sending system supports it.
• SPF is published as one valid record that includes all legitimate senders.
• DKIM and DMARC are configured and tested for the visible From domain.
• A test message reaches both an internal and an external mailbox.
• Exchange Online message trace confirms acceptance and final disposition.
• The connector has an owner and is documented for periodic review.

FAQ

What is the SMTP server for Microsoft 365 SMTP relay?

Use your tenant-specific Microsoft 365 MX endpoint, typically a hostname ending in .mail.protection.outlook.com. Find it by querying the MX record for an accepted domain in your tenant. Do not use smtp.office365.com for connector-based relay.

What port does Microsoft 365 SMTP relay use?

Microsoft 365 SMTP relay uses TCP port 25. The sending host must be able to make outbound port-25 connections to the tenant MX endpoint.

Does Microsoft 365 SMTP relay require a username and password?

No. Connector-based SMTP relay is authenticated by an Exchange Online inbound connector that matches the source public IP address or TLS certificate. Username-and-password submission to smtp.office365.com is SMTP AUTH, which is a different method.

Can Microsoft 365 SMTP relay send to external email addresses?

Yes. That is a key difference between SMTP relay and Direct Send. Microsoft 365 SMTP relay can relay messages to external recipients when the connector, sender domain, and mail-flow requirements are satisfied.

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

You may be using Direct Send rather than a configured SMTP relay connector, or a policy/authentication issue may be blocking the outbound message. Confirm the connector is enabled, test with an external recipient, and use Exchange Online message trace to see whether the message was rejected, deferred, filtered, or delivered.