SMTP Relay for Microsoft 365: Setup, Security, and Troubleshooting

SMTP relay M365 usually means one thing: letting an app, printer, scanner, server, or network device send email through Exchange Online. The correct setup depends on who receives the mail, whether the sender can authenticate, and whether your device has a stable public IP address or TLS certificate.

The terminology is confusing because Microsoft 365 supports three different ways for an application to hand mail to Exchange Online. They use different host names, ports, authentication methods, permissions, and security controls. Choosing the wrong one is the usual reason messages fail with relay-denied errors—or, worse, why a configuration becomes easy to abuse.

What SMTP relay means in Microsoft 365

SMTP is the protocol that mail systems use to transfer messages. A relay is a server accepting a message from one system and delivering it onward. In an Exchange Online setup, your application sends an SMTP message to Microsoft 365; Exchange Online then applies policy, routing, compliance, and anti-spam controls before delivering it.

In Microsoft documentation, SMTP relay has a narrower meaning than many administrators use. It normally means an Exchange Online inbound connector that trusts mail from your organization because it arrives from one or more approved public IP addresses, or presents a trusted TLS certificate. The sending device then connects to your Microsoft 365 Protection MX endpoint on TCP port 25.

That is different from authenticated SMTP submission, where an application logs in with a mailbox or service account, and different again from Direct Send, where an application delivers only to internal Microsoft 365 recipients without authenticating.

A reliable decision rule is:

1. Use SMTP client submission when the application can use modern authentication and sends as a mailbox.
2. Use SMTP relay with an Exchange Online connector when the device cannot authenticate, needs to send externally, and has a fixed public egress IP or an appropriate certificate.
3. Use Direct Send only for unauthenticated messages to recipients in your own accepted Microsoft 365 domains.
4. Use a specialist transactional email provider when the workload is application email at volume, needs API-level observability, or should not depend on a human mailbox or Microsoft 365 tenant sending limits.

The three M365 SMTP options compared

Option 1: SMTP client submission

SMTP client submission is the familiar “SMTP AUTH” model. The application connects to:

Host: smtp.office365.com
Port: 587
Encryption: STARTTLS / TLS
Authentication: OAuth 2.0 preferred

The application authenticates as a licensed or otherwise enabled Microsoft 365 mailbox and normally sends with that mailbox’s address in the From: header. This is generally the best approach for a modern application that supports OAuth 2.0 and needs to send to internal and external recipients.

Do not assume a username-and-password setup will continue working merely because an old device supports it. Microsoft has moved Exchange Online away from Basic authentication, and SMTP AUTH can also be disabled at the tenant or mailbox level. Modern authentication is the durable choice. Confirm the application supports OAuth before designing around this method.

SMTP client submission is a poor fit for many multifunction printers, building systems, older monitoring appliances, and industrial devices because they often support only basic SMTP username/password login or no login at all.

Option 2: SMTP relay through an Exchange Online connector

This is the conventional smtp relay m365 design. You create an inbound connector in Exchange Online that identifies trusted traffic from your on-premises network. The device connects to the MX endpoint for one of your Microsoft 365 domains:

Host: contoso-com.mail.protection.outlook.com
Port: 25
Encryption: STARTTLS when supported or required by your connector policy
Authentication: none at SMTP command level
Trust: approved public IP address(es) or TLS certificate

The MX hostname is not guessed. Look up the MX record for a Microsoft 365 accepted domain in your tenant. It commonly has the pattern shown above, but the exact hostname is tenant-specific.

Because Exchange Online identifies the source by network address or certificate rather than a mailbox password, relay is useful for devices that cannot perform OAuth. It can send to both internal and external recipients when properly configured. The trade-off is that the public IP address, firewall path, connector scope, and sender restrictions become critical security boundaries.

Option 3: Direct Send

Direct Send also uses your Microsoft 365 MX endpoint and port 25, but no connector and no authentication are required. It is intended for devices sending to people in your organization only.

For example, a scanner may send scan-notice@contoso.com to accounts@contoso.com. It cannot reliably use this route to send a scan to a customer at customer@example.net. Exchange Online will not relay unauthenticated Direct Send mail to external domains.

Direct Send also has a security downside: it can be abused for internal spoofing if tenant protections are not configured carefully. Do not treat it as a general-purpose outbound mail service just because an initial internal test succeeds.

Prerequisites before you configure SMTP relay M365

A connector is not simply an SMTP setting on a printer. It is an Exchange Online mail-flow policy. Gather the following first.

• A verified, accepted domain in Microsoft 365, such as contoso.com. The envelope sender should use a domain your tenant accepts.
• The tenant’s MX endpoint. In the Microsoft 365 admin center, find the MX value under domain DNS settings, or query DNS for the domain’s MX record.
• A static public outbound IPv4 address. This is the address Exchange Online sees after NAT, not necessarily the server’s private address such as 10.0.20.15.
• Control of the network firewall. It must allow outbound TCP 25 from the relay device or gateway to Exchange Online. Some ISPs and cloud providers restrict port 25.
• A narrow list of allowed sender addresses and devices. Write this before building the connector; do not make the relay available to every workstation VLAN.
• A test recipient outside your organization. Internal delivery alone does not prove that external relay works.

If the device is on a changing consumer or ISP address, IP-based connector relay is fragile. A relay gateway with a static egress address, SMTP client submission using OAuth, or a transactional mail service is usually a safer architecture.

How to set up an Exchange Online SMTP relay connector

The current Exchange admin center is the normal place to create the connector. Microsoft can change labels and navigation, but the underlying choices remain the same: Exchange Online receives mail from your organization’s email server or partner, identifies the sender by IP/certificate, and accepts mail for relay under defined conditions.

Step 1: find the correct MX endpoint

For a domain such as contoso.com, run:

nslookup -type=mx contoso.com

Or on many systems:

dig MX contoso.com +short

A result may look like this:

0 contoso-com.mail.protection.outlook.com.

Use that exact hostname as the SMTP server in the device. Do not use smtp.office365.com for connector-based relay, and do not use a guessed hostname based on a different domain in the tenant.

Step 2: create the inbound connector

In the Exchange admin center, go to Mail flow and then Connectors, and add a connector. The exact wizard wording varies, but select the equivalent of:

• Connection from: Your organization’s email server
• Connection to: Microsoft 365

Name it descriptively, such as Relay - HQ Print Gateway. A useful name identifies the sending location or service, because connectors are operational security controls that future administrators must audit.

Choose how Microsoft 365 identifies mail from the source. For most device relays, select identification by one or more public IP addresses. Enter only the NAT address or addresses that the device uses to reach the internet. Never enter private RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16), because Microsoft 365 cannot see them.

Certificate-based identification can be appropriate when you operate a capable SMTP gateway with a publicly trusted certificate and controlled TLS configuration. It is usually not practical for a basic printer.

Step 3: restrict what the connector can do

The secure intent is not “accept all mail that appears to be from our network.” It is “accept only mail from this controlled gateway, for the sender identities and use case we authorize.”

Use connector options and mail-flow rules to constrain the path where your requirements warrant it. Typical controls include:

• limiting the source to explicit public IP addresses;
• requiring TLS if the sending gateway supports it;
• limiting which systems can reach the NAT path at the firewall;
• using separate connectors or gateways for distinct environments;
• restricting permitted envelope sender domains or addresses with mail-flow rules;
• blocking external forwarding and monitoring unusual recipient patterns.

Do not add a broad CIDR range merely to get a test working. A source IP range shared by many devices turns a single misconfigured workstation into a possible abuse source.

Step 4: configure the device or application

For the worked example below, the device settings are:

SMTP server: contoso-com.mail.protection.outlook.com
Port: 25
SMTP authentication: Off
STARTTLS: On, if the device supports it and your policy requires it
From address: scanner@contoso.com

The device must exit through the exact public address listed in the connector. If a second WAN link, VPN, SD-WAN policy, cloud NAT gateway, or failover circuit changes that source IP, Exchange Online will not match the connector.

Avoid placing a personal mailbox username and password in the device when using this method. The connector is the authentication boundary; SMTP-level login is not expected.

Step 5: test both routing and authorization

Send a message first to an internal mailbox and then to an external mailbox you control. Use an unambiguous subject, for example:

M365 relay test - HQ scanner - 2026-01-15T10:30Z

Then use Exchange message trace to find the message. Confirm the sender, recipient, submission source, connector or route indication where available, and final delivery status. A successful SMTP response from the printer is useful, but message trace is the authoritative place to establish what Exchange Online accepted and did with the mail.

Worked example: relay a warehouse scanner through Exchange Online

Assume Contoso has a Ricoh scanner at 10.40.8.25. It sends invoices from scanner@contoso.com to the finance team and, occasionally, to vendors. The warehouse firewall NATs this device subnet through the static public address 198.51.100.44 (an example documentation address, not a usable public IP).

The administrator verifies that contoso.com is an accepted Microsoft 365 domain and that its MX record is:

contoso-com.mail.protection.outlook.com

They create an inbound connector named Relay - Warehouse Scanner, with source IP 198.51.100.44. Their firewall permits outbound TCP 25 only from the scanner’s dedicated relay gateway—not from the entire warehouse LAN—to Microsoft 365. The scanner sends to the gateway, and the gateway sends onward through the NAT address. This is preferable to allowing every scanner and workstation direct internet SMTP access.

On the relay gateway, the outbound delivery configuration is:

smarthost: contoso-com.mail.protection.outlook.com:25
smtp authentication: disabled
envelope sender: scanner@contoso.com
TLS: opportunistic or required according to connector and gateway capability

The administrator sends one scan to ap@contoso.com and one to test@vendor-example.net. Both appear in Exchange message trace. They also inspect the received external message headers and confirm the visible From address is scanner@contoso.com, not the gateway host name.

Finally, they test a failure condition: they temporarily route the gateway through a different test WAN address. The message should be rejected because that address is not listed in the connector. That failed test proves the connector is actually enforcing the intended trust boundary.

DNS authentication and sender identity still matter

A connector permits Exchange Online to accept your message. It does not automatically guarantee excellent deliverability at external providers. External mail systems evaluate domain authentication and alignment, especially for messages sent to consumer inboxes.

SPF

Your SPF record tells receivers which systems may send mail for a domain. A typical Microsoft 365 SPF record is:

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

This is only an example. Do not overwrite an existing SPF record without merging all legitimate sending services. A domain must have one SPF TXT record; publishing multiple independent v=spf1 records commonly causes SPF PermError.

If your device sends to Exchange Online and Exchange Online delivers outward, Microsoft 365 is the external sending infrastructure. The relevant SPF design must still match the overall services that send as your domain.

DKIM and DMARC

Enable DKIM signing for each active sending domain in Microsoft 365, then publish the CNAME records Microsoft supplies. Microsoft’s selector host names are tenant-specific, so copy them from the admin portal rather than copying a generic internet example.

A cautious DMARC starting policy might be:

_dmarc.contoso.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@contoso.com; adkim=r; aspf=r"

p=none asks recipients to report failures without requesting enforcement. Review reports before moving to p=quarantine or p=reject. DMARC requires identifier alignment, not merely that some unrelated domain passes SPF or DKIM.

Keep the visible From: domain under your control and aligned with the domain authenticated by SPF or DKIM. Using scanner@contoso.com is generally clearer than using a device’s unowned host name or a public email address from another provider.

Security rules that prevent open-relay problems

An open relay accepts mail from untrusted sources and sends it onward to arbitrary external recipients. It will be exploited for spam and can damage your domain and IP reputation. Microsoft 365 connector relay is designed to avoid this, but overly broad source access and poor network segmentation can recreate the practical risk inside your environment.

Use these safeguards:

1. Allow only fixed, documented public egress IPs in the connector. Review the list whenever WAN, firewall, or cloud NAT architecture changes.
2. Put legacy devices behind a dedicated SMTP gateway. A gateway can enforce sender addresses, recipient limits, TLS, logging, and rate controls that an old printer cannot.
3. Restrict outbound TCP 25 at the firewall. Permit only the gateway or named device subnet, not every client machine.
4. Do not allow arbitrary From addresses. A compromised device should not be able to impersonate executives, payroll, or other protected identities.
5. Use separate paths for bulk marketing and transactional mail. A scan-to-email workflow is not a newsletter platform. Mailbox and Exchange Online service limits are not a substitute for a purpose-built bulk sender.
6. Monitor connector changes and mail flow. Alert on new source IPs, unexpected sender domains, elevated external recipients, and repeated SMTP failures.
7. Keep Direct Send constrained. It is internal-only by design; add anti-spoofing protection and do not depend on it for messages that must reach external customers.

For software you control, an email API can remove many SMTP-era credential and device limitations. Compare the available endpoints, authentication model, and event handling in the email API reference and setup guides before choosing a new sending architecture.

Troubleshooting SMTP relay M365 failures

Start with the exact SMTP response and Exchange message trace. “Email does not work” is not a diagnostic category: distinguish a connection failure, TLS failure, rejection during SMTP, accepted-but-filtered mail, and accepted-but-undelivered mail.

Connection timeout or cannot connect

A timeout usually occurs before Exchange Online evaluates the connector. Check:

• the device is using the tenant MX endpoint, not smtp.office365.com;
• TCP port 25 is allowed outbound from the actual sending gateway;
• the ISP, cloud provider, or firewall is not blocking port 25;
• DNS resolves the MX hostname;
• the device is not trying IPv6 through a path you did not authorize or configure.

Test from the gateway with a TCP connectivity command appropriate to its operating system. A successful DNS lookup does not prove TCP 25 is reachable.

“Unable to relay” or a 5.7.x rejection

These errors generally mean Exchange Online did not consider the source authorized to relay. Confirm the public NAT address from firewall logs, not from assumptions about the server address. Compare it exactly with the connector’s IP list.

Also verify that the connector is enabled, the envelope sender uses an accepted domain, and the device is connecting to the correct MX endpoint. If the organization has multiple Microsoft 365 domains, using the MX endpoint for the wrong configuration can produce confusing results.

TLS or certificate errors

Older devices may offer obsolete TLS versions, weak cipher suites, or certificate validation behavior that does not work with modern services. Update device firmware if possible. If not, place it behind a maintained internal SMTP gateway that can negotiate modern TLS outward.

Do not solve a TLS validation error by globally disabling certificate checks on an application server. That turns an SMTP configuration problem into a traffic interception risk.

Internal delivery works but external mail fails

This is a strong clue that you accidentally configured Direct Send, not connector relay, or that outbound policy is blocking the message. Check the message trace and the SMTP server configured on the device. Direct Send accepts internal recipients but is not an external relay route.

For a connector relay, check external delivery status, anti-spam policy, transport rules, recipient domain errors, and DMARC/SPF/DKIM alignment. An external recipient may also reject a message after Microsoft 365 accepts it, so inspect the final non-delivery report and remote server response.

SMTP AUTH is disabled

If you use smtp.office365.com:587 rather than connector relay, an authentication failure may be caused by tenant-wide SMTP AUTH settings, mailbox-level settings, Security Defaults, an authentication policy, or an application using Basic authentication instead of OAuth. That is a different problem from connector relay; do not add an IP-based connector as a workaround unless it is truly the right delivery model.

How to verify the setup is working over time

A single test message proves only that one path worked once. Production verification combines transport evidence, authentication evidence, and operational monitoring.

First, search Exchange message trace for a known test subject and verify the message was received and delivered. Next, inspect headers in an external mailbox. Look for Authentication-Results and confirm SPF, DKIM, and DMARC outcomes are consistent with your domain policy. Header formatting differs by recipient, but a passing result normally includes indicators such as spf=pass, dkim=pass, and dmarc=pass.

Then monitor the operational signals:

• connector configuration changes and source-IP changes;
• SMTP rejection counts from the device or gateway;
• message trace failures and non-delivery reports;
• volume by sender address and recipient domain;
• DMARC aggregate reports;
• external recipient complaints or blocks.

Set an alert threshold appropriate to the device’s normal behavior. A scanner that normally sends a few messages per day should not silently begin sending hundreds of external messages. Baselines are more useful than generic thresholds because each relay use case is different.

When M365 SMTP relay is not the best tool

Exchange Online relay is appropriate for operational messages: scanner output, monitored-system alerts, low-volume device notices, and application messages closely tied to your Microsoft 365 identity. It is not automatically the best solution for product notifications, password resets, receipts, newsletters, or large application workloads.

For customer-facing email, evaluate sender separation, APIs, webhook events, bounce handling, suppression management, dedicated sending controls, templates, and clear per-message observability. Those are usually central requirements for transactional email, while an Exchange connector is primarily a mail-flow trust configuration.

Also separate transactional and marketing traffic. Marketing consent, unsubscribe handling, segmentation, and campaign delivery require different processes. Even if a connector technically relays a message, that does not make it an appropriate bulk-mail channel.

SMTP relay M365 checklist

Before declaring the implementation complete, confirm all of the following:

• The selected method matches the recipient scope and device capability.
• The connector source is the real public NAT IP, not a private server IP.
• The device uses the tenant-specific Microsoft 365 MX hostname on port 25.
• The firewall limits outbound port 25 to the relay gateway or named devices.
• External-recipient testing succeeds when external delivery is required.
• Exchange message trace confirms acceptance and delivery.
• SPF, DKIM, and DMARC are configured for the visible sending domain.
• Legacy devices cannot choose arbitrary sender identities or use the relay from untrusted network segments.
• Configuration ownership, connector name, IP addresses, and test results are documented.

The best smtp relay M365 configuration is deliberately narrow: it authorizes one known route, from known infrastructure, for a known business purpose. If the use case needs identity-aware application sending or high-volume customer email, choose an authentication and delivery platform designed for that job rather than stretching a device relay beyond its intended role.

FAQ

What is the SMTP server for Microsoft 365 relay?

For connector-based relay, use the MX hostname published for your Microsoft 365 accepted domain, such as contoso-com.mail.protection.outlook.com, on port 25. For authenticated SMTP client submission, use smtp.office365.com on port 587. They are different methods.

Does M365 SMTP relay require a mailbox license?

Connector-based SMTP relay does not authenticate with a mailbox at SMTP level; it trusts a configured public IP address or certificate. SMTP client submission does authenticate as a mailbox or application identity and has different licensing and policy considerations.

Can Microsoft 365 SMTP relay send to external email addresses?

Yes, an Exchange Online connector relay can send externally when correctly configured. Direct Send cannot be used as a general external relay; it is for internal recipients in your Microsoft 365 accepted domains.

Why does my printer send internal mail but not external mail?

It is likely using Direct Send, which accepts mail for internal recipients but does not relay unauthenticated mail externally. Create and secure an Exchange Online connector relay, or use authenticated SMTP submission if the device supports a suitable modern authentication method.

Which port should I use for SMTP relay M365?

Use TCP port 25 for Exchange Online connector relay and Direct Send. Use TCP port 587 with STARTTLS for SMTP client submission through smtp.office365.com. Do not interchange those endpoint-and-port combinations.