Changes coming to the SMTP Authenticated Submission client protocol

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

Comments (6)

  1. Mike Crowley says:

    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.

  2. Dame Luthas says:

    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?

  3. 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.

  4. 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.

  5. @ 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.

  6. Robin Carlsson says:

    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.

Skip to main content