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 (email@example.com) to signify that they are machine generated. Incoming e-mail to the firstname.lastname@example.org 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
- 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.