I'm posting this in the hope of saving someone else from wasting their time on trying to get 6.3 to relay through Office 365 via TLS.(it doesn't work).
SummarySending alerts from the VSA directly to Office 365 users works fine. However, using the VSA to relay email alerts to users OUTSIDE of our Office 365 mail system does not work.
SymptomWhen the VSA generates alerts and they are queued to relay to users outside of our Office 365 install, the VSA log shows failed and the log detail shows "Must send StartTLS command".
I edited the Outbound email properties on the VSA server and pointed to pod51018.outlook.com using port 587 (TLS) and did a test email. Office 365 REQUIRES a TLS based connection on port 587 (standard TLS port) to relay email to users outside of your Exchange organization. I independently verified the Office 365 server, username and password using the system diagnostics from checktls.com, All TLS tests checked fine.
DeterminationAfter weeks of discussion with support (and emails back/forth) I received confirmation from Kaseya support that this feature is not supported. Here's what was sent as the closing comment (Ticket CS146527) by Kaseya Support:
TLS on sending emails is not currently supported and this issue will be escalated as a feature request.
WorkaroundAs a work-around, I setup an SMTP server (Microsoft Mail) on the same server as where the VSA. I send the VSA alerts to this server which then relays via TLS to Office 365 and then out to the external email recipients.
I just ran into the same problem, however mine cropped up after out Office 365 account was upgraded.
After some trial and error, and finding this post, I was able to get this working again and send to email addresses inside and outside my organization without having to use any workarounds. My settings are as follows:
Host Name - smtp.office365.com
Port - 587
User Name - email@example.com
Password - examplepassword
Require SSL - yes
Default Days to keep Logs - 90
Retry Limit - 5
Retry Interval - 1
Default sender Email - same as username above
Not sure if anyone is having this problem anymore, or if the Office365 upgrade fixed it, but it is possible now.
Some additional information. Using Ben's configuration also works for me both internally and externally. However, if the "User Name" doesn't match the "Default Sender" name it will fail.
We send Keseya reports using different "From" addresses and our emails were failing to get through and giving the "must send startTLS command" error.
To stop this error, in Office 365, either give (deligate) Send As permissions for the account used in the "User Name" to the account for the "Default Sender" address, or add the Default Sender address, and any other addresses Kaseya sends as, as an alias of the account used in the "User Name" section of the Kaseya outbound email configuration.