Microsoft 365 SMTP Setup: Authenticated Submission, Relay and Connectors

Three ways to send, and choosing between them

Microsoft 365 offers three distinct sending methods and picking the wrong one is the root cause of most configuration pain. Decide this before you touch any settings.

Most developers want the first. Scanners and printers usually want the second. Enterprise line-of-business systems want the third.

SMTP AUTH client submission

Server:      smtp.office365.com
Port:        587
Encryption:  STARTTLS (required)
Username:    full UPN, e.g. app@yourcompany.com
Password:    mailbox password, app password, or OAuth token

Only port 587 with STARTTLS is supported. Port 465 is not offered. The username must be the full User Principal Name — the sign-in address — which is not always the same as the primary SMTP address on the mailbox.

The mailbox also needs a licence. An unlicensed or shared mailbox cannot authenticate for SMTP submission.

Enabling Authenticated SMTP (the step everyone misses)

Microsoft disables SMTP AUTH by default on all tenants created since 2020, and has been progressively disabling it on older tenants too. A perfectly correct configuration will still return 535 until it is switched on.

Per mailbox, via the admin center:

1. Open the Microsoft 365 admin center → Users → Active users.
2. Select the user, open the Mail tab.
3. Click Manage email apps.
4. Tick Authenticated SMTP and save.

Per mailbox, via PowerShell:

Set-CASMailbox -Identity app@yourcompany.com -SmtpClientAuthenticationDisabled $false

Check the tenant-wide default:

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

If the tenant-wide setting is $true, per-mailbox enablement still works — the mailbox setting overrides the tenant default. Enable it per mailbox rather than turning it on tenant-wide; that keeps the attack surface small.

Changes can take up to an hour to propagate.

Security defaults and conditional access

Even with Authenticated SMTP enabled, two tenant-level policies can block basic authentication entirely:

• Security defaults, which Microsoft enables automatically on new tenants, blocks legacy authentication protocols including SMTP AUTH.
• Conditional access policies requiring MFA cannot be satisfied by an SMTP client, because there is no way to present a second factor mid-session.

If either applies, password-based SMTP will never succeed regardless of what you configure on the mailbox. Your options are OAuth 2.0, a high-volume connector, or a conditional access exclusion scoped tightly to the service account and its source IP addresses.

OAuth 2.0 for SMTP AUTH

Microsoft supports XOAUTH2 for SMTP, and it is the recommended path for new applications.

1. Register an application in Microsoft Entra ID → App registrations.
2. Add the API permission Office 365 Exchange Online → SMTP.SendAsApp (application permission) and grant admin consent.
3. Create a client secret or upload a certificate.
4. Register the service principal in Exchange Online and grant it access to the specific mailboxes it may send as — application permissions are tenant-wide by default, so scoping with New-ManagementRoleAssignment and an application access policy is essential.
5. Acquire a token from https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token with the scope https://outlook.office365.com/.default.
6. Authenticate using XOAUTH2.

Tokens are valid for roughly an hour. Cache and refresh proactively rather than waiting for an authentication failure.

Direct send

Direct send skips authentication entirely. Your device connects to the tenant's MX endpoint and delivers straight to internal recipients.

Server:      yourcompany-com.mail.protection.outlook.com
Port:        25
Encryption:  STARTTLS
Auth:        none
From:        must be a domain accepted by your tenant
Recipients:  internal only

Find the exact hostname in your tenant's MX record. Requirements:

• A static public IP.
• That IP listed in the domain's SPF record.
• The From address on a domain verified in the tenant.
• Reverse DNS configured for the sending IP.

Direct send cannot deliver to external recipients and is subject to a limit of 30 messages per minute per IP. It is the right answer for a scanner emailing internal staff, and the wrong answer for anything customer-facing.

High-volume SMTP relay connector

For applications that need to send externally at volume without per-user credentials, create an inbound connector in the Exchange admin center.

1. Exchange admin center → Mail flow → Connectors → Add a connector.
2. Connection from: Your organization's email server. Connection to: Office 365.
3. Authenticate by IP address (list your static public IPs) or by TLS certificate with a subject name matching a verified domain.
4. Require TLS.

Then add those IPs to your SPF record. A certificate-based connector is more robust than IP-based because it survives IP changes, but it requires a certificate issued to a domain you have verified in the tenant.

Connectors bypass the per-mailbox sending limits that apply to authenticated submission, which is exactly why they exist.

Limits

The 3-concurrent-connection cap is the one that surprises people. A worker pool of ten threads all opening SMTP connections to the same mailbox will produce 421 errors under load. Keep the pool at two or three, or move to a connector.

Error reference

### 535 5.7.3 Authentication unsuccessful

• Authenticated SMTP is disabled for the mailbox. Enable it.
• Security defaults or conditional access is blocking basic authentication.
• The username is not the UPN.
• The mailbox is unlicensed.
• The password expired or the account is locked.

### 550 5.7.60 Client does not have permissions to send as this sender

The authenticated account is not permitted to send as the From address. Either send as the authenticated mailbox itself, or grant Send As permission:

Add-RecipientPermission -Identity shared@company.com -Trustee app@company.com -AccessRights SendAs

### 550 5.7.64 TenantAttribution; Relay Access Denied

The connector did not match your connection. Usually the source IP is not in the connector's list, or the outbound IP changed. Verify the IP the tenant actually sees.

### 451 4.7.500 Server busy

Throttling. Reduce concurrency and add backoff.

### 421 4.3.2 Service not available

Connection limit exceeded — you have more than three concurrent connections to the mailbox.

### 550 5.4.1 Recipient address rejected: Access denied

The recipient does not exist in the tenant, or a mail flow rule blocked it.

SPF, DKIM and DMARC for Microsoft 365

SPF for a tenant using Microsoft 365 exclusively:

v=spf1 include:spf.protection.outlook.com -all

Add ip4: entries for any servers using direct send or a connector.

DKIM is not enabled by default. Enable it per domain in the Microsoft 365 Defender portal under *Policies → Email authentication settings → DKIM*, which requires publishing two CNAME records:

selector1._domainkey  ->  selector1-<domain-key>._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey  ->  selector2-<domain-key>._domainkey.<tenant>.onmicrosoft.com

Microsoft rotates between the two selectors automatically, so both must be present. Then publish DMARC starting at p=none and tighten once reports are clean.

Choosing the right path

• Application sending as a real mailbox, modest volume → SMTP AUTH on 587, OAuth if possible.
• Printer or scanner, internal recipients only → direct send.
• Line-of-business system, external recipients, high volume → inbound connector.
• Marketing or bulk campaigns → not Microsoft 365 at all; use a dedicated provider.

Whichever path you take, verify the transport before you deploy. Running smtp.office365.com:587 through SMTPTester with your exact credentials tells you in seconds whether Authenticated SMTP is genuinely enabled, whether TLS negotiates, and whether a conditional access policy is silently blocking you — questions your application logs will not answer clearly.