I have this problem on my application to relay email through port 587 of our Exchange 2010: error prompt was 4.4.2 Message submission rate for this client has exceeded the configured limit.

I understand this is due to the MessageRateLimit of my receiver connector. I checked the limit is 5 and limit by user (MessageRateSource), and I think the problem probably will be fixed by increasing the limit to 50 or 100. However I would like to understand this configuration more (how if I set it to 50 now and it hit the same error tomorrow?)

Based on MS site, this is throttling setting to limit "The maximum number of messages per minute that can be sent by a single source". So I tested using powershell script (not sure whether it does matter, so I include the partial code below):

$SMTPClient = New-Object System.Net.Mail.SmtpClient( $emailSmtpServer , $emailSmtpServerPort )
$SMTPClient.EnableSsl = $true
$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($emailSmtpUser , $emailSmtpPass );
#[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { return $true }
$SMTPClient.Send( $emailMessage )

In this script I'm first submit the email with another user ID, and the result: I'm able to submit email to the same receiver more than 5 times within a minutes. So why does the limit not applied to this case?

After that, I tried the script with my application ID, the same error (4.4.2) prompted. I then checked the tracking log explorer and I found there is no other email submitted with that application ID. So is it Exchange store the user count some where which I need to reset it? And how can I trace the email submission? It doesn't seem appears in tracking log explorer, so as my concern earlier, it might hit the same error even I change it to 50, I'm unable to troubleshoot further without able to trace them.

Sorry as the question is a bit long.

Appreciate if anyone can provide me some clues.

2 Answers 2


I am going to flip this question on its head. When a client comes to me with this issue, the first thing I ask is why are the messages being relayed through Exchange? Exchange makes a very poor bulk emailer, and there are better options. Why isn't the application sending the email itself, or via its own server rather than Exchange?

If you have an application sending so much email to external recipients that it is tripping over the throttling limits then I wouldn't want that anywhere near Exchange. It is only a matter of time before it gets blacklisted. Own IP address, own PTR and DNS and send email itself.

Not the answer you are looking for I admit, but often thinking of the issue another way gives you a better way of dealing with the issue.

  • Hi thanks for your respond, I understand what you mean. But for us the application is handled by our vendor and I'm in charge of the Exchange. The problem now is I'm unable to trace the email submission to prove that the application did submit more than the limit. Is the email submission logged some where in Exchange tracking or in Windows event viewer?
    – nlks
    Feb 22, 2017 at 0:59
  • You would probably need to enable logging on the Receive Connector. Even though the application is handled by a vendor, I would still be looking at using something else to relay the email, particularly if it is just going straight back out again.
    – Sembee
    Feb 23, 2017 at 8:48
  • Hi @Sembee, the application actually does not sending bulk email but just there might be more than 5 (perhaps 1-15) in a minutes. I will explore on the receive connector logging, I believe that shall allow me to trace the submission and solve my problem. Marking your reply as the answer, thank you very much for your advice!
    – nlks
    Mar 3, 2017 at 8:21

Throttling within exchange is quite powerful but - afaik hard to track.

In my experience setting limits on connectors is quite problematic as you may have only a very small subset of users that are sending high volume. Pushing the limits on the connectors for few users exposes an increased risk of abuse by a compromised account.

Throttling policies

When working with higher volumes you should determine your highest message rates and set these to your receive connector. This is your global limit.

Next you should establish first a Throttling-Policy that reduces the limit back to a moderate value (like 5 msg/min) as organizational policy.

Finally you can add additional policies that raise the sending limit for specific users.

This doesn't expose 'mass-mailing' limits to all users that can access the given connector and allows more granular control.

You can get more information about policies in the documentation.

Detecting limits

While it's a good point for diagnostics, I wouldn't start trying to handle reaching the limits on the server side.

There are propably more outcomes that indicate failure that success when sending mail. Reaching the rate limit is just one of them. And your application needs to handle these, as well as scenarios where the whole mailserver may not be reachable due some downtime.

Therefore I would strongly recommend to focus on proper error handling and a queuing mechanism in your application. Check out ways to get the SMTP dialog messages and log them in case of failure. This will enable quick and easy diag in production - not only for this specific case.

As @seembee said, sending high volumes increases the risk of getting blacklisted. This risk is still given when bypassing exchange and using dedicated mass-mailing hosts. Sending stuff like newsletters i would agree completely. But when you're sending important mails like invoices that may even have legal restrictions on the mail-flow i wouldn't recommend to bypass the exchange-infrasructure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.