Software Development, Technology and Innovation

Application Emails & Office 365 Send Limits

In our environment at Readify we have a mail-gateway in a private environment that we use to route e-mails from various internal systems onto our cloud hosted environment (was BPOS, is now Office 365). Due to the e-mail problems we had last week those e-mails queued up, and queued up, to the point that we had thousands of the e-mails sitting there.

When we finally switched that mail gateway to use Office 365 we got a flood of e-mails, followed by a series of errors inside our various systems. Turns out that we were hit by a policy around sending limits inside Office 365. We raised a support case but unfortunately this can’t be configured. I guess they are trying to mitigate the risk of people using Office 365 as a spamming platform.

In our case its completely legitimate. We have a lot of systems that generate unique e-mails to various users. Most of those e-mails come from one account (noreply@readify.net) to signify that they are machine generated. Incoming e-mail to the noreply@readify.net mailbox is periodically checked for issues but hopefully the e-mail address discourages it. The kinds of systems that use this are:

Team Foundation Server

SharePoint

Dynamics CRM

Heaps of custom applications.

As I said, it appears this can’t be changed. We only hope that we won’t be impacted again since the volume of e-mail that was queued up was a result of days of delay. That said, this limit could be an issue for larger organisations wishing to use Office 365 where internal systems need to interact with mailboxes and send personalised e-mails.

The URL that outlines the policy on the Office 365 site simply suggests that you set up an on-premise mail server. In our case I guess we can probably add our mail gateway as an entry to our SPF records and get it to route mail directly. Its kind of a shame that you have to do that however.

A Better Way

For developers building applications that send customised e-mails on a regular basis, you might want to consider using a service such as Mailgun or the Amazon Simple Email Service. I’m not sure which is better since I haven’t used either (good old SMTP relay is usually good enough for me) but these tools do add an extra level of reliability around detecting issues and allow for corrective action, where SMTP relays, or more precisely programs that use them just drop bad messages like a hot potato, even if it is a transient issue.

P.S. After some searching for how this problem is generally addressed by Windows Azure customers I came across a link to this other service – Elastic Email.

Post navigation

2 thoughts on “Application Emails & Office 365 Send Limits”

Hi Mitch, I know this problem well – Machine generated email is always overlooked! If you look at the deployment guide from Microsoft under ” Mail-Enabled Applications” it will state this. Its a big problem for Enterprise customers who usually have no idea how many machine generated SMTP apps they have inside the corporation ranging from ERP & CRM apps which feed revenue recognition systems, customer support systems. A lot of these probably come from a variety of sources over years when various departments implement systems, contractors or professional services organizations from SAP, SalesForce etc. One of our customers originally estimated they had under 1,000 but now the count has grown to be 2,500 and Microsoft want nothing to do with them!! Microsoft provide a maximum of 10 IP connections and that sounds like a lot but when all these machine generated apps need an IP connection and ther is not one, things break and important apps do not work. Have a look at http://www.sendmail.com/sm/sentrion_appliances/sentrion_mpe/ as it might get you or your customer out of a tight corner.

Thanks for the advice Matt. Personally I think that Microsoft should just pull their finger out on this one and raise the limit. Even if it has to be a manual request that you do through support. Clearly we aren’t spamming, we are just conducting our business.