{"id":3863,"date":"2026-08-14T02:42:59","date_gmt":"2026-08-14T02:42:59","guid":{"rendered":"https:\/\/www.warmy.io\/blog\/how-to-fix-smtp-email-error-530-5-7-1-solved\/"},"modified":"2026-08-14T02:43:02","modified_gmt":"2026-08-14T02:43:02","slug":"how-to-fix-smtp-email-error-530-5-7-1-solved","status":"publish","type":"post","link":"https:\/\/www.warmy.io\/blog\/how-to-fix-smtp-email-error-530-5-7-1-solved\/","title":{"rendered":"SMTP Error 530 5.7.1: Why It Happens and How to Fix It"},"content":{"rendered":"\n

TL;DR<\/strong>: SMTP error 530 is a permanent refusal rather than a delay: the server will not accept your command until you authenticate, so retrying without changing anything fails the same way every time. The standardized pairing is actually 530 5.7.0, which RFC 4954 <\/a>defines as authentication required, while RFC 3463<\/a> defines 5.7.1 as delivery not authorized, an authorization statement rather than an authentication one. <\/p>\n\n\n\n

A 530 response means the SMTP server received a command it will not process because the session is not authenticated. It is a 5xx reply, which, under RFC 5321<\/a> puts it in the permanent negative completion class: the command was not accepted, the action did not happen, and the client should not repeat the same request in the same sequence. <\/p>\n\n\n\n

In a live SMTP session it usually appears immediately after MAIL FROM, because that is the first command where the server has to decide whether you are allowed to submit mail at all.<\/p>\n\n\n\n

Why the RFC Says 530 5.7.0, Not 530 5.7.1<\/strong><\/h2>\n\n\n\n

RFC 4954, the SMTP Service Extension for Authentication, defines the response as 530 5.7.0 Authentication required, and specifies that it should be returned by any command other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT when server policy requires authentication and authentication is not currently in force. That is the standardized pairing, and it is what Google returns.<\/p>\n\n\n\n

RFC 3463, which defines enhanced status codes, assigns a different meaning to 5.7.1: delivery not authorized, message refused, describing a sender who is not authorized to send to the destination, typically as a result of per-host or per-recipient filtering. It is explicitly useful only as a permanent error.<\/p>\n\n\n\n

So 530 5.7.1 is a hybrid. The reply code says you have not authenticated. The enhanced code says you are not authorized. Servers that emit this combination, Microsoft’s above all, are usually telling you both things at once: the connection is anonymous, and an anonymous connection is not permitted to do what you just asked.<\/p>\n\n\n\n

Authentication vs. Authorization: The distinction that solves most 530 Errors<\/strong><\/h2>\n\n\n\n

Nearly every guide to this error treats it as a single problem with a single fix, which is why so many people follow the steps correctly and still cannot send. There are two distinct failures hiding under the same code.<\/p>\n\n\n\n

    \n
  • Authentication failure.<\/strong> You never proved who you are. No AUTH command succeeded, or none was attempted. The fix is credentials and client configuration.<\/li>\n\n\n\n
  • Authorization failure.<\/strong> You may have connected fine, but the identity you presented is not permitted to submit mail through this server to this destination or as this sender address. The fix is server-side permissions, not credentials.<\/li>\n<\/ul>\n\n\n\n

    The practical test: if you have not entered a username and password anywhere, you have an authentication problem. If you have entered them and they are correct, and you can log into webmail with them, you almost certainly have an authorization problem, and no amount of re-typing the password will help.<\/p>\n\n\n\n

    Note also that 530 is not the same as 535. A 535 5.7.8 means you tried to authenticate and the credentials were rejected. A 530 usually means you did not try at all, or the server would not let you.<\/p>\n\n\n\n

    Is SMTP Error 530 5.7.1 a hard bounce?<\/strong><\/h2>\n\n\n\n

    Functionally, yes. The 5xx class is permanent, so a sending system that receives a 530 will not queue and retry the way it would with a 4xx deferral.<\/p>\n\n\n\n

    But it is worth being precise about where the failure happened, because it changes what the error means for your metrics. A 530 on submission means your own client or application never got the message into the mail system. Nothing was sent, so nothing bounced in the deliverability sense. If your platform records it as a bounce against a recipient, that recipient is being penalized for your configuration problem, and the record should be corrected.<\/p>\n\n\n\n

    This also means a 530 carries no reputation signal. Spam filters, blocklists, and engagement metrics were never involved. If your open rates dropped at the same time you started seeing 530s, the shared cause is that mail stopped going out, not that receivers started rejecting you.<\/p>\n\n\n\n

    530 error variants by provider<\/strong><\/h2>\n\n\n\n

    The three digits are generic. The trailing text is where the diagnosis lives.<\/p>\n\n\n\n

    Response<\/strong><\/th>Who returns it<\/strong><\/th>What it actually means<\/strong><\/th><\/tr><\/thead>
    530 5.7.0 Authentication Required plus a WantAuthError support link and a gsmtp suffix<\/td>Gmail and Google Workspace<\/td>Your client sent MAIL FROM without a successful AUTH exchange. Standard RFC 4954 pairing.<\/td><\/tr>
    530 5.7.1 Client was not authenticated<\/td>Microsoft Exchange and Exchange Online<\/td>The session is anonymous and anonymous submission is not permitted here.<\/td><\/tr>
    530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM<\/td>Microsoft 365<\/td>You reached smtp.office365.com but did not authenticate as a mailbox. Microsoft’s NDR logs sometimes record the same condition as 550 5.7.57.<\/td><\/tr>
    530 5.7.0 Must issue a STARTTLS command first<\/td>Many servers<\/td>You attempted AUTH before upgrading the connection. Not a credentials problem.<\/td><\/tr>
    535 5.7.8 Authentication credentials invalid<\/td>Most servers<\/td>You did authenticate and the credentials were wrong. A different problem entirely.<\/td><\/tr>
    550 5.7.30 Basic authentication is not supported for Client Submission<\/td>Exchange Online, once Basic auth is disabled<\/td>Your credentials may be perfect. The authentication method is no longer accepted.<\/td><\/tr>
    550 5.7.1 Unable to relay<\/td>Exchange and others<\/td>Authenticated or not, you are not authorized to send to that destination.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    If your error text is not in this table, read it literally before you start changing settings. “Must issue a STARTTLS command first” and “Client was not authenticated” call for completely different fixes.<\/p>\n\n\n\n

    What causes SMTP Error 530 5.7.1?<\/strong><\/h2>\n\n\n\n

    1. SMTP Authentication Is Turned Off in Your Mail Client<\/strong><\/h3>\n\n\n\n

    The simplest cause and still a real one. The client is configured with the right server and port but was never told the outgoing server requires a login, so it connects and sends MAIL FROM without attempting AUTH.<\/p>\n\n\n\n

    In Outlook this lives under the Outgoing Server tab as “My outgoing server (SMTP) requires authentication.” In Thunderbird and most other clients it is an authentication method dropdown that must not be set to None. In application code it is the difference between passing credentials to the SMTP transport and not passing them.<\/p>\n\n\n\n

    2. SMTP AUTH Is Disabled on the Mailbox or Tenant (Microsoft 365)<\/strong><\/h3>\n\n\n\n

    This is the cause most guides miss, and it produces a 530 even when the credentials are perfect.<\/p>\n\n\n\n

    Microsoft 365 controls authenticated SMTP client submission per mailbox and organization-wide. If it is disabled, the mailbox simply cannot be used for SMTP submission, no matter what password you supply.<\/p>\n\n\n\n

    Check it in Exchange Online PowerShell:<\/p>\n\n\n\n

    Get-CASMailbox -Identity sender@contoso.com | Format-List SmtpClientAuthenticationDisabled<\/p>\n\n\n\n

    If the value is True, enable it for that mailbox:<\/p>\n\n\n\n

    Set-CASMailbox -Identity sender@contoso.com -SmtpClientAuthenticationDisabled $false<\/p>\n\n\n\n

    The same setting is exposed in the Microsoft 365 admin center under Users, Active users, then the mailbox, then Mail, then Manage email apps, where “Authenticated SMTP” is a checkbox. Unchecked means disabled.<\/p>\n\n\n\n

    3. You Are Using a Regular Password Where an App Password or OAuth Token Is Required<\/strong><\/h3>\n\n\n\n

    If your application worked for years and then stopped, this is almost always why. Providers have been withdrawing password-only SMTP access for half a decade, and the failure often surfaces as a 530 or a 535 rather than as a clear explanation.<\/p>\n\n\n\n

    Google removed the “Allow less secure apps” toggle from personal Gmail accounts on May 30, 2022. For Google Workspace, access to Less Secure Apps was turned off in stages, partially disabled from June 15, 2024 and fully disabled from September 30, 2024, covering all third-party apps that require password-only access over protocols including SMTP, IMAP, POP, CalDAV, and CardDAV. There is no admin setting that restores it.<\/p>\n\n\n\n

    The replacements are OAuth 2.0 or a 16-character app password, and app passwords are only available on accounts with 2-Step Verification turned on.<\/p>\n\n\n\n

    4. You Are Connecting to the Wrong Endpoint or Port<\/strong><\/h3>\n\n\n\n

    Two versions of this are common.<\/p>\n\n\n\n

      \n
    • Wrong hostname.<\/strong> Microsoft’s SMTP client submission endpoint is smtp.office365.com, not smtp.outlook.com. Sending to the wrong host, or to the MX endpoint ending in mail.protection.outlook.com, produces authentication failures because those endpoints serve different purposes. The MX endpoint accepts inbound mail for the tenant and does not accept authenticated client submission.<\/li>\n\n\n\n
    • AUTH before STARTTLS.<\/strong> Most servers advertise AUTH in their EHLO response only after the connection has been secured. If your client attempts AUTH on a plaintext connection, the server refuses, and depending on implementation you get a 530 telling you to issue STARTTLS first. Port 587 with STARTTLS and port 465 with implicit TLS are the correct submission paths. Port 25 is for server-to-server transfer and is widely blocked for client submission.<\/li>\n<\/ul>\n\n\n\n

      5. Relay Denied: You Authenticated but Are Not Authorized to Send to That Destination<\/strong><\/h3>\n\n\n\n

      This is the pure authorization case, and it is where the 5.7.1 enhanced code earns its RFC 3463 meaning. The server accepted who you are and still refuses to carry the message, usually because the recipient domain is not one it handles and you are not on its permitted relay list.<\/p>\n\n\n\n

      Common triggers include an application configured to relay through a server it is not whitelisted on, a connector missing in Exchange Online, an on-premises Exchange receive connector that does not include the sending host’s IP, and a hybrid setup where IP restrictions were tightened. In one documented Microsoft Q&A case, a hybrid Exchange environment throwing 530 5.7.57 sporadically turned out to be an IP allowlist that was too narrow.<\/p>\n\n\n\n

      6. Security Defaults or Conditional Access Is Blocking Legacy Authentication<\/strong><\/h3>\n\n\n\n

      Even with SMTP AUTH enabled on the mailbox and a valid app password, a tenant-wide security policy can block the connection. Microsoft’s Security Defaults block legacy authentication across the tenant, and because it is a global setting, individual users cannot be excluded from it.<\/p>\n\n\n\n

      The symptom is a permanent authentication refusal that survives every credential change. In this situation Microsoft’s own guidance points toward OAuth 2.0 rather than toward loosening the policy.<\/p>\n\n\n\n

      The deadline behind most new 530 errors: Basic auth is being retired<\/strong><\/h2>\n\n\n\n

      If you are reading this because something that used to work stopped working, this section is probably your answer. The underlying story is not about your settings. It is that the industry is removing the authentication method your settings depend on.<\/p>\n\n\n\n

      Microsoft 365 SMTP AUTH basic authentication timeline<\/strong><\/h3>\n\n\n\n

      Microsoft began disabling Basic authentication across Exchange Online protocols in 2019 and completed that work in late 2022, with Client Submission (SMTP AUTH) left as the sole exception. That exception is now closing.<\/p>\n\n\n\n

      The schedule has moved more than once. Microsoft originally targeted September 2025, then announced a phased rejection starting March 1, 2026 reaching 100 percent on April 30, 2026. On January 27, 2026, Microsoft revised it again. The current published timeline:<\/p>\n\n\n\n

      When<\/strong><\/th>What happens<\/strong><\/th><\/tr><\/thead>
      Through December 2026<\/td>SMTP AUTH Basic authentication behavior remains unchanged<\/td><\/tr>
      End of December 2026<\/td>Basic auth disabled by default for existing tenants, though administrators can still re-enable it<\/td><\/tr>
      New tenants created after December 2026<\/td>Basic auth unavailable by default, with OAuth as the supported method<\/td><\/tr>
      Second half of 2027<\/td>Microsoft announces the final removal date<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      Microsoft attributed the extension to customers facing real challenges modernizing legacy email workflows.<\/p>\n\n\n\n

      Two details matter for troubleshooting. First, the affected endpoints are smtp.office365.com and smtp-legacy.office365.com. Second, when Basic auth is refused, the response is 550 5.7.30 Basic authentication is not supported for Client Submission, not a 530. If you see that string, your credentials are irrelevant and only a change of authentication method will fix it.<\/p>\n\n\n\n

      The systems most exposed are the ones nobody thinks about: multifunction printers and scanners with scan-to-email, monitoring and alerting tools, scheduled batch jobs, and internal web applications with hardcoded SMTP credentials. Microsoft added Basic and OAuth usage reporting to the SMTP AUTH Clients Submission Report in the Exchange admin center in late 2024, which is the fastest way to inventory what is still using Basic auth in your tenant.<\/p>\n\n\n\n

      Google Workspace and Gmail: Less secure apps are gone<\/strong><\/h3>\n\n\n\n

      Google’s equivalent transition is already complete. Personal Gmail accounts lost the toggle in May 2022. Google Workspace accounts were phased out through 2024, with the Admin console setting removed and password-only access fully disabled.<\/p>\n\n\n\n

      What replaces it:<\/p>\n\n\n\n