Jan 12 2017 04:17 AM
Jan 12 2017 04:17 AM
tenant has E3 subscription and uses Exchange Online.
We want to create external "mail contact" who can send emails through SMTP. So we created Exchange Online > Mail user.
User can normally login on https://portal.office.com , and it does not have mailbox or any other O365 application.
The problem is that user does not see its SMTP settings and does not know how to send emails.
When trying to login to smtp.office365.com / 587 / TLS, user login is rejected.
How should "mail user" send emails ? Is SMTP supported?
Jan 12 2017 07:00 AM
Jan 12 2017 07:17 AM
In Exchange Server (on-premise) Mail User feature is a free one and does not require additional license / CAL.
In Exchange Online I did not find any documentation / blog / explanation or limitation that Mail users needs to be licensed to be able do to some things.
The whole point of "Mail contact" which became "Mail user" is to be able send emails.
Also, when I assign a Exchange license to "Mail user" , then it does not get mailbox, but it is also removed from Contacts list forever and is not visible in Exchange cmdlets anymore.
Any offical reference for your answer?
Jan 12 2017 07:40 AM
Jan 12 2017 08:34 AM
I am trying to send email from "Mail User" entity. Not Full / Licenses Office 365 user with mailbox.
Feb 11 2018 02:23 AM
Same problem here. We have a long list of service users in our on-premise environment, one per "service" such as Synology 1, Synology 2, Temperature sensor, Oracle RDBMS 1, etc. Their credentials are used to send email with authentication. For internal mail on Office 365 that should not be a problem. But when you want to relay outside, I will need to configure some other form of authentication like IP-address.
I agree with Hrvoje Kusulja that this is a functional change between on-premise Exchange and cloud.
Feb 11 2018 04:12 AM
The best way is to yuse method 3 on the following article. https://support.office.com/en-us/article/How-to-set-up-a-multifunction-device-or-application-to-send...
For this kind of scenarios is what is best to implement and it's configured in several customers.
Feb 11 2018 04:30 AM
Yes, that one works best. We use it with cname on smtp.COMPANY.TLD. The connectors are somewhat restricted compared to Exchange on-premise.
Feb 11 2018 07:04 AM
cname is not ok, because of server certificates / ssl / tls..., so better use original server name.
Also, if you have dynamic public ip address, then this method is not possible.
It is better that Exchange team implement new functionality, something like Exchange Online - Application user, which will have username/password for SMTP submission, and will not require a license.
Feb 11 2018 07:20 AM
Yes, you are right again, cname has indeed drawback that the certificate does not match the name. I've chosen nonetheless for cname to make it easier to switch. TLS is not so strict currently in our nodes. But it is indeed not the right approach for optimal security.
May 24 2019 06:36 AM
It is possible to send for free, through Azure AD App and using Microsoft Graph API ...