Is smtp.office365.com the Office 365 SMTP server?

Yes. Microsoft documents smtp.office365.com for authenticated client SMTP submission to Exchange Online. Other Microsoft sending methods use different endpoints and authorization models.

Should Office 365 SMTP use port 587?

Yes. Microsoft recommends port 587 with STARTTLS for client submission and also lists port 25. Match the documented method and transport rather than substituting port 465 from another provider.

Can Office 365 SMTP use OAuth?

Yes. Microsoft documents OAuth support for SMTP AUTH. The tenant registration, permissions, and token flow are account-specific, so follow the application's current Microsoft integration instructions.

Can one mailbox send to 10,000 recipients per day?

Only within Microsoft's documented recipient-rate limit and other service controls. The 10,000 figure is a ceiling over a rolling period, not a recommended bulk-mail design or deliverability promise.

Can I send as a shared mailbox after authenticating as a user?

Yes, when the authenticated account has the required Send As permission and the method is supported. Validate the delivered From, SPF, DKIM, and DMARC results rather than assuming permission creates alignment.

Office 365 SMTP settings and authentication

For Microsoft 365 client SMTP submission, use smtp.office365.com, port 587, and STARTTLS. Authenticate with an Exchange Online mailbox, prefer OAuth when the application supports it, and confirm that tenant and mailbox policy allow SMTP AUTH. If the visible From address differs from the authenticated mailbox, it needs Send As permission. After submission works, validate SPF, DKIM, DMARC, headers, service limits, and actual delivery.

At a glance

Quick takeaways

Microsoft recommends smtp.office365.com with STARTTLS on port 587 for client submission.
Tenant security policy and the mailbox's Authenticated SMTP setting can block otherwise correct values.
Prefer OAuth; do not broadly enable legacy authentication to rescue one application.
Exchange Online documents 30 messages per minute and 10,000 recipients per day for a mailbox.
SMTP acceptance does not prove DMARC alignment or inbox placement.

This guide is part of Palisade's ESP setup hub. It covers Exchange Online client submission, not an on-premises Exchange receive connector or a consumer Outlook.com recovery flow.

What should I check before configuring Office 365 SMTP?

Confirm that the sender has an Exchange Online mailbox, the application supports STARTTLS and an approved authentication method, and the tenant owner authorizes the use. Record the visible From address, authenticated mailbox, expected recipient volume, message type, and any Send As requirement.

Microsoft's current client-submission guidance lists smtp.office365.com, port 587 recommended or port 25, TLS/STARTTLS enabled, and mailbox credentials. It also says the application should send from the same address used to authenticate unless the account has Send As permission (Microsoft: Client SMTP submission).

Check policy before changing the application. Microsoft says SMTP AUTH supports modern OAuth and basic authentication, can be disabled at the organization level, and can be enabled for mailboxes that still require it. Security defaults can disable SMTP AUTH, while authentication policies can block basic authentication (Microsoft: Enable or disable authenticated client SMTP submission). Do not disable a tenant-wide security control merely to make a legacy client connect.

Which setup method should I use?

Use client SMTP submission when an application can authenticate as a licensed mailbox and the service limits match the workload. Prefer an OAuth-capable integration when available. Use a different Microsoft-documented method when a device cannot authenticate, the workload is application-wide, or the traffic is high-volume. Do not treat port 25 as a way around authorization.

The current Microsoft settings table anchors the endpoint and transport values.

Microsoft Learn table showing the Microsoft 365 client SMTP submission endpoint, port, TLS, and authentication requirements — Source: Current first-party configuration table from Microsoft Learn, captured August 25, 2026; this is documentation evidence, not a tenant screen.

Confirm client submission is the intended method before changing SMTP AUTH.

Microsoft's Exchange Online limits page says legitimate bulk commercial email should use a specialized third-party provider rather than Exchange Online mailboxes (Exchange Online limits). A working test at low volume does not make a mailbox suitable for a marketing platform.

How do I configure Office 365 SMTP?

1. Define one controlled sender

For a worked example, suppose alerts@example.com is an Exchange Online mailbox. The application will send 240 transactional alerts per day, use visible From alerts@example.com, and send one test to Microsoft 365 plus one mailbox outside the tenant. Run identifier o365-smtp-630184 contains no customer data.

2. Enter the endpoint and transport

Set server smtp.office365.com, port 587, and STARTTLS. Require certificate validation. Do not choose implicit SSL merely because another provider uses port 465; Microsoft's client-submission table specifies TLS/STARTTLS for this workflow.

3. Configure OAuth or an approved credential

Use the application's documented Microsoft OAuth flow when supported. Tenant ID, application registration, client identifiers, scopes, secrets, certificates, and tokens are account-specific. Never copy a registration from another tenant or store a client secret in source control. If the application supports only basic authentication, confirm that the tenant and mailbox explicitly permit it and record the exception owner.

4. Limit SMTP AUTH to the required mailbox

If organization-level SMTP AUTH is disabled but the approved application requires it, an authorized administrator can enable Authenticated SMTP for the specific mailbox. Microsoft documents the Microsoft 365 admin center path through Users, Active users, the user, Mail, Manage email apps, then Authenticated SMTP (Microsoft SMTP AUTH controls). Tenant security defaults or authentication policy can still take precedence.

The first-party Admin Center capture shows the material control in a sample mailbox.

Microsoft 365 admin center Manage email apps panel showing the Authenticated SMTP mailbox control — Source: Microsoft-published Admin Center capture in Microsoft Learn, captured August 25, 2026; the sample mailbox is SAP-specific and does not establish the right policy for another tenant.

Apply account-specific authorization only to the required mailbox.

5. Confirm the From identity and Send As permission

Keep From equal to alerts@example.com for the first test. If the application authenticates as service@example.com but sends as alerts@example.com, grant the narrow Send As permission through the authorized Exchange workflow. Microsoft says the service returns 5.7.60 when the authenticated account lacks that permission in this client-submission scenario (Microsoft client submission).

6. Send one traceable test

Use subject SMTP validation 2026-08-25 14:30 UTC and include o365-smtp-630184 in a non-secret diagnostic line. Record connection time, server response, authenticated mailbox, From, recipient, and application version. Never record a password, access token, client secret, or private message body.

How does the setup affect DMARC?

SMTP AUTH controls application access to Exchange Online. DMARC evaluates whether SPF or DKIM authentication aligns with the visible From domain. One can succeed while the other fails.

Microsoft's SPF guidance says most Microsoft 365 organizations that send only through the service use an SPF policy containing include:spf.protection.outlook.com. The full illustrative value is v=spf1 include:spf.protection.outlook.com -all, but a domain with other senders must combine all authorized sources into one SPF record and remain within the 10-lookup limit (Microsoft SPF configuration). Do not publish a second SPF record or copy a policy that omits real senders.

Microsoft 365 DKIM uses two selector CNAMEs so one selector can sign while the other supports rotation. Current Microsoft documentation tells administrators to retrieve tenant-specific CNAME targets from Defender or Exchange Online PowerShell and warns against copying the example values because newer domains can use a different target format (Microsoft DKIM configuration). Never use another tenant's targets.

RFC 9989 Section 4.4 define alignment and the DMARC pass condition: at least one supported mechanism must authenticate and align with the RFC5322 From domain (RFC 9989). A message accepted from alerts@example.com can still fail DMARC if the observed SPF and DKIM identifiers do not align with example.com.

How do I validate the setup?

Check DNS values

Query the single SPF record, both Microsoft DKIM selector CNAMEs, and _dmarc.example.com from public resolvers. Compare tenant-specific targets exactly. DNS presence does not prove the application used the intended path or that Microsoft signed the message.

Check vendor and mailbox status

Confirm the approved mailbox exists, SMTP AUTH state matches the documented exception, tenant policy permits the chosen method, and Send As permission exists only where required. Record who approved any basic-authentication exception and its review date.

Check the delivered message headers

Open the raw source and use the receiver-added Authentication-Results. RFC 8601 Section 1.2 explains the receiver trust boundary; do not trust a field merely because it is present (RFC 8601, Section 1.2). Confirm the actual smtp.mailfrom, DKIM header.d, visible header.from, and reported DMARC result. Use Palisade's Email Header Analyzer to parse supplied headers; it cannot inspect Entra credentials or tenant policy.

Check DMARC reporting and delivery

Confirm the authorized Microsoft source appears in aggregate DMARC data for the visible From domain. Send the same controlled test to an external mailbox and examine acceptance, authentication, folder placement, and any enhanced status code. The Office 365 DMARC setup guide covers policy deployment, while DKIM for Office 365 covers signing in more depth.

If the message-level test works but the tenant still lacks source-wide visibility, Palisade's DMARC Agent can organize aggregate DMARC evidence for the domain. Smart DNS Deployment can write only DNS records a human approves. It does not change Exchange, Entra, mailbox, or SMTP AUTH settings and cannot guarantee placement. Start with Palisade after the controlled send establishes that monitoring is the next gap.

Troubleshooting

The server rejects authentication

Confirm the server and STARTTLS settings, then determine whether security defaults, organization-level SMTP AUTH, mailbox state, or authentication policy blocks the chosen method. Do not repeatedly retry a secret or weaken tenant policy without an approved exception.

Send As returns 5.7.60

Keep the From equal to the authenticated mailbox or grant the narrow Send As permission to the required identity. Do not grant broad impersonation rights to solve one sender mismatch.

The client is throttled

Microsoft documents 30 messages per minute, 10,000 recipients per day, and up to 3 concurrent SMTP connections for client submission. Its SMTP improvements page shows 432 4.3.2 Concurrent connections limit exceeded for excess concurrency and a SubmissionQuotaExceededException after the recipient limit (Microsoft SMTP submission limits). Queue and pace mail rather than opening more connections.

The message sends but DMARC fails

Compare the From domain with header.d and smtp.mailfrom. Verify the Microsoft DKIM selectors and the actual return path. Do not relax DMARC policy as a substitute for repairing an unaligned sender.

The message is accepted but does not land as expected

Check the exact recipient outcome, service responses, authentication, reputation, consent, and message purpose. Exchange acceptance is not an inbox guarantee, and changing the port will not repair reputation or targeting.

When does this setup not apply?

This workflow does not cover on-premises Exchange connectors, direct send to a Microsoft 365 MX endpoint, high-volume email, consumer Outlook.com accounts, or software that cannot meet the tenant's transport and authentication policy. Select an appropriate architecture rather than creating a permanent broad exception.

Evidence