It appears the LiquidFiles SMTP relay configuration does not work. Syslog has the following message: smtp.office365.com[52.96.180.114] said: 535 5.7.139 Authentication unsuccessful, basic authentication is disabled Are there plans to support modern authenitcaiton for Office 365 smtp relay in the future?
The SMTP basic authentication still should work in the 365 service and you should still be able to re-enable it in your 365 sending account. The termination of the SMTP basic authentication was postponed till first half of 2027 for tenants created prior December 2026. After then I would recommend to switch to a other party, less restrictive, SMTP relay service providers like smtp2go.com If you really can't switch from Ms 365 then it's possible to configure their ACS (Azure Communication Services) connector which will still support the SMTP basic authentication or finally remains the OAUTH2 method, which uses short-lived tokens instead of stored passwords, but it's not suitable for servers. LF appliance also supports that OAUTH2 authorization since v4.3 beta (v4.2.5x).
Thank you for the Azure Communicaton Service article. I already had a communicaiton service setup in our tenant. I was able to successfully add and test SMTP within Azure. In LiquidFiles I cannot get past the error message: SASL authentication failed; cannot authenticate to server smtp.azurecomm.net[52.159.232.89]: generic failure
The "SASL authentication failed; generic failure" against smtp.azurecomm.net is almost always one of these: Most likely causes: 1. Wrong username format: ACS SMTP requires the username in a very specific format. It's not just an email address. In the ACS portal under Email > SMTP credentials, the username is generated as <Azure Communication Services Resource name>|<Entra Application Id>|<Entra Application Tenant Id>. Using a plain email address or Azure AD credentials here will fail with generic SASL error. 2. Wrong password: ACS generates a dedicated SMTP password (not the Azure account password, not an app password). It's generated once in the portal and must be copied exactly. If it was regenerated since LF was configured, the old one is invalidated. 3. From address not matching a verified sender domain: ACS enforces that the From address belongs to a domain verified in the ACS resource. If LF is sending from noreply@company.com but only DoNotReply@some-id-1234.azurecomm.net or DoNotReply@yourverifiedoamain.com is verified in ACS, it will reject it. This can manifest as auth failure rather than a relay denied error. Further to this topic: The ACS (Azure Communication Services) can be used as a limited substitution for the Ms 365 relay service. Unfortunately the ACS solution has had these major limitations: Sender address format limitation Sending limitation Configuration complexity Initially when the ACS service is configured then the sender address is restricted only to this format DoNotReply@some-id-1234.azurecomm.net when the Azure's free domain is used. Additionally or optionally it be verified a custom domain for sending. When you have verified your custom domain make sure you have verified also the mandatory SPF, DKIM a DKIM2 records which Azure generated into your domain DNS records then emails can be relayed from this domain but the sender's name in the email is still restricted to DoNotReply and this can not be changed. So if something has not changed in the ACS the sender's email address can be only in this format for verified custom domains: DoNotReply@yourverifiedoamain.com On the LF server side the Email relay configuration (Admin > Configurations > Email) with configured ACS then should look like this: Email Sender Address Policy: Specified Address Only Email Sender Address: either DoNotReply@some-id-1234.azurecomm.net or DoNotReply@yourverifiedoamain.com Email Delivery Security Level: May Opportunistic TLS Email Relay Host: smtp.azurecomm.net:587 Email Relay Username has this format <Azure Communication Services Resource name>|<Entra Application Id>|<Entra Application Tenant Id> or <Azure Communication Services Resource name>.<Entra Application Id>.<Entra Application Tenant Id> Email Relay Password: is one of the Microsoft Entra application's client secrets. To troubleshoot these ACS delivery issue I would start at first test if the emails are delivered properly when you set the "Email Sender Address" at first to DoNotReply@some-id-1234.azurecomm.net. If the email with the Azure's free domain worked then try to replace with the DoNotReply@yourverifiedoamain.com If this did not work then there is something wrong related to verification of the custom domain.
