Office 365 SMTP Relay: All 3 Methods, Configured Step by Step
Published November 3, 2024 · Updated August 21, 2026 · SMTP & Deliverability
Sending application or device email through Microsoft 365 is common — printers, line-of-business apps, and scripts all need a way to relay mail. Office 365 offers three distinct ways to do it, each with different setup steps and limits. Here is how each one works, exactly how to configure it, and where Office 365 stops being the right tool.
The three ways to relay through Office 365
| Method | How it authenticates | Best for |
|---|---|---|
| SMTP AUTH client submission | Mailbox login (port 587) | A single app sending as one user |
| Direct send | None (to your own domain) | Internal-only mail |
| Connector relay | Static IP + connector | Devices relaying externally |
Method 1: SMTP AUTH client submission
The simplest route for a single app that needs to send as one mailbox:
- Ensure SMTP AUTH is enabled for the mailbox — it is disabled by default on newer tenants; an admin enables it per-mailbox in the Microsoft 365 admin center or via PowerShell.
- Use host
smtp.office365.com, port 587, STARTTLS. - Authenticate with the mailbox's email address and password (or an app password if MFA is on).
- Send — the app now delivers as that user.
Method 2: The connector relay
For on-premises devices and apps that need to send external email through Microsoft 365 using a static IP:
- In the Exchange admin center, create a new inbound connector from your organisation's email server.
- Set it to identify the sending server by its static public IP.
- Add that IP to your domain's SPF record so external servers trust it.
- Point your device or app at your MX endpoint and send a test to an external address.
The connector relay requires a static public IP and is meant for low-volume device mail — it inherits Microsoft's throttling, so it is not a bulk-sending solution.
Method 3: Direct send
For mail that only needs to reach recipients inside your own organisation, direct send requires no authentication and routes through your MX endpoint — the simplest option, but internal-only.
The shared ceiling
Every path runs on Microsoft 365's infrastructure and its recipient caps — roughly 10,000 recipients per day per mailbox. None of the three methods is built for marketing volume. Push a bulk campaign through any of them and you risk throttling, or damage to the whole tenant's reputation.
Skip the caps, the shared IPs, and the DNS wrangling
Dedicated IP, unlimited sending, and SPF/DKIM/DMARC configured on signup. From $39.99/mo, cancel anytime.
Frequently asked questions
What is the Office 365 SMTP server and port?
Use smtp.office365.com on port 587 with STARTTLS for authenticated client submission. Enable SMTP AUTH on the mailbox first, since it is off by default on new tenants.
Can I send bulk email through Office 365?
Not really — all three relay methods inherit Microsoft 365's recipient cap (around 10,000/day) and are built for business mail, not marketing. For bulk, use a dedicated SMTP server on its own IP.
Why is SMTP AUTH disabled in my tenant?
Microsoft disables it by default for security. An admin can enable it per-mailbox in the Microsoft 365 admin center or via PowerShell.
Does the connector relay need a static IP?
Yes — the connector authorises your sender by IP, so a static public IP is required, and that IP needs to be added to your domain's SPF record.