Exchange Online - Mail User - without license and how to send email / SMTP access



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 , 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 / 587 / TLS, user login is rejected.


How should "mail user" send emails ? Is SMTP supported?


Thank you

10 Replies
That user can't send emails in this configuration. He has to have a mailbox in Office 365 to be able to send emails.


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?


Thank you,

Kind regards

It's not exactly clear to me what you want to achieve, but if you want to perform smtp client submission (I came to this conclusion because you mentioned, then you need to have a mailbox in Office 365.

Check this article, maybe you find an explanation there:

I am trying to send email from "Mail User" entity. Not Full / Licenses Office 365 user with mailbox.


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.

The best way is to yuse method 3 on the following article.

For this kind of scenarios is what is best to implement and it's configured in several customers.



Yes, that one works best. We use it with cname on smtp.COMPANY.TLD. The connectors are somewhat restricted compared to Exchange on-premise.

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.

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.


It is possible to send for free, through Azure AD App and using Microsoft Graph API ...