Momentum and PowerMTA have been the two fastest, most effective on-premises MTA solutions in the industry for the past two decades. In 2014, we introduced the SparkPost Cloud delivery engine to that suite and made the power of those high volume on-premises MTAs available to the SaaS Cloud market. Empowering our customers to build on a cloud solution backed by the world’s fastest on-premises solutions was a revolution in the industry, but it also introduced a rarely discussed side benefit which is the ability to leverage our platforms as a hybrid.

When we talk to our customers about hybrid solutions, that really can take three different forms and we will discuss those in detail below. In general, what we mean is that you can deploy one of our on-premises solutions (Momentum or PowerMTA) to your own data centers and also use the SparkPost Cloud SaaS solution together in some fashion.

Diversifying Mail Streams

The SparkPost cloud can operate as an extension to your existing on-premises deployment.  In many cases, you can take advantage of the fact that we have a highly scalable infrastructure or specialty services that are not available in your own data center. For instance, we have a proven ability to deliver effectively into China, one of the most difficult delivery regions in the world. Routing your China-bound traffic through SparkPost could be the solution you are looking for while keeping your domestic traffic in your local data center. Another use case is to separate your time-sensitive notification messages off to SparkPost for delivery while your less time-sensitive messaging is still delivered from your data center.

To make this work, your on-premises configuration should use SparkPost as a “smart host” for specific mail streams. In Momentum you can use a gateway configuration in a binding stanza. In PowerMTA you can use a queue-to directive in a domain stanza.

In either case, only select message streams are relayed to SparkPost for onward delivery.

Maximizing Deliverability

Another use case is to use Momentum or PowerMTA to do all the pre-conditioning, and customization of the message in your data center, then forward ALL the mail to SparkPost for onward delivery.  This can help you reduce your data center footprint and Enterprise customers can take advantage of Technical Account Managers, Deliverability Professionals, and our highly scalable infrastructure to ensure onward delivery of the message.

The easiest way to do this is to add a global configuration that forwards all mail to SparkPost for delivery.  You can do that in Momentum with a Gateway command and adding the required API Key and TLS security as shown below.  Making the change in PowerMTA is similarly simple.

Disaster Recovery

SparkPost’s distributed architecture can be accessed via API or SMTP. In the event of a disaster, it can serve as a hot-standby or failover to ensure business continuity.  In order to make this work effectively, you will want to split your traffic so that a reasonable amount of volume is shared across both platforms. Ideally, this is configured as a hot-hot solution so there is no concern about IP warmup.

If you follow the instructions below to configure the systems, You can select specific mail streams, or portions of them to route through one or the other platform.  You can then trigger the failover in a number of different ways depending on your injection processes. For instance, active load balancing with an external device can route messages only to the systems that are responding. If the hardware data center fails, all traffic natively routes to SparkPost and vice versa.  

You may also want to control that programmatically for times when you want to perform data center maintenance and route all messages through SparkPost during that downtime.

The Nitty Gritty Details

Momentum Configuration

SparkPost requires SMTP injection using TLS and SMTP_Auth.  Momentum has the ability to do both with configuration. You can route all traffic with a static GATEWAY directive or you can route programmatically with Lua.

Configure a binding stanza with a GATEWAY pointing to SparkPost.  Aside from making SparkPost a smarthost, you can also set the TLS configuration here.

Binding PushToSparkPost {
  Gateway = "smtp.sparkpostmail.com"
    TLS = "required"
    TLS_Certificate = "/etc/pki/tls/certs/trymsys.net.crt"
    TLS_Key = "/etc/pki/tls/certs/trymsys.net.key"
    TLS_Ciphers = "DEFAULT"

Configure a domain stanza with the target port (587 or 2525) and the required SMTP_Auth information.  You can copy and paste all of this and just replace the SMTP_AUTH_pass value with the API key from your own SparkPost account.

 Domain "smtp.sparkpostmail.com" {
  Remote_SMTP_Port = "587"
  Outbound_SMTP_AUTH_Type = "LOGIN"
  Outbound_SMTP_AUTH_user = "SMTP_Injection"
  Outbound_SMTP_AUTH_pass = "13d5a82redacted6f16redacted4ca"

In Lua, you can use an X-Header to route to the binding above and the rest is automatic.

local bindingname = msg:header("X-Binding")
local err = msg:binding(bindingname[1]);

Now when you inject a message to Momentum with X-Binding: PushToSparkPost, the message will automatically be routed to SparkPost for onward delivery to the recipient.

That is all that’s needed to make a static route.

 You can optionally let Lua selectively route based on the sending domain or target domain or other factors.  In the sample below, I assign different bindings based on the recipient domain. If the recipient is at a Yahoo address, it will deliver with SparkPost, otherwise, it will deliver with Momentum.

-[[ Sample to selectively route to SparkPost Cloud ]]--

local mod = {};
--[[ Modify these as necessary ]]--
local sproutedomains = { "yahoo.com", "yahoo.co.uk" }
--[[ Set Binding function ]]--
function mod:validate_set_binding(msg)
  local domain_str = msys.core.string_new();
  local localpart_str = msys.core.string_new();
  msg:get_evelope2(msys.core.EC_MSG_ENV_TO, localpart_str, domain_str);
  local mydomain = tostring(domain_str);
  local mylocalpart = tostring(localpart_str);
  local validdomain = "false"
  local bindingname = msg:header("X-Binding")
-- Test to see if the TO domain is in the routing list
  for i,v in ipairs(sproutedomains) do
    if v == mydomain then
    --  print ("Routing to a valid domain: " .. mydomain);
      validdomain = "true"
 This conditional assumes you have bindings configured so that 
 a binding named something_sp will route messages to SparkPost for delivery and a binding named something will route messages via Momentum for delivery
  if (( bindingname[1] ~= "" ) and (bindingname[1] ~= nil ))  then
    if validdomain == "true" then
     -- Append "_sp" to the name
      local err  msg:binding(bindingname[1] .. "_sp");     else
      local err = msg:binding(bindingname[1]);
    local err = msg:binding("catch-all");
  return msys.core.VALIDATE_CONT;

msys.registerModule("policy", mod);

PowerMTA Configuration

If you are using the PowerMTA platform, you can configure it in a similar way.  Though TLS is not absolutely required, SparkPost does recommend using TLS with SMTP_Auth, so you should make those configuration changes as described in the PMTA User Guide in section 10.4.3 Implementation for Outbound Connections. There is also a more comprehensive description in this knowledgebase article: https://staging.sparkpost.com/docs/integrations/power-mta/

First, you need to configure a domain directive to specifically use SMTP_Auth with TLS.  As with the Momentum configuration above, the password is the API key from your SparkPost account.

<domain sparkpost.rollup>
 use-unencrypted-plain-auth yes
 auth-username SMTP_Injection
 auth-password xxxYourSparkPostAPIKeyGoesHerexxx
 route smtp.sparkpostmail.com:587
 use-starttls yes
 require-starttls yes
 max-smtp-out 10

Now you can route ALL mail to SparkPost with a wildcard domain directive

<virtual-mta SparkPostRelay>
  <domain *>
    queue-to sparkpost.rollup

Or you can selectively route mail streams using a pattern-list directive

<pattern-list domainsRelayedToSparkPost>
    mail-from /@email.mydomain.com/ virtual-mta=SparkPostRelay

Bringing it all together

Being able to leverage both SaaS Cloud and On-Premises software in a coordinated Hybrid approach gives you the most flexibility and highest resiliency.  If you want to know more about enabling a hybrid in your environment, let us know.

~ Tom