Hotmail SMTP settings: server, port 587, sign-in, and what changes when an agent sends

Outgoing server settings

The server is smtp-mail.outlook.com. Addresses ending hotmail.com, outlook.com, live.com and msn.com all use it, because they are the same consumer service under different historical domains.

The port is 587 with STARTTLS. Microsoft does not support implicit TLS on 465 for this path, so a client offering only an SSL option rather than STARTTLS will fail to connect.

Authentication is required, and the username is the full email address including the domain. A local part alone is rejected. The general walkthrough is in how to set up SMTP, and the port choices are compared on the SMTP ports page.

Do not confuse this with smtp.office365.com. That hostname serves Microsoft 365 work and school accounts, and pointing a consumer Hotmail account at it fails at authentication in a way that reads as a wrong password.

Passwords and modern authentication

Accounts with two-step verification require an app password rather than the account password. Microsoft generates these in account security settings, and each is scoped to one application.

Consumer accounts are being moved toward OAuth, which Microsoft markets as modern authentication. A client supporting OAuth2 should use it, since a token is scoped, expiring and revocable in ways a password is not.

Basic authentication for client SMTP submission is on a deprecation path across Microsoft's platforms. Anything built on username and password against a Microsoft account has a limited life expectancy.

What an agent does differently with Hotmail SMTP

Ask a coding agent in Claude, ChatGPT or Cursor to make an app send password resets and it reaches for the first SMTP block that works. For a solo developer that is often their own Hotmail account. A person typing these settings into a mail client is a different case from an agent putting them into a product, for four reasons:

• It runs unattended. Nobody watches the first sends, so a failed reset shows up days later as a customer who never got the email.
• It retries on failure. A send that times out gets sent again, and every retry counts against the consumer account's daily sending limit.
• It copies credentials into config. The Hotmail address and its password or app password go into .env, a config file or a test script, and from there into commits and logs.
• It sends product mail on one person's consumer mailbox. Every agent that sends this way borrows one person's address, signing up and sending as them, and every reply and bounce lands in that person's inbox.

Nitrosend gives the agent tools over MCP instead of a mailbox password and a port. The agent sends from a verified domain you own rather than a borrowed personal address, and a person checks the mail before customers get it.

Worked example: move app mail off a Hotmail account

The prompt: "Our app sends password resets through my Hotmail account. Move them off it."

Before. Left unguided, an agent keeps the setup it finds. A personal Microsoft credential sits in .env, the mailer points at smtp-mail.outlook.com on 587, and every password reset depends on one consumer account.

After. With the Nitrosend MCP tools, the agent works through a fixed sequence:

1. nitro_get_status checks account readiness and the sender identity.
2. nitro_manage_domains adds the company's sending domain and verifies it.
3. nitro_manage_template creates a reusable password-reset template.
4. nitro_review_delivery gives that template a read-only pass covering validation, spam analysis, preflight and previews. It never sends.
5. Then nitro_send_test_message sends exactly one copy of the template to the test recipients configured with nitro_configure_account. It never sends to an audience.
6. A person checks the test before any customer gets a reset.
7. The app sends each reset with nitro_send_message or through the REST API behind the transactional email API, with one idempotency_key per reset that is reused only for an exact retry.
8. nitro_get_insights shows email analytics, with trends, benchmarks and recommendations, for the first live resets.

The end state is a verified sending domain and an API key in place of a personal Microsoft credential. The Free plan includes 5,000 emails up front and then 500 a month. New accounts start at 100 recipients per rolling 24 hours, and the allowance rises with sender standing. The limits are on the pricing page.

Where it goes wrong when an agent uses Hotmail SMTP

• The password leaks. It gets committed to a repo or printed in a debug log, and anyone who finds it can send as that Hotmail account.
• Old sign-in code stops working. Agents copy basic-auth examples that send a username and password, and Microsoft is moving consumer accounts toward modern authentication, so that code breaks when the account moves.
• A retry loop spends the daily limit. A loop that resends on every timeout spends the consumer account's daily allowance on duplicate resets, so real resets stop going out.
• Reputation is tied to one person. Product mail carries one person's mailbox reputation, and there are no delivery events to show what happened, so their account problems become the product's delivery problems.

Incoming settings

A mail client needs both halves configured, so here are the incoming values. The incoming server is outlook.office365.com on port 993 with implicit TLS for IMAP, or on port 995 for POP3.

Retrieval is a separate protocol from submission. A client with only outgoing settings configured will send successfully while showing an empty inbox, which is a common source of confusion when only half the configuration was copied.

Sending limits and suitability

For application or bulk mail this path is unsuitable regardless of volume. A consumer mailbox lacks three things a sending system needs to learn what happened to a message:

• Delivery events. Nothing reports whether a message was delivered.
• Bounce classification. A failed message comes back as mail in the inbox, not as data.
• Suppression handling. Nothing stops the next send to an address that already failed.

Consumer accounts carry daily sending limits and per-recipient caps sized for personal correspondence. Exceeding them results in the account being temporarily restricted rather than returning a clear error at send time.

Mail sent this way authenticates as one personal mailbox. It sends as that address, carries that mailbox's reputation, and cannot send as a business domain.

The appropriate arrangement is a submission service authenticating as a verified sending domain, which supplies the reporting layer a consumer mailbox cannot. Send through the email API from a verified domain and the agent never touches a mailbox password.

FAQ

Related reading

• Transactional email, defined
• What email deliverability is
• Email authentication protocols
• SMTP authentication

Go deeper