Email throttling — limiting messages from being sent
Email throttling means limiting the number of emails you send to a (specific) domain. The receiving side often set limits on the number of messages or connections they accept. When an SMTP client opens a connection, the SMTP server typically responds with a 220 code, but in some cases, it may reject the connection. If too many connections are rejected, you might be (temporarily) blocked. This is why you should throttle your email.
Slowing down your outgoing email flow may help your reputation as a sender, too. A good sender reputation can result in decreased limits.
Reasons for rejected connections
You may never know the exact reason for a rejected connection, because SMTP servers have the tendency to respond with quite cryptic errors. Some SMTP servers even use error codes differently.
That being said, you should react to those error codes. ‘5xx’ error codes, mostly known as hard bounces, for example, can indicate that an email address no longer exists. Repeatedly sending to non-existing addresses generally results in a bad sender reputation and lower sending limits. ‘4xx’ error codes or so-called ‘soft bounces’ notify you that some temporary condition has caused a failure. If you throttle your emails, you’re able to avoid errors such as ‘too many simultaneous connections’.
These error codes can appear anywhere during the SMTP dialogue. This means that the only thing you can be certain of is when a connection is dropped. That is why logging your SMTP connection can be valuable in determining why a connection is abandoned.
An SMTP dialogue
Below, you’ll find an example of an email being successfully delivered. You might notice all kinds of 2xx success codes. If instead of a 2xx code you see a 4xx or a 5xx code, this indicates an error. After such error, your message is off course not delivered.
<<< <wait for connection on TCP port 25>>>> <open connection to server><<< 220 example.com SMTP service ready>>> EHLO somecompany.com<<< 250-example.com>>> MAIL FROM:<sender@somecompany.com><<< 250 sender <sender@somecompany.com> OK>>> RCPT TO:<jon@example.com><<< 250 recipient <jon@example.com> OK>>> DATA<<< 354 enter mail, end with line containing only “.”…>>> .<<< 250 message sent>>> QUIT<<< 221 goodbye
Sender reputation
With a good reputation, your limits will be much lower. To build a good reputation you have to slowly warm-up your IP addresses. This can be done initially with low email throttling limits. Then you slowly increase your limits. Even if you’re only sending legitimate email, warming-up your IP is still necessary. Suddenly sending a large number of emails from a single IP without any sending reputation looks very suspicious.
Artificially limiting the number of attempts, connections and the number of messages over a single SMTP connection can improve your deliverability and reputation as a sender. Even your limits may be increased when you improved your sending reputation. To find out what your sending limits are, you can monitor your connections. If you have a lot of errors for a specific domain, you may want to slow down your sending for that domain. The main goal is to be predictable. Receiving domains like predictable patterns.
Domains using the same mail server
It is possible to have multiple domains using the same mail server. This can be specified for every domain using a simple MX-record (Mail eXchange record) in its DNS. Setting up email throttling rules just for multiple domains may or may not be necessary, depending on your Mail Transfer Agent (MTA); some MTAs give you the option to setup MX based rules.
Automatically reacting to error codes
Just limiting your messages from being sent is not a solution on its own. Receiving domains may automatically change their limits every second. That is why you want to dynamically change your limits based on patterns in your traffic. The game is to closely match the limits set by the SMTP server. Throttle settings only limit your outgoing email flow, you may also want to speed up or slow down even more.
Email throttling does not work when there is a connection problem. If such a problem presents itself, you want to pause sending and slowly build up connections after the pause. This can be done with features like Dynamic Delivery or Response Patterns to enable a Backoff Mode. Response patterns or Dynamic Delivery features should automatically react to specific errors from receiving mail servers and override the default email throttling settings. These features enable you to react to limits set by receiving domains.
