SMTP Relay Office 365: Three Methods, One Right Answer
Microsoft documents smtp relay office 365 as three distinct methods, and the documentation's biggest failure is politeness: it presents them as equals when they are three different machines for three different jobs. Pick by coin flip and you get scanners that cannot email customers, applications throttled at 30 messages a minute, or a relay that dies the day the office IP changes with nobody remembering why.
This is the impolite version: what each method actually is, the constraint that defines it, and the chooser that ends the meeting.
The three smtp relay office 365 methods side by side
| Method | Endpoint | Auth | Can reach external? | Defining constraint |
|---|---|---|---|---|
| SMTP AUTH submission | smtp.office365.com:587 | Mailbox credential or OAuth | Yes | Sends as one licensed mailbox, 30 msg/min |
| Direct send | yourdomain-com.mail.protection.outlook.com:25 | None | No - your tenant only | Internal-only by design |
| Connector relay | Same MX endpoint, port 25 | Your static public IP (or certificate) | Yes | You own an IP and its SPF story |
Every office 365 relay conversation is secretly a fight about which column matters most. The chooser: who must the mail reach, and what identity should it carry?
Method one: SMTP AUTH - a mailbox pretending to be infrastructure
Authenticated submission sends as a real licensed mailbox, with everything that implies: the mailbox's 10,000-recipient daily budget, the 30-messages-per-minute throttle, Send As permissions when the From differs, and a credential whose lifecycle belongs to identity policy rather than to your application.
It is the correct method when the identity genuinely matters - the CRM sending as sales@, a tool that must appear in a mailbox's Sent Items. It is the accidental method everywhere else, chosen because it resembles every other SMTP config the engineer has seen. The tell that it was accidental: nobody can say whose mailbox the app uses without looking it up, which also means nobody is watching that credential age.
Modern tenants add the familiar complication: SMTP AUTH is disabled by default in many configurations and blocked entirely under security defaults, so this method now begins with an admin conversation, not a settings screen.
Method two: direct send - the internal-only chute
Direct send skips authentication entirely: a device points at your tenant's MX endpoint and delivers. The price of that convenience is absolute - recipients must be mailboxes in your tenant. External addresses are refused at the door, not filtered, not queued.
That single property decides everything. Multifunction printers scanning to staff, monitoring boxes alerting an internal DL, legacy apps notifying employees: perfect fits, zero credentials to rotate, nothing to leak. Anything that will ever need to email a customer, a supplier, or a personal Gmail address: disqualified on day one, and teams that forget this ship a "notifications feature" that works in every internal test and fails for the first real user.
Two operational notes: mail still traverses spam filtering (a compromised device can spam your own staff), and the sending IP should appear in your SPF record to keep internal authentication results clean.
Method three: the connector - a real relay with real paperwork
A certificate- or IP-anchored inbound connector tells Exchange Online: mail arriving from this source is ours; relay it anywhere. External recipients work, no mailbox identity is consumed, and throughput accounting is gentler than the mailbox path. This is the closest Microsoft gets to the classic relay administrators remember from on-premises Exchange.
The paperwork is the product. You need a static public IP (or a certificate the device can present), the connector configured in the Exchange admin center, your SPF record extended to cover the source, and - the part everyone skips - documentation, because a connector is invisible infrastructure that outlives the person who created it. The classic connector incident is not technical: it is the ISP change, office move, or firewall replacement that silently orphans the registered IP, breaking every appliance at once with bounces that blame "relay access denied".
Connectors also inherit a responsibility: Exchange will relay what your IP sends, so your network's hygiene becomes your email reputation. One compromised machine inside the perimeter mails the world with your domain's name on it, and the cleanup lands on whoever's name is on the tenant rather than on whoever plugged in the machine.
The chooser, stated once
- Recipients are all in your own tenant: direct send. Stop here; it is free, credential-less, and safe.
- Mail must carry a specific mailbox's identity, volume is modest: SMTP AUTH, with the mailbox's SMTP AUTH explicitly enabled and the credential owned like any other secret.
- External recipients, machine identity, static source: connector, with the IP and SPF documented where the next admin will look.
- Volume that grows, campaigns, product email at scale: none of the above. Exchange Online's limits and Microsoft's own guidance point sustained bulk at dedicated sending platforms; the three relay methods are for a tenant's operational mail, and they stay reliable precisely when they are not asked to be a marketing engine.
Most environments end up with two methods live - direct send for devices, plus one of the other two - and that is healthy. The unhealthy pattern is one method chosen once, stretched across every use case, and rediscovered only when its defining constraint finally bites. Write the method name next to each sending system in your inventory today, while everything still works, and future incidents shrink from investigations into lookups.
Frequently asked questions
What is the difference between direct send and SMTP relay in Office 365?
Direct send delivers unauthenticated mail to your own tenant's mailboxes only, while a connector-based relay accepts mail from your registered static IP or certificate and can deliver externally. The recipient scope is the whole difference: internal-only versus anywhere.
Does Office 365 SMTP relay require a static IP?
The connector method effectively does - Exchange identifies your traffic by source IP or certificate, so a dynamic address breaks the trust anchor. SMTP AUTH submission and direct send work without one.
Which Office 365 relay method works for scanners and printers?
Direct send is purpose-built for them when scans only go to your own staff: no credentials on the device and nothing to rotate. If the device must email external addresses, it needs the connector method instead.
Can I use Office 365 SMTP relay for bulk email?
No method is designed for it. Mailbox submission carries per-minute and per-day limits, and Microsoft's guidance explicitly directs bulk and marketing volume to third-party email services rather than Exchange Online relay paths.