Sending email through Microsoft 365: SMTP AUTH, direct send, or a connector

Somewhere in your office a scanner is trying to email a PDF, and how it should do that is a genuine architecture decision. Microsoft's Exchange Online documentation lays out three general-purpose paths for applications and devices sending through Microsoft 365 (plus High Volume Email, an internal-only fourth covered below), each with different authentication, different reach, and different documented limits, and the trouble tickets start when a workload uses the wrong one. This guide is the decision tree: what each option is, the numbers Microsoft publishes for it, the DNS records that must be true in every case, and the volume at which the correct answer leaves Microsoft 365 entirely.

Option one: SMTP AUTH client submission

The application authenticates as a licensed mailbox against smtp.office365.com on port 587 with STARTTLS and sends as that mailbox. It is the simplest path and the most tightly rationed: Microsoft's documentation caps a mailbox at 30 messages per minute and 10,000 recipients per day. The same documentation flags Basic authentication for this method as scheduled for deprecation and recommends OAuth, so plan on modern auth from the start. It reaches external recipients, honors your tenant's policies, and stores sent items with the mailbox. Choose it for low-volume application mail that genuinely belongs to one identity: an invoicing app, a helpdesk sending as support@your-domain.

Option two: direct send

The device sends unauthenticated mail straight to your tenant's MX endpoint, the *.mail.protection.outlook.com host you can read out of your own MX record with the MX lookup. The catch is scope: Microsoft documents direct send as a path for delivering to recipients inside your own organization only, with messages subject to normal spam filtering on arrival. No license, no credentials, but also no reach: the scanner mailing scans to your staff is the use case, and mail addressed outside the tenant is rejected. Microsoft also notes that most customers don't need direct send and that it is working on an option to disable it by default.

Option three: SMTP relay via connector

The infrastructure answer. An administrator creates an inbound connector in Exchange Online that identifies your application servers by TLS certificate (Microsoft's recommended method) or static IP address, and mail from those sources relays through Microsoft 365 to any recipient, internal or external, sent as your domain without a per-mailbox identity. This is the true SMTP relay configuration in the Microsoft world. The costs are operational: it needs port 25 and either a certificate or a static IP not shared with another organization, an IP-authenticated source becomes part of your domain's sending identity (so it must appear in your SPF record), and Microsoft says the method can't be used from third-party hosted services such as Azure. Its documentation publishes no fixed daily cap for connector relay; it states that reasonable limits are imposed and that the service can't be used to send spam or bulk mail. A relay connector is for line-of-business application mail, not campaigns.

What Microsoft points bulk senders toward

Microsoft's own documentation acknowledges the ceiling. It lists High Volume Email (HVE) as a separate method for sending large volumes to internal recipients only, and where mail must reach internal and external recipients it recommends Azure Communication Services Email rather than an Exchange Online mailbox. Read that as the vendor drawing the same line this guide draws: Exchange Online is correspondence infrastructure, and volume mail belongs on systems built for it, whether Microsoft's or the broader ESP category profiled in our services directory.

The records that must be true regardless

Every door sends as your domain, so your domain's authentication has to stand on its own. SPF needs include:spf.protection.outlook.com, plus the static IPs of any relay-connector sources; stacking services is how domains hit the 10-lookup ceiling. Enable DKIM signing for the domain in the Defender portal and publish the two CNAME selector records it issues. Publish DMARC, because the mailbox providers' sender requirements expect it and because its reports are how you discover which devices are sending unauthenticated. Verify the whole triad with the email authentication checker and re-run the email DNS check after every connector change. Reverse DNS matters too for relay-connector sources; confirm yours with the reverse DNS checker.

Choosing, in one pass

License-bound, low volume, external reach needed: SMTP AUTH. Unattended device mailing your own staff: direct send. Servers with a certificate or static IP sending application mail as the domain to anyone: relay connector. Marketing campaigns, newsletters, or transactional volume beyond the documented allowances: none of the above. Move that stream to a sending platform, put it on its own subdomain so its reputation is accounted apart from corporate correspondence, ramp it per IP warming practice, and compare providers as a category through our deliverability benchmark rather than on marketing claims. If Outlook-side placement is the worry driving the migration, register your sending IPs with Microsoft SNDS and watch the verdicts directly.

The tenant-side hygiene deserves one paragraph of its own. Every door you are not using is attack surface. Microsoft leaves SMTP AUTH disabled for organizations created after January 2020 and documents enabling it per mailbox; keep it that way, switching it on only for mailboxes whose workload genuinely needs it, since credential-stuffing against legacy SMTP endpoints is a standing abuse pattern. Inventory which systems use which door, alert on unexpected volume from any of them, and read your DMARC reports monthly to confirm the list of sources sending as your domain matches the list you wrote down. A compromised device relaying spam through your tenant damages the same sender reputation every legitimate stream depends on, and it is far cheaper to notice in a report than in a blocklist listing.

Related guides

• Sending email through Google Workspace — the same decision on the other office suite
• SMTP relay — relaying mechanics beyond any one vendor
• Microsoft SNDS — Microsoft's own data on how its filters treat your IPs
• Outlook sender requirements — the rules on the receiving side of Microsoft's ecosystem
• Email subdomain — where a bulk stream should live when it outgrows M365
• Email authentication checker — verify SPF, DKIM and DMARC across every door

About this guide

Written by InboxRatio Editorial. The three options, their authentication models, the SMTP AUTH limits (30 messages per minute, 10,000 recipients per day), direct send's internal-recipient scope, connector behavior, and the HVE and Azure Communication Services pointers all follow Microsoft's published Exchange Online documentation, checked in September 2026, which is authoritative if details change. This guide addresses legitimate application mail, not quota- or filter-evasion. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on Microsoft's documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

6 October 2026. Microsoft documentation and limits reviewed quarterly.

Frequently asked questions

What is the Office 365 SMTP relay? The connector-based relay option in Exchange Online: an administrator registers your application servers by static IP or certificate, and mail from them relays through Microsoft 365 to internal and external recipients as your domain, without authenticating as a mailbox.

What are the Microsoft 365 SMTP sending limits? For SMTP AUTH client submission, Microsoft documents 30 messages per minute and 10,000 recipients per mailbox per day. Connector relay has no published fixed daily cap; Microsoft states that reasonable limits apply and that it can't be used for bulk mail.

What is the difference between direct send and SMTP relay in Microsoft 365? Direct send delivers unauthenticated device mail to your MX endpoint for recipients inside your organization only. The relay connector, configured with your servers' IPs or a certificate, relays to external recipients too. Reach is the deciding difference.

Which option should a scanner or printer use? If it only emails people in your tenant, direct send is the lightest fit. If it must reach outside addresses and can present a certificate or a static source IP, the relay connector; if it can hold mailbox credentials and volumes are small, SMTP AUTH.

Can I send newsletters through Microsoft 365? No. Microsoft's documentation states that connector relay can't be used for bulk mail, and SMTP AUTH stops at 10,000 recipients a day. Campaign mail lacks its required unsubscribe and complaint machinery in Exchange Online and puts your corporate domain's reputation behind it; use an ESP on a subdomain.

Why does mail from my relay connector go to spam? The connector moves mail; it does not authenticate your domain. Add the source IPs to SPF, enable DKIM in the Defender portal, publish DMARC, and confirm reverse DNS on the sending IPs. Then check the content and list-quality layer like any other stream.

Pick the door by workload, not by whichever settings screen accepted credentials first. The scanner, the CRM and the newsletter each have a correct answer, and the email DNS check will tell you whether the domain records behind your choice are finished.