Smart Delivery Optimization (SDO)

Retarus uses a mechanism for Inbound and Outbound Smart Delivery Optimization that controls dispatch and reception for emails. The outbound Smart Delivery Optimization automatically adapts the customer's sending behavior to the feedback from individual ISPs and/or ESPs in order to keep the throughput of messages at the ISPs and/or ESPs high. In exceptional cases the optimized dispatch control can lead to a reduction of the agreed processing capacity.

SDO Inbound

The guaranteed hourly capacity is enforced as defined in the contractual agreement by the SDO-Inbound feature, on customer level. All incoming requests over REST and SMTP APIs to the retarus infrastructure are checked against the defined limit within the customer number. In order to cover possible rounding errors, we implicitly extend the hourly booked capacity with up to 25%, this is however not a guaranteed capacity.

As limits are usually very high, we require all customers to distribute the booked capacity evenly across the hour, as it is not possible to send the defined limit all at once. Thus, the guaranteed hourly capacity comes with an essential precondition that you have a mechanism staggering the traffic evenly across the hour on your side, ensuring an even spread of the workload. We check the traffic distribution using 5-minute timeframes and make sure the throughput is proportional to the booked hourly capacity. This means, for a guaranteed hourly capacity of 150.000 emails/hour your guaranteed maximum throughput would be (150.000 emails/hour) / (12 timeframes/hour) = 12.500 emails / timeframe. With the implicit capacity extension of 25%, the throughput could reach a maximum of up to 15.625 emails / timeframe.

In case you reach the limit you will receive a HTTP response with code „429 - LIMIT_EXCEEDED“. We recommend you to use a retry mechanism for this scenario.

Example of HTTP response with status code 429

{
   "meta":{
      "jobId":"41455798-70c6-4cd4-bae8-df03d1a6aa29",
      "state":{
         "type":"REJECTED",
         "subType":"LIMIT_EXCEEDED",
         "phase":"PRE_PROCESS",
         "description":"Request rate limit of %d recipients per hour exceeded."
      },
      "account":"m4a_test_user"
   }
}

In case you reach the limit over the SMTP API you will receive a response with code „450 4.7.0 Request rate limit of %d recipients per hour exceeded.“. We recommend you to use a retry mechanism for this scenario.

SDO Outbound

The SDO Outbound Solution check the transmission-logs to the recipient-ISP/ESP. During a high-volume transmission, receiving ISPs/ESPs are not able to process many messages at the same time and give us feedback in form as a SOFT_BOUNCE.

Sample of ISP soft bounces

[4.0.0] deferred (host freemx2.sinamail.sina.com.cn [113.108.216.47] said: 452 Too many recipients received this hour. Please refer to http://chengxin.mail.sina.com.cn/info/qa.php?p=ca1-452 XX.XX.XX.XX (in reply to DATAcommand))

[4.7.652] deferred (host outlook-com.olc.protection.outlook.com [104.47.37.33] said: 451 4.7.652 The mail server [XX.XX.XX.XX] has exceeded the maximum number of connections. (S3115) [CY1NAM02FT045.eop-nam02.prod.protection.outlook.com]

[4.4.2] deferred (host extmail.bigpond.com [XX.XX.XX.XX] refused to talk to me: 421 4.4.2 Connection refused due to exceed max concurrent connections . IB007)

[4.0.0] deferred (host smtp-in.orange.fr[XX.XX.XX.XX] refused to talk to me: 421 mwinf5c84 ME Trop de connexions, veuillez verifier votre configuration. Too many connections, slow down. OFR004_104 [104])

Our aim is to send all messages smoothly. In case of a hit, we throttle the outbound channel, to prevent that receiving ISPs/ESPs put us on a Graylist or Blocklist. We’ve implemented a four-tier outbound channel, with different speeds for transmission. During the whole transmission our service is checking the behavior of the ISP/ESP. Using the SMTP information, we are able to detect if we could switch the transmission back to normal or if we have to switch to next lower channel.

SDO Outbound Monitoring

Retarus provides status information on every email sent via the API callback (HTTP Push Notifications). You will be informed about newly created events e.g., delivery status, reasons for undeliverability, blocking of emails to recipients listed in the Suppression List, etc.

Within our API Callback solution, you will be informed in case that we have throttled your transmission with following event types: