Hotmail SMTP settings

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.

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.

Incoming settings

For completeness, since a mail client needs both halves configured. 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

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.

For application or bulk mail this path is unsuitable regardless of volume. There are no delivery events, no bounce classification and no suppression handling, so a sending system has no way to learn what happened to a message.

The appropriate arrangement for that case is a submission service authenticating as a verified sending domain, which supplies the reporting layer a consumer mailbox cannot.

The bar rises with volume. George, our CEO, tracks the receiver rules in his Email Marketing Bible, and the current one is blunt. Authentication must be SPF, DKIM and DMARC aligned at p=quarantine or stronger, and Outlook requires it for anyone sending five thousand a day or more. A consumer mailbox cannot meet that, because none of those records are yours to publish on hotmail.com.

We watch this from the operator side too. Nitrosend records the email stack behind each customer domain, microsoft included, because knowing whether a sender lives on a consumer mailbox or a Workspace or 365 tenant changes the advice that follows.

Go deeper