How to find SMTP server in Outlook, and what an agent should use instead

Know which account you have first

Outlook has two account types, personal and Microsoft 365, and each has its own SMTP server. Using the wrong one gives the same error as a wrong password.

Personal accounts are documented in Microsoft's settings reference, with the Hotmail case on the Hotmail SMTP settings page. Work or school accounts are administered through a Microsoft 365 tenant and covered in Microsoft's device and application guide and on the Outlook and Office 365 SMTP settings page.

When an AI agent asks for your Outlook SMTP server

An AI coding agent wiring email into an app usually asks for three things in a row: the SMTP host, the port and the mailbox password. With those it writes smtp-mail.outlook.com or smtp.office365.com, port 587 and the mailbox login into a .env file or straight into the code, and every message the app sends then leaves from that one personal or work mailbox.

That is enough for a first test and wrong for an app, for three reasons:

• Microsoft caps client submission at 10,000 recipients per day and 30 messages per minute, per its device and application guide.
• The mailbox password sits in code that other people and other tools can read.
• Replies from customers land in one person's inbox.

The alternative is to give the agent a sending domain and an API rather than a mailbox. Nitrosend has no SMTP host to hand over. An agent sends through the transactional email API, the email API and SDKs or the Nitrosend MCP server, from a domain verified for sending. A generic shared agent-mail domain looks spammy to receivers, so the sending identity belongs on your own domain or a subdomain of it.

Nitrosend publishes nitrosend.com/SKILL.md, a file written for the agent itself that covers account setup, a sender and the first test email. The broader pattern is in sending email from LLMs. The case of an agent moving alerts off an Outlook mailbox is covered on the Outlook SMTP server page, and the outgoing mail server page explains what that field means in any client.

In the Outlook desktop application

Account settings hold the values:

1. Open File.
2. Open Account Settings.
3. Choose Account Settings again from the dropdown.
4. Open the account entry to view the server details.

Some builds surface this under Server Settings within the account rather than in a properties dialog, and the outgoing server appears there alongside the port and encryption method.

Where the account is an Exchange or Microsoft 365 connection rather than an IMAP or POP one, the desktop client may not display an SMTP host at all. Exchange accounts connect over Microsoft's own protocol rather than SMTP, so there is no outgoing server field to read, and the value has to come from the documentation instead.

In Outlook on the web

1. Open Settings with the gear icon.
2. Go to Mail.
3. Open the sync or forwarding section.
4. Follow the link to view POP, IMAP and SMTP settings.

The web interface changes frequently, and the section has moved between Mail and Accounts across versions. If the link is absent, the published values remain correct, and the general method for any client is in how do I find my SMTP server.

Administrators can disable this display for a tenant, in which case the values come from the administrator rather than the interface.

Outlook SMTP settings: host, port 587 and STARTTLS

For personal accounts: smtp-mail.outlook.com, port 587, STARTTLS, authentication required, username being the full email address.

For Microsoft 365: smtp.office365.com, port 587, STARTTLS at TLS 1.3 or 1.2, authentication required. Port 465 is not supported on this path, and Microsoft states that a device defaulting to it does not support the required TLS versions.

Two account-level requirements sit outside the values. SMTP AUTH must be enabled on the specific mailbox, and Microsoft disables it by default for tenants created after January 2020. Accounts with two-step verification need an app password rather than the account password.

Worked example: answering the agent without handing over a mailbox

A coding agent building a signup flow stops and asks for the Outlook SMTP server and the password. The reply that keeps the mailbox out of the code, as the prompt:

Don't use my Outlook login. Set up sending from our domain for the signup emails and send me a test.

Before: unguided, the agent pastes smtp.office365.com, port 587 and the mailbox password into .env, and every signup confirmation goes out as one employee's mailbox.

After, with the Nitrosend MCP server connected to the coding agent, the sequence is:

1. nitro_get_status reads the account context, sender identity and readiness.
2. nitro_manage_domains adds the company sending domain and verifies it.
3. nitro_manage_template creates the signup email as a reusable template.
4. nitro_review_delivery runs the read-only review of that template, with validation, spam analysis, preflight and previews. It never sends.
5. nitro_send_test_message delivers a single live copy of the template to the test addresses configured through nitro_configure_account.
6. A person opens the test and checks the From address, the links and the copy before any signup email goes out.
7. The app sends each signup email as a single transactional send through the API, with one idempotency_key per signup that is reused only for an exact retry of that signup.
8. nitro_get_insights reports email analytics with trends, benchmarks and recommendations once real signups arrive.

No mailbox password is written anywhere, and the From address is the company domain rather than whoever happened to set up Outlook. Connecting the agent to the MCP server is the step that makes this sequence available.

Where it goes wrong when an agent uses the Outlook SMTP server

Most of these come from finding and copying the settings, not from sending itself.

• The personal host is used for a Microsoft 365 account, or smtp.office365.com for an outlook.com address. Both fail at authentication with the same error as a wrong password, so an agent that retries keeps changing the password instead of the host.
• The incoming host is copied as the outgoing one. Outlook on the web lists the POP, IMAP and SMTP values together, and an agent reading that list can pick the IMAP server and port for sending.
• The mailbox password is stored in the repo. Once it sits in a committed .env file or a log line, it is a login to a person's whole mailbox, not a send-only key.
• The From address is not the signed-in mailbox. An agent that sets the From to a no-reply or support address on the same domain has the message rejected by Microsoft 365.
• SMTP AUTH is off for the mailbox. Tenants created after January 2020 have it disabled by default, so correct settings still fail until an administrator enables it.

When the answer will not help

Finding the value configures a client to send as one mailbox, which is the right outcome for a person sending their own mail.

An application is a different case. Client submission is held to the limits above, sends as an individual rather than as a domain identity you manage, and reports no delivery events or bounce classification back to the sending system.

For apps, Microsoft also offers SMTP relay through a connector and High Volume Email (see how SMTP relay works). Neither reports delivery events or bounces back to the app. A sending service on a verified domain does, which is the transactional email API route described above.

Go deeper