Changes coming to the SMTP Authenticated Submission client protocol

Published Apr 20 2018 11:48 AM 51.5K Views

There are a number of client protocols offered by Exchange Online to allow email clients to send email from their mailboxes. One of the most widespread protocols is SMTP Authenticated Submission (also known as SMTP Client Submission) which is supported by most email service providers. This non-proprietary protocol is used to send email by legacy email clients, third-party software and services, and devices such as multi-function printers. Changes that we’re making to how this protocol works in Exchange Online may adversely affect the rate at which these clients or devices can send email. Starting June 1, the following changes will begin rolling out for SMTP Authenticated Submission protocol:

  • Sent email will now be stored in the Sent Items folder of the mailbox.
  • Only three concurrent connections to our service per mailbox will be allowed. Additional connections will be rejected with the error: 4.3.2 STOREDRV.ClientSubmit; sender thread limit exceeded.
Exchange Online uses a number of mechanisms to protect the service from abuse and ensure fair usage by users. One such protection is the Recipient Rate Limit (RRL) which limits the number of recipients per day to 10,000. The aim is to deter the sending of bulk email (and as mentioned on the service limits page, you should send bulk email using a specialized third-party provider). This change to the SMTP Authenticated Submission protocol will further protect the service from large bursts of emails in a short amount of time from automated systems. This will not affect the majority of SMTP Authentication Submission users who only send from one email client or multi-function device for a given mailbox. For customers who have numerous devices sending emails using the same mailbox (for example,, there’s a small chance that multiple devices will try to send email at the same time. Any devices that are rejected would just need to retry. The same is true if an application that uses a cloud mailbox to send email tries to send multiple messages at the same time (and that behavior depends on how the application was designed). Most applications and devices that send email should be able to handle errors and retry sending email. However, retrying will reduce the overall rate at which email can be sent. If this change adversely affects you, you have a few options:
  1. Use a different mailbox for each application or device.
  2. If you’re trying to send thousands of copies of the same message (for example, a newsletter) in parallel using a third-party application, you may need to send it out in batches or use distribution groups.
  3. If time is important (for example, an alert system that generates multiple alerts at the same time), you’ll need to use a third-party delivery service that’s designed to send large amounts of email.
Sean Stevenson

Not applicable
Can you elaborate on the first bullet? Why are submitted items now being copied to the user's sent items folder? is this a customer requested change? I would expect this to be undesirable for most users, also risking quota-based lockouts due to email which isn't expected to be saved in the user's mailbox.
Not applicable
Re: The first bullet point (Sent Items location)

While I’m very familiar with the issue with:

- Compromised accounts

- The importance of paying close attention to Azure risky logins

- Time spent identifying and removing these messages from the tenant

I have several questions regarding the overall solution..

How will this affect:

- Multiple accounts being used within the same profile?

- Messages created offline?

- Messages created while the user is unable to Authenticate to the service?

- Will the user receive some type of notification if they were to open the outbox?

- Can admins control how these changes are applied to Outlook Clients? Perhaps a grace period for the transition?

- Will OFFcat be updated in preparation for this change?

Regarding, the second bullet point (Concurrent connections) - I'm curious how this will affect mobile devices?

Not applicable
Hello Mike,

The change aligns the SMTP Auth Submission protocol with other protocols' behavior of having a submitted email go through the Outbox and then placed into the Sent Items folder once it is send out. This have been asked for by customers who find it difficult to troubleshoot issues sending emails without a record of successfully sent emails.

If storage is a problem, there is the option of creating a retention policy for the Sent Items folder to avoid having the 50GB/100GB mailbox size limit reached.

Not applicable

I missed that this change was coming and have noticed the storage of emails in Sent Items in recent weeks - it confused me for a while!

You say, "This have been asked for by customers who find it difficult to troubleshoot issues sending emails without a record of successfully sent emails."

That's all well and good but I've not had any problems troubleshooting issues. I really don't want my Sent Item clogged up with emails sent from my scanner. Why can't this behaviour be turned off? Even if I were troubleshooting, I'd want to turn it off when I'd resolved my problem.

Is my only option to have a mailbox specifically for my scanner so that the Sent Items aren't seen?

Not applicable
I have a question regarding 3 concurrent connections.

What is the wait time between 2 connections, after which they are not concurrent?

We send many emails using SMTP Authenticated Submission, but never at the same time.

Not applicable
@ Dame Hitting this throttling using multiple email clients will be extremely rare. Regarding messages created offline and queued for sending, an email client with a large queue of messages should only be opening a single connection to us and submitting the messages one by one. Clients would receive a temporary error and it should retry by itself without little for the user to notice. Outlook clients should not be affected by this as they should not be using SMTP Auth protocol to connect to Office 365 when there are more modern protocols available. This change will not have an option to opt-out. The connections from mobile phones or desktops will only apply when emails are actually being sent.

@Infiltrator There is no wait time of any significance. If you are not sending at the same time, you have nothing to worry about.

Not applicable
Hi, have this change been implemented in all Office 365/Exchange Online tenants yet? Or when are you planning to roll out these changes? I am specifically interested in having sent emails available in Sent Items folder.
Not applicable
We run an application that relays email via Exchange Online over SMTP. One of the features of this application is the ability to track emails on a per-recipient basis, even for grouped emails. For example, if an end-user sends an email with 2 email addresses in the TO field and 1 email address on the CC field, this application, it will report when each of the 3 recipients has opened the email.

To do this, it leverages the decoupling between the SMTP envelope and data. It connects to and issue 3 send-email transactions. Each transaction includes ONLY 1 of the recipients in the "RCPT TO" command. The data field contains identical headers across all 3 email are identical. In the example above, they all contain the 2 email addresses 'To' header and the 1 email address in the 'Cc' header. However, the message body will include a unique image URL.

This application has worked flawlessly over the past 3+ years allowing us to implement fine-grained email-open tracking.

However, over the past few days, there seems to be a change email where multiple emails are being delivered by Exchange. Each recipient in the email is getting the email where their email address is in the RCPT command AND every email for all other recipients as well! It appears as though Exchange is delivering emails to every email address mentioned in the RCPT command AND in the To and CC headers.

Consider the following SMTP transcript:







Subject: test email

test 1







Subject: test email

test 2



I would expect user1 to receive 1 email with the text 'test 1' in the body and user2 to receive 1 email with text 'test2' in the body.

Instead, user1 receives 2 emails ('test 1' and 'test 2') and user2 receives the same 2 emails!

This doesn't seem correct. Is it a side-effect of this change? Any way to restore the correct behavior?

Not applicable
Last week every customer we have sending automated emails with multiple recipients through starting receiving duplicates for each recipient. We are submitting those emails with the same message id (because it is in fact the same envelope data) multiple times with a different RCPT TO call each time. With each additional connection all the previous connections RCPT TOs get sent to again. Not sure where or how to report this so here I am.
Not applicable
We are experiencing duplicate emails problem as well. And per premier support, this above change is directly related to it. And they are working to resolve the problem.
Not applicable
We are an O365 customer and have a user who used to be able to override the displayName on outgoing messages using his IMAP client (which sends using authenticated SMTP) because he doesn't like our default displayName format. On September 17th this stopped working and the displayName on his messages is the one from our directory instead of his customized one and he's complaining. Is it possible that this new behavior was related to this change being rolled out?
Not applicable
Is it possible to restrict "SMTP Client Submission" to a range of IPs? We would only want our own devices (eg printers) to talk via SMTP. We can disable IMAP and POP on a mailbox, but cannot find any way to disable SMTP Client Submission.
Occasional Visitor

We recently migrated from local Exchange to O365. We have some console apps that periodically check for and send out queued emails in batches. 


We discovered that if we didn't throttle the send rate in the smtp loop, the O365 account used to authenticate with our tenant would start getting 5.2.0 connection errors "STOREDRV.Submission.Exception:SubmissionQuotaExceededException".  We put in a 3-second delay which would throttle the emails to 20/minute, which seems to work OK (I believe the rate limit is still 30/minute?).


Recently one of our apps ran without the delay, and the user account used to send emails started getting blocked. We disabled the process and added back in the delay, but we're still unable to connect with that user (changing the SMTP authentication to a different user worked fine).


My question is, how long does the block stay on the account? an hour? 3 hours? 24 hours?

Occasional Visitor


is there a way to deactivate "Sent email will now be stored in the Sent Items folder of the mailbox." for a mailbox?

This behaviour is not GDPR comliant in our use case.

Occasional Visitor

@The_Exchange_Team I would also like a way of turning this feature off, our customer service team is finding it hard to filter through our dispatch emails to find emails they have written, and automated rules don't work on the sent items folder very well.

Occasional Visitor

@The_Exchange_TeamI'm starting to hit the sender thread limit exceeded problem sometimes. Our platform sends out emails to notify when services are down.


We are currently using SMTP Authenticated Submission. If we switch to sending emails using Modern Auth, will the 3-simultaneous thread limit still apply?

Version history
Last update:
‎Jul 01 2019 04:33 PM
Updated by: