Connection settings
The server is smtp.office365.com on port 587 with STARTTLS at TLS 1.3 or 1.2, per Microsoft's device and application guide.
The username is the full email address of a licensed mailbox. Client submission requires a licence, so an unlicensed or shared mailbox cannot be used this way.
Port 465 is not supported on this path. Microsoft states that a device defaulting to it does not support the TLS versions required for client submission.
Enabling SMTP AUTH
The setting exists at two levels, and both must permit it.
Per mailbox, it is enabled through the Microsoft 365 admin centre on the individual account, or through Exchange Online PowerShell by setting the mailbox's SMTP client authentication property. Microsoft documents the procedure under authenticated client SMTP submission.
At the organisation level, a tenant-wide block can be lifted through Exchange Online PowerShell using the transport configuration setting for SMTP client authentication. Where the tenant blocks it, enabling the per-mailbox setting alone has no effect, which is the configuration that produces the most confusing failures.
Security defaults in Microsoft Entra ID also disable legacy authentication protocols, so a tenant with those enabled will refuse basic-auth SMTP regardless of either setting.
Authentication method
Basic authentication with a username and password still works on many tenants and is on a deprecation path. Microsoft recommends OAuth, carried over the XOAUTH2 mechanism, and treats basic auth as legacy.
Where multi-factor authentication applies to the account, an app password is required rather than the account password, and organisational policy may prohibit app passwords entirely.
Anything built to last should target OAuth. A working basic-auth integration today has a deadline attached to it that Microsoft rather than you controls.
Limits on this path
Client submission is throttled at 10,000 recipients per day and 30 messages per minute. Those figures are per mailbox and sized for a person rather than an application.
Exceeding them results in throttling rather than a clear error, which presents as intermittent failures that are difficult to attribute to a quota.
Mail sent this way authenticates as one licensed mailbox and appears from that address, carrying that mailbox's reputation rather than a domain identity you manage separately.
Volume brings its own bar. George, our CEO, wrote it into his Email Marketing Bible after a decade running SmartrMail: past 5,000 messages a day, Outlook requires SPF, DKIM and DMARC aligned, with the DMARC policy at p=quarantine or stronger. A licensed mailbox on client submission never clears that bar for application mail, because the identity is the mailbox, not a domain you control.
When to use a different method
Microsoft documents two alternatives for higher volume. SMTP relay through an inbound connector authenticates by certificate or static IP on port 25, requires no licensed mailbox and carries higher limits, though it cannot be used from a third-party hosted service. High Volume Email covers large internal sending.
Any relay endpoint is an abuse target, which shapes how we run our own. On Nitrosend's forwarding relay, TCP 2525 is firewalled to our API host, TLS and exact SMTP authentication are mandatory, and unsigned or replayed requests, extra recipients and arbitrary destinations are rejected. Microsoft's certificate-or-IP gate on the inbound connector exists for the same reason.
For application mail generally, a submission service authenticating as a verified sending domain avoids the licence requirement, the per-mailbox throttle and the deprecation timeline, and supplies the per-message delivery events, bounce classification and suppression handling that client submission does not report.
We profile the email stack behind every domain that signs up to Nitrosend, a DNS MX lookup says immediately whether a company lives on Microsoft 365, and those records are what this page's advice is calibrated against rather than guesswork.