Microsoft 365 Server Settings: IMAP, SMTP, POP, Outlook

If you just want the exact Microsoft 365 server settings, I’ll give you the copy/paste values. But if you’re responsible for keeping email reliable and secure for a business, the faster win is knowing when you actually need manual settings - and when to let Microsoft 365 do the heavy lifting. Here’s the operator’s field guide to finding, validating, and safely using Microsoft 365 (Exchange Online) server settings for IMAP, POP, SMTP, Outlook, and mobile - without getting burned by security defaults or legacy protocols.

Most modern Microsoft 365 accounts don’t need manual server names at all. Outlook (Windows/Mac/mobile) uses Autodiscover and modern authentication to connect automatically. If a user types their email and password (or gets SSO), Outlook figures out the rest. No ports and hostnames to memorize.

So why do people still ask for server settings? Usually three reasons: connecting older email clients (IMAP/POP), wiring up devices (printers, scanners) that send mail, or integrating third‑party tools that can only talk SMTP. All three sit outside Microsoft’s preferred path, which means you’ll hit security guardrails: Basic Auth disabled, protocols turned off per mailbox, or tenant-level SMTP AUTH blocked.

The practical approach: decide if you actually need manual settings. If the client or device supports “Office 365” or “Exchange” as an account type, use that. If you must use IMAP/POP/SMTP, confirm the protocol is enabled, understand the security trade-offs, and copy the right hostname/port combo once. The rest of this guide walks you through it.

If you don’t have admin rights and only need your own settings, go to Outlook on the web (OWA). Microsoft surfaces IMAP/POP/SMTP details there, but expects most people to use automatic setup. UI labels move around, so here’s the current pattern that consistently works:

Method 1 - Outlook on the web: Sign in at outlook.office.com. Select the gear icon (Settings) > Mail (view all Outlook settings) > Accounts > POP and IMAP. You’ll see server names, encryption, and ports. If POP/IMAP are disabled for your mailbox, this page tells you. Copy the values if your app truly requires them.

Method 2 - Outlook desktop: Recent Outlook builds no longer expose raw server names because they’re unnecessary for Exchange Online. If you’re asked for manual settings during setup, stop - use the “Microsoft 365” or “Exchange” account type and sign in with your work account. Manual IMAP/POP in Outlook is a last resort and cuts you off from calendar, contacts, categories, shared mailboxes, and advanced features.

Admins should verify why a connection is failing before sharing server names. Two toggles commonly block legacy connections: tenant-wide SMTP AUTH and per-mailbox protocol settings.

Step 1 - Check tenant SMTP AUTH: SMTP AUTH is often disabled by default in newer tenants. Use Exchange Online PowerShell to confirm.

Commands to run (from a PowerShell session):

Connect-ExchangeOnline
Get-TransportConfig | fl SmtpClientAuthenticationDisabled

If SmtpClientAuthenticationDisabled is True, SMTP AUTH is blocked tenant-wide. To allow SMTP AUTH at the tenant level (while still controlling it per mailbox), set it to False:

Set-TransportConfig -SmtpClientAuthenticationDisabled $false

Step 2 - Check mailbox protocol status: POP/IMAP can be disabled per mailbox, and SMTP AUTH can also be disabled per mailbox regardless of tenant settings.

Get-CASMailbox user@domain.com | fl PopEnabled,ImapEnabled,SmtpClientAuthenticationDisabled,ActiveSyncEnabled,MAPIEnabled

Enable only what you truly need, ideally for a dedicated service mailbox instead of a user’s account:

Set-CASMailbox user@domain.com -ImapEnabled $true -PopEnabled $false -SmtpClientAuthenticationDisabled $false

Step 3 - Confirm service health: If protocols look right but login still fails, check Service Health in the Microsoft 365 admin center to rule out regional incidents. Also validate sign-in is allowed for the user (conditional access, security defaults, location/IP restrictions).

If you must manually configure a client or app, these are the standard Exchange Online endpoints for most commercial tenants. Use your full email address as the username.

• IMAP (receive): Server outlook.office365.com, Port 993, Encryption SSL/TLS
• POP (receive): Server outlook.office365.com, Port 995, Encryption SSL/TLS
• SMTP AUTH submission (send): Server smtp.office365.com, Port 587, Encryption STARTTLS
• Exchange ActiveSync (mobile): Typically autodiscovered; fallback server outlook.office365.com

Notes that save you hours:

- Outlook desktop and the Outlook mobile app do not need these manual values - use the Microsoft 365/Exchange account type and sign in. You’ll get modern auth, calendar, and admin controls automatically.

- Many tenants have POP/IMAP disabled at the mailbox level, and Basic Auth for those protocols is retired. Only use IMAP/POP with clients that support OAuth 2.0 for Exchange Online. For anything else, use Outlook or Exchange account type instead.

- SMTP AUTH may be disabled tenant-wide or per mailbox. It also doesn’t support modern MFA in most devices. For reliability and security, use a dedicated mailbox for SMTP AUTH, lock it to known IPs, and monitor it.

Devices and legacy apps usually can’t sign in with modern auth. Microsoft recognizes this and supports three patterns. Pick the one that fits your risk tolerance and routing needs.

Option A - SMTP AUTH submission (smtp.office365.com:587): Your device signs in with a dedicated Microsoft 365 mailbox and sends mail to internal and external recipients. This requires SMTP AUTH enabled for the mailbox and not blocked tenant-wide. Secure it with a strong, rotated password, IP restrictions via conditional access (where applicable), and mailbox monitoring.

Option B - Direct Send (via your MX endpoint on port 25): Configure the device to send to your domain’s MX record (e.g., yourdomain-com.mail.protection.outlook.com). No authentication is used; messages can only be sent to recipients in your own domains. It’s simple and avoids credentials, but you can’t send to external recipients and some networks block outbound port 25.

Option C - On-premises relay (hybrid or SMTP relay server): Point devices at a local relay that authenticates to Exchange Online (Option A) or relays direct to your MX (Option B). This centralizes logging and access control, reduces device complexity, and lets you swap credentials without touching every printer.

Operator pick: For most SMEs, Option A with a dedicated mailbox is the fastest path. Name the mailbox something explicit (e.g., relay@yourdomain.com), restrict it, and keep credentials in your secrets manager. If you can’t lock IPs or you need internal-only routing, Option B is acceptable.

Microsoft retired Basic Authentication for Exchange protocols like IMAP, POP, and EWS. That’s good for your security posture, but it breaks older clients that only know username/password prompts. Here’s how to stay operational without backsliding on security.

- Prefer Outlook or native “Microsoft 365/Exchange” account types. They support modern auth (OAuth 2.0), device compliance, conditional access, and all the collaboration features users expect.

- If a non-Microsoft client must use IMAP/POP, confirm it supports OAuth with Exchange Online. Many do now, but not all. If it doesn’t, you’re forcing a workaround that likely won’t pass compliance reviews.

- SMTP AUTH remains available but should be used sparingly with a dedicated mailbox, long random password, minimal permissions, and IP/conditional access restrictions. Avoid app passwords and broad exceptions. Don’t enable SMTP AUTH for every user; you don’t need that blast radius.

Even the best server settings won’t help if your DNS is misconfigured. Autodiscover and routing depend on a short list of records. Verify these in your DNS host and the Microsoft 365 admin center under Settings > Domains.

Core records to check:

• MX: yourdomain-com.mail.protection.outlook.com (the exact value is tenant-specific)
• SPF (TXT): v=spf1 include:spf.protection.outlook.com -all
• Autodiscover (CNAME): autodiscover.outlook.com
• Optional: DKIM CNAMEs (two records), DMARC TXT (e.g., v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com)

Tips:

- After updating DNS, give it time. TTLs and registrar propagation can take minutes to hours. Test from a network that’s not caching old values.

- If Autodiscover fails, Outlook falls back to less efficient discovery paths. That’s when users start asking for manual server names. Fixing Autodiscover is usually the better move.

- Sovereign clouds (GCC High, 21Vianet in China) use different endpoints. If your users are in those environments, fetch the exact records from your admin center instead of assuming the commercial defaults.

Login works on the web but not in the device? Password’s correct but auth keeps looping? These are the usual suspects, in order.

1) SMTP AUTH blocked: Tenant or mailbox-level block will cause immediate failures when a device tries smtp.office365.com:587. Confirm with PowerShell and enable only for the dedicated mailbox.

2) MFA and legacy clients: Devices that don’t support OAuth can’t complete MFA. Don’t weaken your policies for every user. Use a service mailbox with SMTP AUTH and apply precise conditional access, or use Direct Send for internal mail.

3) Wrong ports or encryption: IMAP must be 993 with SSL/TLS; POP 995 with SSL/TLS; SMTP AUTH 587 with STARTTLS. 465 is not supported for SMTP in Exchange Online.

4) Conditional Access/location blocks: If SMTP or IMAP is allowed but your CA policy denies the sign-in due to location or device state, you’ll see failures that look like bad passwords. Check Azure AD sign-in logs for the service account.

5) DNS not finished propagating: New domains need correct MX, SPF, and Autodiscover before clients behave. Re-run domain verification in the admin center if needed.

6) Sovereign cloud endpoints: Commercial endpoints (outlook.office365.com, smtp.office365.com) don’t apply to GCC High or 21Vianet tenants. Always confirm in the admin center for those cases.

Use this fast decision path to reduce back-and-forth tickets:

• Is it Outlook (Windows/Mac/mobile) or a modern email app with “Microsoft 365/Exchange” option? Use that. No manual settings.
• Is it a third-party app that supports OAuth with Exchange Online? Use OAuth IMAP/SMTP where supported.
• Is it a printer/scanner? Use SMTP AUTH with a dedicated mailbox (587/STARTTLS) or Direct Send to your MX for internal-only mail.
• Does the client only speak legacy IMAP/POP with Basic Auth? Replace the client. Don’t fight retired auth.
• Need external delivery but can’t store credentials on a device? Use a local relay server that authenticates once, then centralize logging and rate limits.

Document the final pattern once and standardize it across offices. That alone will cut 80% of “what’s our server settings?” requests.

If this article exists on your desk because you own “email problems” plus five other marketing ops jobs, you don’t need another agency - you need an operator. At Anton Chisliuk · AI Marketing Ops, one senior builder runs the stack: CRM/HubSpot, outbound infrastructure (600 emails/day safely), automation, and SEO content. We optimize for outcomes, not vanity metrics, with proof like taking Cleverence from 0 to 80K organic visits/month and 2K inbound leads/month. If you want a quick read on gaps and the shortest path to pipeline, grab a free Growth Audit and we’ll map it in plain English.

Sometimes IT is busy and you just need to get an app connected responsibly. Here’s how to self-check without changing tenant settings.

- Confirm your mailbox allows the protocol: In OWA Settings > Mail > Accounts > POP and IMAP, look for a message stating the protocol is disabled. If it is, stop and ask IT; you can’t override it from your inbox.

- Test credentials in a known-good client: If Outlook on the web and desktop both sign in, your password is fine. Failures in the device point to protocol blocks or wrong ports - not bad credentials.

- Try the Outlook mobile app: If the native phone mail app refuses to connect via Exchange, install Microsoft Outlook for iOS/Android. It uses the modern stack and usually works without any manual server settings.

IT loves specifics. When you escalate, include this mini-brief so they can act quickly:

• Exact client/device and version
• Required protocol (IMAP/POP/SMTP/ActiveSync) and why alternatives won’t work
• Whether external recipients are needed (decides Direct Send vs SMTP AUTH)
• Network egress IP for allowlisting/conditional access
• Copy of error message and timestamp with timezone

With those five bullets, an admin can confirm tenant and mailbox settings in minutes instead of guessing.

Email doesn’t live in a vacuum. If this exercise connects a tool that captures leads, make sure those contacts land in your CRM with the right attribution and routing. Microsoft 365 server names won’t handle that - your CRM and automation do. If you’re cleaning up lead flow, rules-based assignment, and sequences, it may be time to formalize your RevOps stack. See how we structure pipelines, deal stages, and integrations on our CRM implementation work, or wire low-code routing with Make/n8n on our marketing automation builds. And if you’re equipping a mail-sending engine for prospecting, ensure warm-up, reputation, and domain segmentation are in place - our email outbound infrastructure covers those guardrails.

You rarely need to memorize Microsoft 365 server names. Let Autodiscover and modern authentication handle Outlook and mobile wherever possible. When you must go manual - IMAP/POP for a legacy app, or SMTP for a printer - copy the canonical endpoints, confirm tenant and mailbox protocol permissions, and pick a pattern that won’t undermine your security posture. Standardize the approach across your org and you’ll prevent endless “what’s our server?” tickets.

Authored by Anton Chisliuk - operator, not agency. If you’re standing up compliant outbound or integrating email into a real pipeline, the fastest path is to blueprint it once. Start with our email outbound setup and keep your domain reputation, deliverability, and lead flow intact.

- What are the Microsoft 365 IMAP, POP, and SMTP server names?

IMAP: outlook.office365.com:993 (SSL/TLS). POP: outlook.office365.com:995 (SSL/TLS). SMTP: smtp.office365.com:587 (STARTTLS). Use your full email as the username. Remember: many tenants disable POP/IMAP and SMTP AUTH unless explicitly enabled.

- Do I need server settings for Outlook on Windows or Mac?

No. Choose Microsoft 365/Exchange during setup and sign in. Outlook uses Autodiscover and modern authentication. Manual IMAP/POP reduces features and reliability - skip it unless there’s no other choice.

- Why does my device fail to send via smtp.office365.com:587?

Most likely SMTP AUTH is disabled tenant-wide or for that mailbox, or conditional access is blocking the sign-in. Confirm with Exchange Online PowerShell and your Azure AD sign-in logs. Also verify STARTTLS is enabled and port 587 is open outbound.

- Can I use direct send instead of SMTP authentication?

Yes - point the device at your domain’s MX record (e.g., yourdomain-com.mail.protection.outlook.com) on port 25. It works without credentials but only for internal recipients in your accepted domains. You can’t send to external addresses with direct send.

- Is POP/IMAP still supported in Microsoft 365?

Yes with conditions. Basic Auth for POP/IMAP is retired, so clients must support OAuth 2.0 to connect. Many modern clients do; older ones don’t. If yours doesn’t, replace it or use Outlook. Enabling POP/IMAP per mailbox might still be required.

- What if my tenant is in GCC High or operated by 21Vianet?

Endpoints differ from commercial tenants. Don’t assume outlook.office365.com or smtp.office365.com. Fetch the exact values and DNS records from your Microsoft 365 admin center for your cloud environment.

- Why does OWA show that POP/IMAP are disabled for my account?

Your admin has turned off those protocols for your mailbox (or organization). You’ll need IT to enable them, or you should use Outlook with the Microsoft 365/Exchange option, which doesn’t require POP/IMAP at all.

- Which SMTP option is best for printers?

Use a dedicated service mailbox with SMTP AUTH on port 587 and lock it down (IP restrictions/conditional access). If you only email internal addresses, Direct Send via your MX is simpler and avoids credentials. Avoid enabling SMTP AUTH for user accounts.