We have had many conversations with users and prospective customers about shaping message delivery based on a particular user instead of just IP or Domain. This is critical to ESPs who may host multiple customers on a pool of IPs or have multiple message streams on the same base domain. Once they have moved off their existing MTA, we can take them a step further and configure specific behaviour based on "Tenant" - an arbitrary term used to define a user or message stream that is independent of IP or domain so it can have separate behaviour.
Why is this important? Let's say you are an ESP with two customers on the same shared IP pool. Customer A has a stellar reputation, and customer B is still working on building theirs. Tenant shaping allows you to add custom queue factors such as Maximum Age or Retry Interval to customer B by name instead of IP so you can protect the reputation of the shared pool while ramping a growing customer toward top performance. More importantly, you can reroute customer B exclusively by name to another pool if necessary.
This can be valuable for large brands as well. Perhaps you are a large retailer with message streams for Growth, Marketing, Notifications, and Administration. These may share one or more shared IP pools and may all have the same base domain. Tenant shaping allows you to make each stream a "tenant" with its own Retry Interval and Max Age parameters on the same IPs and Domains.
So how does this work? The tenant shaping factors actually form a separate queue. Consider the queue config for Gmail below. This creates a queue for Gmail-bound messages with a custom maximum age and retry interval.
[queue.'gmail.com']
max_age = '72 hours'
retry_interval = '20 mins'
We can create separate queues specific for tenant configurations as below. This inherits the settings from the Gmail queue but allows for overrides specific to this tenant.
[queue.'gmail.com'.'mytenant_alerts']
max_age = '12 hours'
retry_interval = '5 mins'
[queue.'gmail.com'.'growth_team']
max_age = '24 hours'
retry_interval = '30 mins'
[queue.'gmail.com'.'admin']
egress_pool = 'admin_pool'
This is just one more way KumoMTA gives you control over how an email is shaped for delivery. Tenant behaviours are controllable in the scheduled queue and a myriad of other shaping is available later on in the ready queue. These include connection rates and other throttles needed for effective delivery management.
Ready to discuss a move to KumoMTA? Let us know, or join the Discord here.