Microsoft 365 SMTP Settings and How to Configure Them

If you just need the values to paste into an app, here they are for client SMTP submission through Microsoft 365.

This is the SMTP AUTH client submission method, the right choice when a single application sends as one specific mailbox. Microsoft documents these values in its SMTP AUTH client submission reference. The rest of this guide explains the prerequisites, the alternatives for higher volume, and the limits, because the values above will silently fail if SMTP AUTH is disabled on the tenant.

Microsoft turned off SMTP AUTH by default for new tenants and as part of its security defaults initiative. So even with perfect settings, you may hit an authentication error like 550 5.7.1 or a smtp client authentication disabled message. If that happens, the protocol is switched off, not your credentials.

There are two layers that can block you:

1. 1Tenant-level. Security defaults or an organization-wide policy disables SMTP AUTH for everyone.
2. 2Mailbox-level. SMTP AUTH is enabled tenant-wide but switched off for the specific mailbox you are using.

Both must allow SMTP AUTH for client submission to work. The next section covers enabling it. If you see a 550 5.7.1 bounce, our SMTP 550 5.7.1 error fix walkthrough helps you read the exact variant.

You enable SMTP AUTH per mailbox (and confirm it is not blocked tenant-wide). An administrator does this; a regular user cannot.

Per mailbox, via the admin center:

1. 1Sign in to the Microsoft 365 admin center.
2. 2Go to Users > Active users and select the mailbox.
3. 3Open the Mail tab, then Manage email apps.
4. 4Check Authenticated SMTP and save.

Per mailbox, via PowerShell (Exchange Online):

Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

Tenant-wide check (only re-enable broadly if your security posture allows it):

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
Set-TransportConfig -SmtpClientAuthenticationDisabled $false

Leaving SMTP AUTH off tenant-wide and enabling it only on the specific sending mailboxes is the safer pattern. Changes can take up to an hour to apply.

SMTP AUTH client submission uses basic credentials, but Microsoft 365 mailboxes increasingly require multi-factor authentication. Basic auth and MFA do not mix directly, so you need an app password: a generated credential that lets a single app authenticate without completing the MFA prompt. An app password is a long random string tied to one mailbox; if it leaks you revoke just that string rather than changing the account password, which is why it is treated as a per-application secret.

To use an app password:

1. 1The mailbox must have MFA enabled and app passwords allowed by tenant policy. Some tenants disable app passwords entirely under modern authentication policies.
2. 2The user generates an app password from their My Account > Security info page.
3. 3Use the full mailbox address as the username and the app password (not the regular password) in your SMTP client.

Two practical traps catch people here. First, app passwords are displayed in spaced groups for readability, and pasting those spaces into the password field causes a 535 authentication failure; strip them. Second, an app password only works if SMTP AUTH is also enabled for that mailbox, so a valid app password against a mailbox with Authenticated SMTP switched off still fails. Both conditions must be true at once.

If your tenant has fully moved to modern authentication and blocks app passwords, SMTP AUTH client submission may not be available at all, and you should use OAuth-based sending (XOAUTH2) or one of the relay options below. OAuth avoids storing a long-lived password by exchanging a token that can be scoped and revoked, but it requires the sending application to support the flow. This is a common friction point, and it is one reason teams running cold email at scale often choose mailbox infrastructure where authentication is handled for them.

SMTP AUTH client submission is meant for low-volume, single-mailbox sending. For more, Microsoft offers two other paths.

High Volume Email (HVE) is Microsoft's service for internal bulk mail (line-of-business apps sending to recipients in the same organization), with higher throughput than standard client submission. It is aimed at internal communications, not external cold outreach.

SMTP relay via a connector lets devices and apps send through your tenant using a connector that authenticates by source IP or certificate rather than per-mailbox credentials. This suits printers, scanners, and internal apps that cannot hold mailbox passwords. The connector points at a different endpoint (your tenant's MX-style host rather than smtp.office365.com) and trusts the source instead of a login, which is why it is the standard answer for a copier that needs to email scans but has no mailbox of its own. The trade-off is that a connector authenticated by IP is only as safe as the network it trusts, so it is scoped tightly to known addresses.

For a fuller treatment of relay versus direct sending, see SMTP relay vs SMTP server. None of these change the fact that external mail must pass authentication, covered next.

Whatever sending method you pick, external recipients (Gmail, Yahoo, other Microsoft tenants) check that your mail is authenticated. Since the Google and Yahoo sender requirements took effect, this is mandatory.

• SPF. Add Microsoft's include to your domain's SPF record so its servers are authorized. See SPF record setup for cold email.
• DKIM. Enable DKIM signing for your custom domain in the Microsoft Defender portal, then publish the two CNAME records Microsoft gives you. See DKIM setup for cold email.
• DMARC. Publish a DMARC record so receivers know how to handle failures. See DMARC setup for cold email.

Microsoft applies SPF automatically for mail sent through the service, but DKIM for a custom domain must be turned on manually, and many bounce problems trace back to DKIM never being enabled. The full picture is in SPF, DKIM, and DMARC explained.

Microsoft 365 enforces caps to protect the platform. Exceeding them causes throttling and then rejection, no matter how clean your configuration is.

These are platform protections; the practical cold email ceiling is much lower because reputation, not the hard cap, governs how many messages actually reach the inbox. Pushing toward the hard limit on a fresh mailbox triggers throttling and spam filtering long before you hit the number. A brand-new mailbox sending fifty cold messages on day one will see deferrals and spam placement that a warmed mailbox sending the same volume would not, because the receiver has no history to trust yet.

A worked illustration: suppose you want to reach 1,000 prospects a day. Doing that from a single Microsoft 365 mailbox sits far under the 10,000 recipient cap on paper, yet in practice it scorches the mailbox, because no warmed cold-email mailbox should send anywhere near that volume. Spreading the same 1,000 across, say, twenty or more warmed mailboxes keeps each one at a modest, believable daily figure and protects the reputation of every domain involved. The hard cap is a ceiling you should never approach, not a target. Compare the providers in email sending limits for Google and Microsoft and plan realistic per-mailbox volume in our sending volume limits guide.

The durable approach for cold email is many mailboxes each sending modest, warmed volume, rather than one mailbox pushed to its cap.

A working Microsoft 365 cold email setup needs all of these aligned:

1. 1Correct SMTP settings: smtp.office365.com, port 587, STARTTLS.
2. 2SMTP AUTH enabled on the sending mailbox (or a relay connector configured).
3. 3App password generated if MFA is on, or OAuth where required.
4. 4SPF, DKIM, and DMARC published and passing.
5. 5Warmup run on each mailbox before real sending, per the cold email warmup guide.
6. 6Volume kept well under the platform caps, spread across mailboxes.

That is a lot of moving parts, and Microsoft's shift away from basic auth makes the authentication piece harder every year. InboxKit provisions real Microsoft 365 (and Google Workspace and Azure) mailboxes on US IPs with SPF, DKIM, DMARC, and MX configured automatically through Cloudflare in under sixty seconds, plus isolated warmup, so the checklist above is handled rather than assembled by hand. If you configure it yourself, this list is still the order to work through. Microsoft-specific spam problems are covered separately in our Microsoft 365 cold email spam fix.