Outlook and Microsoft 365 mailboxes can send mail over SMTP, which is how printers, scanners, websites and scripts send through a Microsoft account. The settings are simple, but the details trip many people up: the right server name depends on the kind of account, authentication rules are changing, and Microsoft limits how much you can send. This guide lists the Outlook and Microsoft 365 SMTP settings in common use, explains the options for each type of device or application, covers the move away from basic authentication, and says when a dedicated SMTP service is the better choice.
Check Microsoft's current documentation. Microsoft changes authentication rules and limits over time, and we cannot see your tenant's settings. Treat the values below as a starting point, and confirm them with Microsoft's own pages linked at the end of this guide.
Outlook SMTP settings
These are the values generally used by mail clients and applications that sign in to a mailbox:
| Setting | Microsoft 365 (work or school) | Outlook.com (personal) |
|---|---|---|
| SMTP server | smtp.office365.com | smtp-mail.outlook.com |
| Port | 587 | 587 |
| Encryption | STARTTLS | STARTTLS |
| Username | Your full email address | Your full email address |
| Password | Your password, or an app password if your account requires one | Your password, or an app password if you use two-step verification |
Port 587 with STARTTLS means the connection starts in plain form and is then upgraded to an encrypted one before any login details are sent. If you want to understand the difference between this and other ports, read our guide to SMTP ports 25, 465 and 587. The general explanation of each field is in SMTP settings, ports, TLS and authentication.
Three ways to send through Microsoft 365
Microsoft describes several options for devices and applications that need to send mail, and the right one depends on what you are connecting.
- Client submission (SMTP AUTH). The device or app signs in with a mailbox name and password to the server above. It can send to anyone, inside or outside your company. It needs a licensed mailbox, and the mailbox must be allowed to use authenticated SMTP.
- Direct send. The device sends straight to your organisation's own mail endpoint with no sign-in, and it can only deliver to mailboxes inside your company. It suits a scanner that sends scans to staff.
- SMTP relay through a connector. Your organisation sets up a connector that accepts mail from a fixed public IP address or a certificate. It can send to people outside the company, and it needs no mailbox licence for the device. It requires an administrator to configure it.
Pick the least powerful option that does the job. A printer that only emails staff does not need permission to send to the world.
Why a login can fail
- SMTP AUTH is switched off for the mailbox or for the organisation. An administrator must allow it for the account that sends.
- Two-step verification is on, and the app does not support it. Use an app password if your administrator permits one, or move to a modern sign-in method.
- Security defaults or conditional access block legacy sign-in. Many organisations switch these on to protect accounts.
- Wrong server for the account type. A personal Outlook.com account and a work account use different server names.
- The from address does not match the signed-in mailbox. Microsoft may rewrite or reject a sender that is not the account owner.
- A network blocks the port. Some networks block outbound connections on 587. Our guide on SMTP connection timeouts and TLS errors helps trace this.
The end of basic authentication for SMTP
"Basic authentication" means signing in with just a username and a password. Microsoft has been retiring it across Exchange Online in favour of modern authentication with tokens, and has announced the retirement of basic authentication for SMTP AUTH client submission. The dates have been revised more than once, so we do not state one here. Search Microsoft's current announcement for the exact timetable before you plan.
What this means in practice:
- Scripts and applications that sign in to a mailbox with a stored password may stop working when the change takes effect for your tenant.
- Applications that support OAuth 2.0 can obtain tokens and keep sending. Many libraries support it, though setup in Azure is more work than a password.
- Devices that cannot use modern sign-in, such as older printers, should move to direct send, to a connector or to another service.
Plan the change before it breaks your invoices. List every device and app that sends through Microsoft 365, find out which method each one uses, and decide whether to upgrade, reconfigure or move it.
Sending limits
Microsoft sets limits on the number of messages and recipients per mailbox, and on the rate of sending. They exist to protect the service and they are meant for people, not for application traffic or marketing lists. A mailbox that sends too much can be restricted or blocked, which also stops the account owner's ordinary mail. Check Microsoft's current limits for your plan, since they change and we do not list them here.
The same caution applies to deliverability. Mail that you send through a work mailbox uses your company's domain reputation, so a mistake in an application can harm the mail your colleagues send by hand.
When a dedicated SMTP service is a better fit
A Microsoft mailbox is built for people. If your website, product or scripts send receipts, alerts, resets or newsletters, a dedicated service is usually a better fit, because:
- It is built for application volume and does not tie sending to one person's account.
- You get logs and delivery events for each message, not a sent folder.
- Bounces, complaints and suppression are handled for you.
- You are not exposed to changes in a mailbox login method.
- Your people's mail and your application mail stay on separate reputations.
With our relay, an application connects to smtp.migosmtp.com on port 587 with STARTTLS and signs in with SMTP credentials made for that purpose. See SMTP relay and the guide to choosing between SMTP and an API. You will need to authenticate your domain so that mail from your company name passes checks.
Testing your settings
- Enter the server, port, encryption and credentials in your device or application.
- Send a test message to an address you own outside the company, and to one inside.
- If it fails, read the error text. "Authentication unsuccessful" points to a sign-in rule, while a timeout points to the network.
- Open the received message's headers and check that SPF and DKIM pass.
The free SPF, DKIM and DMARC checker shows what your domain publishes. If you add a second sender to the domain, such as an SMTP service next to Microsoft 365, make sure SPF lists both. Otherwise one of them will fail checks. Our SPF lookup limit guide explains what happens when the record grows too long.
Keep application email off your staff mailboxes Send receipts, alerts and resets through a relay built for it, with logs for every message.
References and further reading
Frequently asked questions
What is the Outlook SMTP server?
For Microsoft 365 work or school accounts it is generally smtp.office365.com, and for personal Outlook.com accounts smtp-mail.outlook.com. Both use port 587 with STARTTLS.
Which port does Outlook SMTP use?
Port 587 with STARTTLS is the usual setting. The connection starts plain and is upgraded to an encrypted one before login.
Why does my Microsoft 365 SMTP login fail?
Common causes are SMTP AUTH being disabled, two-step verification without an app password, conditional access blocking legacy sign-in, or the wrong server for the account type.
Is basic authentication for SMTP going away?
Microsoft has announced the retirement of basic authentication for SMTP AUTH client submission. The dates have changed, so check Microsoft's current documentation for your timetable.
Should I send newsletters through an Outlook mailbox?
No. Mailboxes are built for people and have sending limits. Use a dedicated sending service for application and bulk email.