Further information on Exchange Online/Outlook email send/recieve limitations.

[Steve Roberts]

Hi O365 Community! 🙂

I'm hoping someone can help shed some light on some questions i have regarding the limitations on bulk emails when sending and receiving mail.

My environment:

Exchange online - Cloud only

subscription: E3

Client: Outlook 2016 (click to run software from portal)

Background Info
We have a bespoke application in house that manages all of our communications with our customers which sits on a SQL server back end. Our SQL server feeds email communications into an outlook client using MAPI and then Outlook sends the email to our customers. When a customer replies SQL ingests the email back into the database. We have some mail flow rules that re-direct mail from several accounts to one email account that our application manages.

We send thousands of communications to our customers every day! each of these communications are transnational, and specific to our customers. (this is not bulk spam or marketing, each email is different)

Our problem is this, office 365 only allow a maximum of 10K outbound emails a day, so we would like to spread the loads across multiple accounts and with a little development we can have our in house application do this.

my questions are

Q1. When we use a mail-flow rule to forward a copy of an email to a secondary mailbox, does this count as part of the 10K daily send limit set by Microsoft?

Q2. Microsoft sets a limit of 1millions items per folder, does this have any baring on in-place hold? we move mail from the folders at certain periods throughout the month. But due to the nature of in-place hold will we hit in limits there?

Q3. When we send from the on-prem outlook client, to office 365 does this count as a inbound email? so if we had customers emailing to our email address, and then our client emailing out, does this count as 2 inbound emails? as both are destined for the mail database it the cloud. Or would only our inbound email from our external customer count?

i have read many technet documents regarding the standard limits like the one here: https://technet.microsoft.com/en-GB/library/exchange-online-limits.aspx

but i cannot seem to find answers to my questions? i do not want to develop our app, and make all of these changes, only to discover some strange "Gotcha" later on down the line and still fall foul of microsofts limits

any clarification on this would be greatly received.

thanks

Steve

[#2]

I think Exchange gurus over here will answer your questions properly 🙂 cc @TonyRedmond @VasilMichev How you think about using a different approach to send this massive amount of e-mails? For instance, Azure SendGrid could be an option here

[#3]

Use a dedicated email service for massive email communication. Exchange Online is not designed for this kind of activity and that's why the throttling limits exist. Remember, Office 365 is a multi-tenant environment. If Exchange allowed tenants to send out hundreds of thousands of messages daily, the server load generated by that activity could prevent other tenants working. 

[#4]

yes,

ive looked at solutions like sendgrid, mailgun etc, but i want avoid using a 3rd party. The solution itself is quite complicated and bespoke and I'm trying to keep it simple. id rather have our in house solution manage it, and keep my mail environment as clean and simple as possible.

[#5]

yes i understand,

however this inst bulk spam or marketing, we are not affecting the health of the IP addresses with black lists. we can send from multiple addresses, each with 10K outbound and 80K inbound which is more than we need.

my questions are more "sanity checking" that there aren't going to be any weird limits i haven't thought of before we invest time in development.

thanks for your reply,

[#6]

Well, if you stay within the limits, you should be OK. However, understand that Exchange throttles activities based on server load and this might affect your ability to send messages. With this in mind, I would consider whether this might impact your business processes. It probably won't if the messages are not time-critical; it might if they are.