Email deliverability has truly become a science, and there’s no denying that science can be complex, even difficult for some to understand. Yet, over many years, accomplished scientists have learned that experiments often reveal the answers to important questions and problems. The same concept also applies to email deliverability. In many instances, postmasters of organizations must experiment with delivery configurations in order to optimize inbox placement and pacify receiving networks.
Experimenting can also be helpful in warming up new IPs. Below are the latest experiments that may help you to optimize your sends when configuring new IPs. This set of “tips” comes directly from the field, with insights from delivery consultants with hands on experience.
In regards to IP warm up specifically, here are some of the latest experiments and tips you can use with PowerMTA features:
- Restrict daily volume (per IP and per domain) for cold IPs
- Route overflow volume to a legacy server during IP warm up
- Roll up queues to different domains of a single ISP
- Automatically stop sending in case of reputation related errors
- Log transient errors to monitor reputation related errors
Restrict daily volume per IP per domain for cold IPs
When an IP has no reputation yet, it is important to limit the volume, as seen from the provider. An unexpected large volume from an IP might trigger spam filters to block the IP. This is to protect against compromised computers and to give the spam filters some time to check how recipients or reputation systems respond to the mail. The cold-virtual-mta and cold-virtual-mta-msg directives in PowerMTA can be used to send a daily quota of emails from a cold IP to each domain.
Route overflow volume to a legacy server during IP warm up
Suppose you are migrating from a general purpose mail server to PowerMTA. You can use PowerMTA to warm up new IPs, while sending the remaining volume to your old mail server. During a period of a few weeks to a few months, depending on the volume, more and more mails are sent via PowerMTA and the new IPs. This can be accomplished by submitting the mails to PowerMTA, and configuring PowerMTA to forward to the old mail server. The route directive is used to implement the forwarding.
Roll up queues to different domains of a single ISP
If a provider hosts multiple domains, then the volume that the provider sees from an IP is the sum of the volume sent to its domains. For example, Hotmail hosts many domains, which all resolve to the same MX hosts, and are processed by the same system. When you want to limit the volume to a provider, you need to control the total volume sent to the MX hosts of the provider. This can be done by having PowerMTA “roll up” the queues of specific domains to one single queue. To consolidate the queues in this way, use the domain-macro, the queue-to and the route directives to create a single queue for multiple domains of a provider. Then you can control the volume to the provider with the max-msg-rate directive.
Automatically stop sending in case of reputation related errors
Setting a limit on the volume can prevent deliverability issues due to volume spikes or bursts. However, at times, the average volume may still be considered too high by the provider. When that occurs, PowerMTA can “adapt” to the situation by scanning for specific SMTP errors, and hold back when the provider returns a limit or block related error. This way, less SMTP errors are generated, which could have a positive effect on reputation. In practice, this means using the smtp-pattern-list directive together with the backoff directives.
Log transient errors to monitor reputation related errors
Postmasters often look at permanent (5xx) errors and DSNs (bounce mails) to see what is going on and discover any deliverability issues. However, transient (4xx) errors can also reveal interesting information about the performance and reputation of specific providers. Most 4xx errors are related to greylisting, but more interesting are the errors related to volume or reputation issues. These errors could indicate that certain parameters need adjustment, such as number of concurrent connections, number of mails per connection, rate of sending, etc. They can also indicate if there is a problem with complaints, causing the mail to be deferred. In PowerMTA, you easily can add transient errors to the regular logs, or add another log with only transient errors for diagnostic purposes.
It is undeniable that email deliverability can be complex—especially when configuring new IPs is thrown into the mix. However, just as in the scientific community, the only way to solve problems is to experiment with different solutions. Hopefully, some of the PowerMTA features will be helpful in solving email deliverability problems. Of course, each deliverability situation is different. You may have to experiment with different combinations of these tools before finding the solution that provides optimal performance while warming up new IPs.
This blog post was inspired and partially written by Maarten Oelering of www.postmastery.com