This solution describes the best practices for setting the bounce and retry configuration to achieve optimal mail delivery performance.
What bounce and retry means to deliverability?
ListManager has two primary mechanisms to deal with undeliverable email addresses. The main goal of these mechanisms is to minimize the number of attempted sends to invalid or bad addresses.
Sending to bad addresses not only taxes the server and reduces sending performance but can also cause the ListManager server to be considered as a spammer by the destination mail servers.
Bounce limit:
The server automatically keeps track of how many times a particular address has been consecutively undeliverable. Addresses that are undeliverable repeatedly are usually bad or invalid.
After this consecutive count exceeds the bounce limit the member is held. This prevents them from being tried for future mailings.
Reasons for modifying bounce limits:
- Lowering the bounce limit:
- For lists with many bad emails, it can be prudent to lower the bounce limit, to minimize the number of repeated sends on bad addresses by quickly holding them.
- Raising the bounce limit:
- For lists with a very low percentage of expected bad addresses (such as previously mailed addresses), a higher bounce limit can help to minimize good addresses being held due to a temporary issue.
Retry timing:
Navigate to: Utilities: Administration: Server: Server Settings: Network Settings -> Deliver Email tab
Sometimes an attempted send to a member will return a transient failure.
This category of error covers all cases where the receiving server did not explicitly send an error indicating that delivery will not succeed on a retry. One example of a transient failure is when network congestion prevents ListManager from opening a connection to the destination mail server.
ListManager will automatically try to send to that member again. How quickly and how many attempts will be made is determined by the retry timing.
Our recommended settings for most senders are as follows:
30,30,30,30,45,45,60,60,75,75,90,90,120,120,120,180,240
This corresponds to a max retry time of 24 hours, though in practice other factors such as DCLs may occasionally result in a somewhat higher max time in the queue.
Reasons for modifying retry times vs. recommended settings:
- Lowering or shortening number of retries:
- For servers running on very old or low-powered hardware, frequent retries may reduce overall server performance or contribute to sending speed bottlenecks.
- For messages with very timely information, it may be undesirable to attempt to deliver past a certain time period.
- Raising or extending the number of retries:
- For messages with lower time sensitivity of content and higher bounce rates and/or higher spam complaints, a higher number of retries may improve delivery in throttling/deferral situations caused by ISP filters.
