Microsoft 365 SMTP Authentication Issue Affecting FRP Service Contact Forms and Automated Emails

Question

I am currently managing an FRP-related website that provides Android FRP bypass information and remote unlocking support. Recently, after migrating our email services to Microsoft 365, we started facing issues with SMTP authentication and outbound email delivery. Our website contact forms and automated support responses are no longer sending emails consistently, especially when users submit unlock requests or account verification forms.

The problem started after enabling modern authentication policies in Microsoft 365 Admin Center. Previously, the website was using traditional SMTP authentication through a WordPress SMTP plugin. Now, emails either fail silently or return authentication errors related to OAuth and SMTP AUTH being disabled. Some users also reported not receiving password reset emails or FRP service confirmation messages.

We tested multiple configurations including SMTP relay, app passwords, and direct send methods, but the issue still persists intermittently. In some cases, Microsoft 365 accepts the connection but delays or blocks outgoing messages due to suspected spam or security filtering. We also checked SPF, DKIM, and DMARC records, and although they appear configured correctly, email delivery remains unstable.

Another issue is related to Microsoft Defender policies automatically quarantining messages generated from our website forms. Since our platform deals with Android device unlocking support, some automated messages contain technical keywords that may be triggering security filters. We are unsure whether additional Exchange Online protection rules need to be adjusted for this type of website communication.

The website itself is hosted on a Linux server using PHP mail fallback alongside SMTP. Error logs show TLS negotiation problems and occasional “535 5.7.139 Authentication unsuccessful” responses from Microsoft servers. We already enabled SMTP AUTH for the mailbox account, but the issue continues randomly across different devices and IP addresses.

Has anyone experienced similar Microsoft 365 email authentication or deliverability problems with WordPress-based service websites? You can click here to check the website. Any guidance regarding secure SMTP setup, OAuth implementation, Exchange connector configuration, or Defender policy adjustments for transactional emails would be appreciated.

Answer 1

For intermittent SMTP authentication failures and TLS issues after enabling modern authentication, verify and adjust the following areas that are explicitly called out for SMTP AUTH client submission and SMTP relay in Microsoft 365.

1. Verify SMTP AUTH is enabled on the mailbox

• Use Exchange Online PowerShell to confirm the mailbox used by WordPress has SMTP AUTH enabled:

    Get-CASMailbox -Identity <EmailAddress> | Format-List SmtpClientAuthenticationDisabled
  

• If the value is True, enable SMTP AUTH for that mailbox:

    Set-CASMailbox -Identity <EmailAddress> -SmtpClientAuthenticationDisabled $false
  

• If security defaults or an authentication policy is blocking basic auth for SMTP, SMTP AUTH will fail even if enabled. In that case, either disable security defaults or adjust the auth policy so that SMTP basic auth is allowed for this mailbox. Note that security defaults being enabled automatically disables SMTP AUTH.

2. Address 535 / 5.7.x authentication errors For errors such as 535 5.7.3 Authentication unsuccessful or 5.7.57 Client not authenticated to send mail:

• Confirm the username and password configured in the WordPress SMTP plugin are correct.
• Sign in to Outlook on the web with the same credentials to ensure the mailbox is active and not blocked for sending spam.
• If multifactor authentication (MFA) is enabled on the mailbox, disable MFA for that account when using basic SMTP AUTH, or move to an OAuth-based implementation instead. To disable MFA:
  • In Microsoft 365 admin center: Users → Active users → Multi-Factor Authentication, then disable MFA for that user.
• If Conditional Access is blocking legacy authentication, exclude this specific user from any policy that blocks legacy authentication for SMTP.

3. Ensure TLS 1.2 support and resolve TLS negotiation failures

• Microsoft 365 requires TLS 1.2 or higher for SMTP AUTH in many scenarios. Devices or applications that do not support TLS 1.2 can fail with TLS negotiation errors.
• Update the PHP/WordPress host’s OS, OpenSSL, and mail libraries to ensure TLS 1.2 is supported and enabled.
• If the device or application cannot support TLS 1.2, Microsoft provides an opt-in endpoint for legacy TLS, but the preferred approach is to upgrade so that TLS 1.2 is supported. See “New opt-in endpoint available for SMTP AUTH clients still needing legacy TLS” and “How Exchange Online uses TLS to secure email connections” for details.

4. Test SMTP connectivity from the web server

• Install the Telnet client on a machine on the same network as the web server.
• From a command line, run:
  • telnet smtp.office365.com 587 (or port 25 if configured that way).
• A successful connection should show a banner similar to:
  • 220 ...outlook.office365.com Microsoft ESMTP MAIL Service ready ...
• If connection fails, a firewall or ISP may be blocking ports 587 or 25. That must be resolved for SMTP AUTH or relay to work.

5. Consider SMTP relay vs. SMTP AUTH If using Microsoft 365 SMTP relay (connector-based) instead of authenticated submission:

• Ensure the web server sends from a static IP address.
• Confirm that IP is configured on the inbound connector and in SPF.
• If the IP or certificate changed (for example, hosting changes), update the connector with the new IP or certificate. Otherwise, errors like 5.7.64 TenantAttribution; Relay Access Denied can occur.
• If the static IP changes due to ISP/network changes, update both the connector and SPF record.

6. Handle spam filtering and Defender quarantining When Microsoft 365 or Defender marks messages as junk or quarantines them:

• Ensure SPF includes the sending IP, and that DKIM/DMARC are correctly aligned for the From domain.
• Be aware that Microsoft 365 uses blocklists and antispam tools; if outbound spam is detected, IPs or users can be restricted. Use the Restricted Users portal guidance to remove blocked users if applicable.
• For messages being quarantined due to content, review Defender policies and adjust as needed so that legitimate transactional messages from the site are not treated as spam. This can include tuning policies or rules, but must be done carefully to avoid weakening protection.

7. Diagnose intermittent failures and high-volume or OAuth scenarios

• For OAuth-based SMTP with High Volume Email (HVE), specific error codes indicate configuration problems:
  • 535 5.7.144 XOAUTH2 authentication failed. Invalid API permissions.
    • Check API permissions as described in “OAuth authentication for high volume emails for Microsoft 365”.
  • 550 5.7.240 The application is not allowed for use with this High Volume Email account.
    • Ensure the application is on the allowed applications list.
• For general SMTP error codes and NDRs, use the documented SMTP error reference to interpret and correct configuration issues.

8. When to use diagnostics or support

• If issues persist after confirming SMTP AUTH, TLS, connectors, and Defender policies, run the automated diagnostic for applications or devices sending email using Microsoft 365 from the Microsoft 365 admin center.
• The diagnostic helps validate configuration and can highlight misconfigurations in SMTP AUTH, relay, or connectors.

By ensuring SMTP AUTH is explicitly enabled for the mailbox, confirming TLS 1.2 support, validating connector and SPF configuration for relay, and tuning Defender policies so that legitimate transactional messages are not quarantined, WordPress-based transactional email should become stable and predictable.

---

References:

• Fix issues with printers, scanners, and LOB apps that send email using Microsoft 365
• Enable or disable authenticated client SMTP submission (SMTP AUTH) in Exchange Online
• Troubleshoot issues with High Volume Email (HVE) for Microsoft 365
• Security Operations guide for email authentication in Microsoft 365

AI-generated content may be incorrect. Read our transparency notes for more information.