Sender Reputation Part II: Splitting Email lists across VirtualMTAs | Port25 Solutions, Inc.
Blog
Deliverability
Fred Tabsharani
PowerMTA
VirtualMTA Technology

By port25admin

Sender Reputation Part II: Splitting Email lists across VirtualMTAs

P25In our previous post my friend Steve Henderson from Email Service Provider Communicator wrote an article exclusively for Port25 and PowerMTA users.  In part I we looked at how email filtering using sender reputation has brought about a change in sending behavior necessitating admins to rethink email delivery best practices and configurations.  In Part II, we’ll take a look at some different ways to optimize PowerMTA to work with the challenges introduced by reputation-based delivery.

Typical Setup
Regardless of whether you use dedicated or shared IP addresses you typically assign a sender to an IP address using a VirtualMTA (VMTA). The data used in email campaigns, the sending patterns and the recipient responses for the sender or senders generate the IP’s reputation.  You then monitor and optimise the delivery settings for that MTA based on the delivery and bounce information which is collected. Reputation-based delivery means that active and targeted data are easier to reach inbox delivery, than non-targeted and less-active data. A regular email sender will usually have mix of “good”  data and bad data; and send acquisition, retention, targeted and non-targeted campaigns.

Sending the active, inactive, targeted and non-targeted email all from a single IP and a single VMTA will mean that the IP reputation will be based on an average of all the campaign and data types. The sending optimization for these different data and campaign types will also be an average and sub-optimal.

Reputation and scenario-based VMTAs
Instead of chasing a moving target and trying to optimise delivery for one or more email senders who send a variety of campaign and data types; defining a range of scenario-based VMTAs customisation lets you flip this concept on its head and work a bit smarter.

Here is an example to illustrate the concept:
VMTA Patterns

Instead of just having two IPs for marketing and notification emails we define four VMTAs in PowerMTA. The marketing campaigns still go from one IP and notifications from another; but we use the extra VMTAs to optimize the delivery based on our understanding of sender reputation delivery albeit behavioral data.  Splitting the marketing emails across multiple VMTAs allows us to prioritize and configure delivery for each scenario. For the above situation you may have the following code:

<virtual-mta newdata>
  smtp-source-host 11.222.33.444 yourdomain.com
  queue-priority 70
  bounce-after 4h
  max-msg-rate 10/min
</virtual-mta>
 
 
<virtual-mta active>
  smtp-source-host 11.222.33.444 yourdomain.com
  queue-priority 90
  bounce-after 48h
  max-msg-rate 200/min
</virtual-mta>

 

<virtual-mta inactive>
  smtp-source-host 11.222.33.444 yourdomain.com
  queue-priority 60
  bounce-after 24h
  max-msg-rate 50/min
</virtual-mta>

 

<virtual-mta notification>
  smtp-source-host 11.222.33.555 yourdomain.com
  queue-priority 100
  bounce-after 1h
  max-msg-rate 200/min
</virtual-mta>
 

 A setup like this allows you to define different queue sending speeds, priorities and expiry times.  This is different from the typical setup because instead of having to reconfigure an email sender’s VMTA based on the campaigns they send and the data they use, you can pre-define the VMTAs and then just assign your emails to the appropriate VMTA by adding the x-virtual-mta header to your emails.

While sending emails in this way can lower the risk of sending to unknown or inactive data it can never replace good data practices. Even small amounts of inactive or poorly validated data can result in delivery problems, so this approach should be used alongside good data hygiene and sending best practice.

Taking things further
Delivery queues in the PowerMTA Management Console,  show responses from recipient domains.  Separating different campaign and data types over custom VMTAs  helps identify data, delivery and reputation issues with more accuracy; and also allows you to manage those queues directly.  The above example just shows the start of what you can do. By defining a range of VMTAs for each of your sending requirements,  you can assess your campaign and data prior to sending and assign emails to the appropriate VMTA and help get the best delivery for that campaign.

Here are some scenarios which might benefit from being sent from customised VMTAs:

  • New, untested data, or data from unknown senders
  • Recent openers
  • Data from trusted senders
  • Acquisition mailings
  • Retention mailings
  • Notifications and alerts with a short lifespan
  • Re-engagement campaigns and inactive data
9160 Guilford Rd // Columbia, MD 21046 // (410) 750-SMTP