SMTP Relay Exchange Online: Secure Setup, Testing, and Troubleshooting

SMTP relay Exchange Online is the usual answer when a printer, server, line-of-business application, or on-premises device must send email through Microsoft 365 without storing a user’s mailbox password. The right configuration depends on who receives the mail, whether the sender has a static public IP address, and whether the workload is transactional or high-volume.

What SMTP relay means in Exchange Online

SMTP is the protocol an application uses to hand a message to a mail server. An SMTP relay is the mail server’s agreement to accept that message and deliver it onward, including to recipients outside your Microsoft 365 organization.

In Exchange Online, “SMTP relay” normally means a device or application connects on TCP port 25 to your Microsoft 365 Protection MX endpoint. Exchange Online recognizes the sender through an inbound connector, most commonly by the sender’s static public IP address, and relays messages to internal and external recipients.

That is different from simply sending mail to an Exchange Online mailbox. It is also different from logging into smtp.office365.com as a mailbox user. Those distinctions matter because each method has different authentication, recipient, network, and security requirements.

A relay is a good fit for:

• A multifunction printer or scanner that must send scans to staff and sometimes to customers.
• An on-premises monitoring system that sends alerts from addresses such as alerts@contoso.com.
• An ERP, CRM, or warehouse application that can send SMTP but cannot complete modern OAuth authentication.
• A server workload that must send from a shared functional address without a licensed user mailbox.

It is not automatically the best fit for every application. A cloud-hosted app with changing outbound IP addresses, a product that needs API-level delivery events, or a newsletter-style workload generally needs another approach.

Choose the correct Microsoft 365 sending method first

The phrase “SMTP relay” is often used for three separate Exchange Online patterns. Selecting the wrong one is the source of many avoidable configuration failures.

SMTP client submission

SMTP client submission has an application authenticate as a mailbox, typically to:

Host: smtp.office365.com
Port: 587
Encryption: STARTTLS
Authentication: OAuth 2.0, where supported

It can send to internal and external recipients. It requires a licensed Exchange Online mailbox (or another mailbox that can authenticate), SMTP AUTH to be enabled for that mailbox and tenant where applicable, and a client capable of the authentication method Microsoft permits.

This is convenient for modern applications that support OAuth 2.0 and need to send as one specific mailbox. It is a poor choice for a legacy printer that stores a long-lived username and password, and it creates operational risk when a human user account is used as the service identity. Microsoft has retired Basic authentication for many Exchange Online protocols and has moved SMTP AUTH away from Basic authentication; do not design a new integration around a username-and-password SMTP connection.

Direct Send

Direct Send also connects to your Microsoft 365 MX endpoint on port 25, but it is intended for delivery to recipients inside your own Microsoft 365 organization. It does not use a connector or authenticate the sender.

For example, a copier can send to person@contoso.com through the MX endpoint, but it cannot reliably use Direct Send to deliver to customer@example.net. Because it has no sender authentication, Microsoft documents important abuse risks, including spoofing scenarios. Treat it as an internal-recipient-only mechanism, limit it at the network boundary, and do not expose it as a general application relay.

SMTP relay through an inbound connector

This is the method covered in this guide. Your device sends to your Microsoft 365 MX endpoint on port 25. An Exchange Online inbound connector identifies the sending server by static IP address or, in some cases, by a TLS certificate. The connector authorizes the server to relay to both internal and external recipients.

It does not require a mailbox credential on the device. It does require a properly controlled sending source and a connector that is narrow enough not to become an abuse path.

High Volume Email and a dedicated email provider

Microsoft also offers High Volume Email (HVE) for Exchange Online tenants, with a purpose-built path for internal and external high-volume sending. Availability, limits, licensing, and configuration are service-specific, so assess its current Microsoft documentation before committing a workload to it.

For product emails—password resets, receipts, invitations, and event notifications—a dedicated transactional email provider can be more suitable. These platforms commonly provide an HTTP API, SMTP credentials scoped to an application, delivery webhooks, suppression handling, and sending analytics. Compare the operational model and sending costs before choosing an email API or relay service; see transactional email pricing and plans when you need a dedicated sending channel.

Requirements before you configure SMTP relay Exchange Online

Do not start by creating a connector. First collect the details Exchange Online will use to decide whether a message is trustworthy.

The essential prerequisites

You need all of the following:

1. An accepted domain in Microsoft 365. The envelope sender address should use a domain that your tenant has verified, such as contoso.com. Check this in the Microsoft 365 admin center under Domains.
2. A static, public outbound IPv4 address for the device, server, or the NAT gateway it uses. This must be the address Microsoft sees on the internet, not a private address such as 10.20.30.40.
3. Outbound TCP port 25 connectivity from that public IP to Microsoft 365. Many internet providers and cloud environments restrict port 25 to reduce spam. Test this before changing application settings.
4. Exchange administrator permissions sufficient to create and manage mail-flow connectors. The Exchange admin center is the normal interface.
5. An accurate sender address and recipient test plan. Decide the From address, such as scanner@contoso.com, and prepare one internal and one external test recipient.

A fixed IP is not an optional convenience. IP-based connector authentication cannot safely identify an application that exits from an unpredictable address. This is why a hosted SaaS application, an employee laptop, or a residential connection is usually unsuitable for this relay pattern.

Find the MX endpoint to use as the SMTP host

The SMTP host is not smtp.office365.com for IP-authenticated relay. Use the MX record for the Microsoft 365 accepted domain from which you are sending.

From Windows PowerShell or Command Prompt:

nslookup -type=mx contoso.com

From macOS or Linux:

dig +short MX contoso.com

The result resembles this:

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

Use that hostname—not the sample hostname—in the device’s SMTP server field. The exact hostname is tenant- and domain-specific. Microsoft may change the underlying routing infrastructure, so always use DNS rather than hard-coding an IP address returned by a lookup.

Decide how Exchange Online identifies your sender

The common connector option is to identify the partner organization by one or more sending IP addresses. Enter the public NAT address used by the application, firewall, or mail server.

Certificate-based connector identification is possible in Exchange Online connector scenarios, but it requires the sending system to present TLS correctly and use the subject name configured in the connector. For a single legacy appliance, static IP identification is often simpler. For a mail gateway fleet, a properly managed certificate can be attractive, but only if the gateway and certificate lifecycle are under your control.

Do not use a broad CIDR range “just in case.” Every address included in the connector can potentially submit mail that Exchange Online will relay. Add only the exact egress IPs you own and operate.

Create the inbound connector in the Exchange admin center

The connector tells Exchange Online that mail arriving from your approved source is allowed to relay. The labels in the Exchange admin center can change, but the configuration logic remains the same.

Connector setup steps

1. Sign in to the Exchange admin center with an Exchange administrator account.
2. Open Mail flow, then Connectors.
3. Choose Add a connector.
4. For the connection from field, select Partner organization. For the connection to field, select Microsoft 365 or Office 365, depending on the interface wording.
5. Give it a clear, operational name, for example: SMTP relay - warehouse gateway 198.51.100.24.
6. Select the option that identifies the partner organization by the sending server’s IP address.
7. Add the public egress IP address. In this guide’s worked example, it is 198.51.100.24.
8. Review security options carefully. Require TLS only when the sending device or gateway supports it correctly. If TLS is enabled, use a valid configuration and test it; do not assume an old copier can negotiate the required TLS version or certificate validation behavior.
9. Save the connector and ensure it is enabled.
10. Complete the connector validation test if the wizard offers it. Use a test sender and recipient you can inspect.

The connector is inbound because messages enter Microsoft 365 from your device. The fact that Microsoft 365 subsequently delivers the message to an external recipient does not make it an outbound connector configuration task.

Avoid over-permissive connector settings

The security boundary is the connector match. A safe design makes it difficult for an unrelated host to match it.

Use these practices:

• Restrict IP addresses to owned, fixed egress IPs.
• Use separate connectors for clearly separate environments when that improves accountability, such as production versus test.
• Document the device, NAT rule, application owner, sender domains, and change owner beside the connector name or in your operations system.
• Do not share the connector’s permitted IP with unmanaged devices, general user Wi-Fi, or arbitrary workloads.
• Review it after firewall, ISP, office, or cloud-network changes. A new NAT gateway can silently break all relay mail.

Microsoft 365 anti-spam protection remains in the mail path. A connector authorizes relaying; it does not guarantee that every message is accepted by every recipient provider or that content will avoid filtering.

Configure the application, server, or printer

Once the connector is active, configure the sending workload. Interface names vary widely, but the fields map to the same SMTP values.

Standard IP-authenticated relay settings

SMTP server / smart host: <your-domain-mx>.mail.protection.outlook.com
Port: 25
Authentication: None
Username: blank
Password: blank
From address: alerts@contoso.com
TLS: Optional or required to match your connector and device capability

Replace <your-domain-mx> with the hostname discovered from your MX query. Do not use smtp.office365.com here; that endpoint is for authenticated client submission, not this connector-based relay workflow.

Some devices call the hostname a “smart host,” “outgoing mail server,” or “SMTP gateway.” Some expose a checkbox called “SMTP authentication.” Turn it off for IP-authenticated relay. A device that attempts AUTH may fail or behave unexpectedly because the relay is being authorized by its source IP rather than by a mailbox login.

Sender address rules

Use a From address in a domain accepted and verified by your tenant. A functional address is preferable to an employee’s personal address:

scanner@contoso.com
alerts@contoso.com
invoices@contoso.com

Create a shared mailbox, distribution group, or monitored mailbox for replies if humans might respond. The SMTP relay itself does not require that every From address be a mailbox, but a valid, monitored reply path reduces support problems.

If your application controls the envelope sender or Return-Path separately from the visible From header, keep both in a verified domain where possible. Third-party recipient systems inspect alignment and authentication, not just what users see in their inbox.

Test network reachability before blaming Exchange Online

From a Windows server, test port 25 connectivity:

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

A successful TcpTestSucceeded : True only proves that the TCP connection can be opened. It does not prove the connector matches, the sender is allowed to relay, or the message is deliverable. Still, it quickly exposes blocked outbound port 25 and DNS mistakes.

On Linux, a basic TCP check can be run with:

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

When TLS is expected, use a tool that can initiate STARTTLS and show the SMTP conversation. This is particularly useful when a device reports only a vague “SMTP error.” Do not paste real customer addresses, passwords, or message content into public testing services.

Worked example: relay monitoring alerts to internal and external recipients

Assume Contoso has an on-premises monitoring server. It uses private address 10.40.8.15, exits through a firewall NAT address of 198.51.100.24, and must send alerts from alerts@contoso.com to employees and to an external managed-service provider.

Step 1: confirm the domain and MX record

Contoso has already verified contoso.com in Microsoft 365. An administrator runs:

dig +short MX contoso.com

The result is:

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

The monitoring team records contoso-com.mail.protection.outlook.com as the SMTP host.

Step 2: verify the public IP

The firewall team confirms that SMTP traffic from 10.40.8.15 is source-NATed to 198.51.100.24. This is the value to enter in Exchange Online. Entering 10.40.8.15 would fail because Microsoft never sees that private RFC 1918 address.

They also confirm that the firewall permits outbound TCP 25 from that server to Microsoft 365. The server administrator runs:

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

The output reports a successful TCP test.

Step 3: create the connector

In Exchange admin center, the administrator creates a connector from Partner organization to Microsoft 365, names it SMTP relay - monitoring NAT, and chooses IP-address identification. They add only:

198.51.100.24

They do not add the whole office IP range. They enable the connector and record the change ticket and firewall rule reference.

Step 4: configure the monitoring application

In the monitoring application’s notification settings, they enter:

Server: contoso-com.mail.protection.outlook.com
Port: 25
Authentication: disabled
TLS: enabled if the application supports STARTTLS correctly
From: alerts@contoso.com
Reply-To: noc@contoso.com

They leave username and password empty. If the product refuses to save a blank authentication field, it may not support connector-based relay; check its documentation for unauthenticated SMTP or choose an OAuth-capable client submission or email API integration instead.

Step 5: send two purposeful tests

First, they send a short alert to admin@contoso.com. Second, they send the same alert to monitoring-contact@example.net. The internal message proves basic submission and tenant routing. The external message proves the connector is authorizing relay beyond the tenant.

They inspect the monitoring application log for the SMTP response and use Exchange message trace to locate the message. If the external test arrives, they inspect message headers at the receiving system to see the actual authentication results. They then trigger an ordinary real alert to prove the application’s production notification template does not introduce malformed addresses or oversized attachments.

Authenticate the domain: SPF, DKIM, and DMARC

A connector allows your system to submit mail, but domain authentication still affects recipient trust and deliverability. Configure these controls before relying on relay for customer-facing messages.

SPF

SPF is a DNS TXT policy declaring which services may send mail for a domain. Microsoft’s published guidance for SMTP relay includes adding the sending server’s public IP address to the domain’s SPF record. The exact record must reflect every legitimate sender for the domain and must be maintained as one consolidated SPF TXT record.

For example, if Contoso’s only authorized sources are Microsoft 365 and its relay gateway at 198.51.100.24, its policy might have this shape:

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

This is an example, not a copy-and-paste universal record. If you also use a website platform, help desk, marketing provider, or another mail gateway, include only the mechanisms those vendors explicitly document. Multiple SPF TXT records at the same hostname can produce a permanent SPF error, so merge authorized mechanisms into one record.

Avoid +all, which effectively authorizes every host on the internet. Use -all only after you have inventoried all real senders; ~all is sometimes used during a controlled transition, but it is not a substitute for completing the inventory.

DKIM

DKIM applies a cryptographic signature to messages. For mail that Exchange Online sends outward using your accepted domain, enable DKIM for the custom domain in the Microsoft 365 security or Defender portal after publishing the CNAME records Microsoft provides.

The required selector hostnames and targets are tenant-specific. Copy them from the Microsoft 365 DKIM setup interface rather than guessing. Publish both selectors, wait for DNS propagation, then enable DKIM. Check headers from an external mailbox for a DKIM-Signature header and an authentication result showing dkim=pass.

DMARC

DMARC tells receiving systems how to handle mail that fails SPF and DKIM alignment, and it provides aggregate reports. Start with a monitoring policy while you inventory all authorized senders:

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

The strict alignment tags in that example are a deliberate policy choice, not mandatory defaults. Ensure dmarc-reports@contoso.com is ready to receive reports, and review them before changing to p=quarantine or p=reject. DMARC reports often reveal forgotten systems sending as your domain.

For a small number of internal device alerts, authentication may seem excessive. The moment messages go to external recipients, compromised relay infrastructure can damage your domain reputation. SPF, DKIM, and DMARC are practical controls, not cosmetic DNS records.

How to verify that relay is actually working

A green connector status or successful printer test page is not sufficient evidence. Verify the whole route, including acceptance, message tracing, recipient delivery, and authentication.

Use an internal and external test matrix

Run these tests after initial setup and after meaningful network or mail-flow changes:

Use Exchange message trace in the Exchange admin center to search by sender, recipient, and time window. Trace data can show whether Exchange Online received, delivered, failed, or filtered the message. It is the primary evidence when an application says “sent” but the user reports no email.

Inspect the delivered message headers

In an external mailbox that received the test, view the full message source or original headers. Look for the Authentication-Results header. A healthy message generally shows outcomes such as:

spf=pass
dkim=pass
dmarc=pass

Exact header wording differs by recipient provider. A delivered message may still have a failed or missing authentication result, so inspect rather than assume. If DMARC fails, compare the domain in the visible From address with the domains used for SPF and DKIM alignment.

Monitor continuously, not just on launch day

Set an operational owner for the connector and sender address. Monitor application failures, bounce messages, mailbox replies, and unusual sending volume. Sudden volume from scanner@contoso.com at midnight may indicate a compromised device or a misconfigured application loop.

Keep relay sources patched. A connector authorization is not a security blanket: if an attacker compromises a server behind an authorized static IP, that server may be able to submit abusive mail through your tenant.

Common SMTP relay Exchange Online errors and fixes

Failures become easier to diagnose when you classify them by where they happen: DNS and network, connector matching, sender authorization, or recipient delivery.

Connection timeout or cannot connect

Likely cause: outbound port 25 is blocked, the MX hostname is wrong, DNS cannot resolve it, or a firewall/proxy interferes.

Fix: run Test-NetConnection or nc from the actual sending host. Compare the configured server name with the MX record. Ask the network provider specifically whether outbound TCP 25 is permitted. Do not switch to random Microsoft IP addresses; use the MX hostname.

Authentication failed or 5.7.x relay denied

Likely cause: the device is using smtp.office365.com with no mailbox authentication, the connector is disabled, the connector does not include the observed public IP, or the device is exiting through a different NAT address than expected.

Fix: confirm the SMTP host is your mail.protection.outlook.com MX endpoint and the port is 25. Check the firewall’s live NAT logs. Update the connector with the actual public IP only after confirming that IP belongs to the intended workload.

A generic “unable to relay” message is not an invitation to loosen the connector. First establish the exact source IP Microsoft is seeing.

Internal messages work but external messages fail

Likely cause: Direct Send was configured instead of connector-based SMTP relay, or the connector is not matching.

Fix: verify that an inbound connector from Partner organization to Microsoft 365 exists and is enabled. Confirm the sending server uses the tenant MX endpoint and its public IP is listed. Then use message trace to distinguish Microsoft rejection from a downstream recipient rejection.

The message lands in spam

Likely cause: missing SPF, DKIM, or DMARC alignment; a new or low-reputation sender; poor message content; malformed headers; or an application sending unexpected volume.

Fix: inspect external message headers, publish and enable domain authentication, use a stable functional From address, include meaningful text rather than empty or repetitive alerts, and avoid unsolicited bulk sending through device relay. For ongoing product email, use a service designed for deliverability controls and event feedback.

TLS or certificate errors

Likely cause: an older device does not support the TLS versions, cipher suites, hostname validation, or STARTTLS behavior required by its configuration.

Fix: update firmware or route mail through a maintained local SMTP gateway that supports modern TLS. Do not disable security controls globally merely to accommodate one old printer. If you use a connector that requires TLS, test the exact device path—not just a desktop mail client.

Security, limits, and architecture choices

SMTP relay is an infrastructure integration, so design for failure and abuse as well as successful sending.

Keep a relay from becoming an open relay

An open relay accepts unauthenticated messages from arbitrary internet hosts and forwards them to arbitrary recipients. That is a spam engine. Exchange Online connector relay is safe only when the connector match is tightly constrained.

Your minimum security posture should be:

• A static, controlled egress IP, limited to the actual sending system.
• A connector scoped to that IP rather than a broad network.
• A verified accepted sender domain.
• SPF, DKIM, and DMARC configured for external mail.
• TLS enabled where the device and connector support it correctly.
• Logging and alerting for unusual mail volume or failures.
• An owner who removes old IPs, applications, and connectors when systems are retired.

Know when not to use this pattern

Do not force all outbound mail through Exchange Online SMTP relay. Use a different architecture when it better fits the workload:

• No static IP: use an email API, a managed SMTP provider with credentials, or OAuth-based client submission if supported.
• Cloud application: use the provider’s API or a dedicated transactional service. Static-IP relay is fragile across autoscaling, NAT, and region changes.
• Bulk marketing: use a consent-aware marketing platform with unsubscribe management and audience controls. SMTP relay is not a substitute for marketing compliance tooling.
• Need delivery events: select a service with webhooks for delivered, bounced, complained, and opened events where those measurements are appropriate.
• Legacy hardware with weak TLS: use a supported local gateway or replace/upgrade the device rather than weakening tenant-wide mail security.

Application developers integrating a modern service should prefer a documented email API where possible. The email API reference and setup guides are useful when you need code-level sending, scoped credentials, and programmatic status handling rather than network-based SMTP authorization.

A practical rollout checklist

Use this checklist to move from a test configuration to an operational relay without overlooking the pieces that fail later.

1. Verify the sender domain is accepted and verified in Microsoft 365.
2. Identify the application’s real public NAT IP and confirm it is static.
3. Look up the domain’s MX endpoint and configure the hostname, not an IP address.
4. Confirm outbound TCP 25 from the actual source host.
5. Create an inbound Partner organization to Microsoft 365 connector scoped only to that public IP.
6. Configure SMTP host, port 25, no SMTP AUTH, a verified From address, and TLS settings that match device capability and connector policy.
7. Send internal and external test messages.
8. Use message trace to confirm Exchange Online processing.
9. Inspect external headers for SPF, DKIM, and DMARC results.
10. Document the connector, sender, source IP, NAT rule, application owner, and rollback plan.
11. Monitor logs and review the connector whenever the network or application changes.

The central rule is simple: use connector-based SMTP relay only when Exchange Online can identify a controlled sending source. When the source is dynamic or the workload needs product-email capabilities, choose a modern authenticated service instead.

FAQ

What SMTP server should I use for Exchange Online SMTP relay?

Use the MX endpoint for your Microsoft 365 accepted domain, such as contoso-com.mail.protection.outlook.com, on port 25. Find the exact hostname through an MX DNS lookup. smtp.office365.com is for authenticated SMTP client submission, not IP-based connector relay.

Does Exchange Online SMTP relay require a mailbox license?

Connector-based SMTP relay does not authenticate as a mailbox, so it does not inherently require a mailbox credential for the device. You still need a Microsoft 365 tenant, an accepted domain, and a properly configured connector. SMTP client submission is different and does require an authenticating mailbox or supported application identity.

Can SMTP relay send to Gmail or other external recipients?

Yes, an Exchange Online inbound connector that correctly identifies your controlled sending IP can relay to external recipients. Direct Send cannot serve as the external-recipient method. Test an external mailbox and inspect message trace and headers to confirm delivery and authentication.

Why does my printer send internally but not externally?

It is often using Direct Send, which is designed for internal Microsoft 365 recipients, or its source IP does not match an SMTP relay connector. Configure the domain MX endpoint, port 25, and a connector that includes the printer’s actual public NAT address.

Should I use SMTP relay for newsletters or bulk campaigns?

No. SMTP relay is best for operational device and application messages. Bulk campaigns need consent management, unsubscribe processing, audience controls, bounce handling, and deliverability tooling that a marketing platform provides.