The SMTP server requires a secure connection 5.7.57

The server response usually reads: 530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM (Microsoft's own NDR troubleshooting docs sometimes label the equivalent bounce as 550 5.7.57 — the two numbers refer to the same underlying condition at different points in the mail pipeline: 530 is the live SMTP session reply, 550 is the code Microsoft's non-delivery-report logs use for it). This is a Microsoft 365 / Exchange Online (smtp.office365.com) error, not a generic SMTP reply code.

What causes the 5.7.57 error?

Exchange Online's client SMTP submission endpoint requires that every message be sent as an authenticated mailbox. The 5.7.57 enhanced status code (a 5.7.x security/policy failure under RFC 3463) means your application connected but Exchange saw the MAIL FROM command arrive without a successful SMTP AUTH login — i.e. as anonymous mail, which smtp.office365.com does not accept. Common triggers:

• Authenticated SMTP (SMTP AUTH) is disabled on the mailbox. Microsoft disables SMTP AUTH by default for tenants created after January 2020.
• No credentials, or the wrong credentials, were supplied in the client. The contemporary "client requires a secure connection" wording (often surfaced by .NET System.Net.Mail / SmtpClient) reflects this: the library never completed AUTH.
• Security Defaults or an authentication policy is blocking it. Per Microsoft's docs, if Security Defaults is on, SMTP AUTH is disabled tenant-wide regardless of the per-mailbox setting.
• Basic authentication is being used while it's deprecated. Microsoft is retiring Basic auth for client SMTP submission; OAuth (Modern auth) is the recommended path.

This is not primarily a password-strength problem — a weak password doesn't produce 5.7.57. The original "use a strong password" advice on this page was incorrect and has been removed.

How do I fix the 5.7.57 error?

1. Enable Authenticated SMTP on the sending mailbox. In the Microsoft 365 admin center go to Users > Active users, select the mailbox, open Mail > Manage email apps, and check Authenticated SMTP. Or via Exchange Online PowerShell:

Set-CASMailbox -Identity sender@contoso.com -SmtpClientAuthenticationDisabled $false

2. Make sure it isn't blocked tenant-wide or by Security Defaults. Confirm the org-wide toggle is off and disable Security Defaults if needed:

Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled
# False (or per-mailbox $false override) is required to allow SMTP AUTH

3. Connect with credentials over TLS on port 587. Use the DNS name smtp.office365.com (never an IP), port 587 with STARTTLS (TLS 1.2 or 1.3), and supply the mailbox's username and password / OAuth token. Microsoft notes that if your client defaults to port 465, it likely doesn't support the required TLS for client submission — use 587 instead. Node example:

const transport = nodemailer.createTransport({
  host: "smtp.office365.com",
  port: 587,
  secure: false,        // STARTTLS upgrade on 587
  requireTLS: true,
  auth: { user: "sender@contoso.com", pass: process.env.SMTP_PASS }
});

4. Prefer OAuth, and watch the Basic-auth deprecation. Because Microsoft is retiring Basic auth for SMTP AUTH, move to OAuth for IMAP/POP/SMTP, or switch the workload to a method that doesn't depend on a mailbox login: SMTP relay via an inbound connector (IP/cert-authenticated, port 25, to yourdomain-com.mail.protection.outlook.com), Direct Send (internal recipients only), or High Volume Email. Do not re-enable "Less secure apps" — Google phased out Less Secure Apps for Gmail (2022 for personal accounts, fully gone for Workspace by 2024-2025), and it never applied to Microsoft 365 anyway.

5. If you authenticate as one mailbox but send "From" another, you'll instead see 5.7.60 Client doesn't have permissions to send as this sender — grant Send As on the mailbox.