SparkPost today is synonymous with the concept of a cloud MTA. But you might not know how deep our expertise with MTAs runs. For more than a decade, the SparkPost team has been building the technology that powers some of the most demanding deployments of enterprise MTAs in the world. In fact, more than 25% of the world’s non-spam mail is sent using our MTAs every day.

Those are impressive figures to be sure. So when we say we’re proud  that SparkPost has become the world’s fastest-growing email delivery service, we know that one reason for the trust given to us is the credibility that comes from having installations of our Momentum and PowerMTA software deployed in the data centers of the largest Email Service Providers (ESPs) and other high-volume senders such as LinkedIn and Twitter.

As CTO of SparkPost, my team and I also have faced the sizable challenge—albeit a rewarding one—of migrating complex, highly optimized software like MTAs to a modern cloud architecture. Our team’s experience developing and managing high-performance email infrastructure has been a major part of why SparkPost has been successful with that transformation, but so too has been our vision of what a “cloud native” service really entails.

A few years ago, our team and many of our customers recognized that the cloud promised the ability to deliver the performance of our best-in-class messaging with dramatically improved economics and business flexibility. We understood that not only would it be more cost-effective for our customers to get started, but that it also would reduce the ongoing burden on their resources in areas like server maintenance, software maintenance, and deliverability analysis and resolution.

To get there, we knew we needed to do it the right way. Standing up servers in a data center wasn’t an option—because traditional data center models would limit our scalability, reliability, and operational flexibility in all the same ways our customers were trying to avoid!

That’s a big part of why we selected Amazon Web Services (AWS) to provide SparkPost’s underlying infrastructure. Platforms such as AWS, Microsoft Azure, Heroku, and others have many great qualities, but building a cloud-native messaging solution is conceptually a lot more than taking an MTA and installing it on a virtual machine in the sky.

There are times when architecting for the cloud necessarily embodies contradictory requirements. Just consider these architectural challenges of bringing something like an MTA into the cloud, for example:

  • Scaling Stateful Systems in the Cloud. One of the primary lures of deploying within a cloud provider is the ability to take advantage of push-button server deployments and auto-scaling. For the majority of AWS customers this is very straightforward; most of them deploy web-based applications of some form, following well established patterns for creating a stateful application using stateless web servers. A mail server, however, is inherently stateful; it implements a store-and-forward messaging protocol delivering to tens of thousands of unique endpoints. In practice some messages may need to be queued for extended periods of time (minutes/hours/days) during normal operation. Thus, like a database, it is significantly harder to handle scaling in the cloud, since typical load-driven scale-up/scale-down logic can’t be applied.
  • Limitless Limitations. Cloud infrastructure like AWS doesn’t magically change the laws of physics—even if it does make them a lot easier to manage. Still, every service has a limit, whether published or not. These limits not only affect what instance types you deploy on, but how you have to architect your solution to ensure that it scales in every direction. From published limits on how many IPs per instance you can allocate for sending, to unpublished DNS limitations, every AWS limit needs to be reviewed and planned for (and you have to be ready for the unexpected through monitoring and fault-tolerant architecture).
  • IP Reputation Management. A further complication both in general cloud email deployments, but especially in auto-scaling, is managing the dynamic allocation of sending resources without having to warm up new IPs. You need the ability to dynamically coordinate message routing across all your MTAs and to decouple the MTA processing a message from the IP assignment/management logic.
  • It Takes a Village. Moving to the cloud is not just a technology hurdle—it took the right people to make sure our customers were successful. We had to bring in expertise in engineering, security, operations, deliverability, and customer care to ensure the success of our customers in a scalable cloud-driven environment.

As I noted earlier, building and deploying a true cloud MTA is a lot more complex than putting our software up on a virtual server. But the end results show why services like SparkPost are so important to how businesses consume technology today.

I you’re a software engineer or architect building for the cloud, you understand how important solving complex technical and architectural challenges really are to achieve the promise of the cloud. I recently wrote a brief that shares some of what my team learned building a cloud-native email delivery service. I hope you find it helpful as you take your own journey into the cloud.

I’m interested in hearing about your experiences and what you’ve run into as you’ve developed for the cloud. Ping me on Twitter with your thoughts.

—George Schlossnagle

Businesses have more options than ever for choosing email sending infrastructure: from on-premises servers to full-service, hands-off marketing solutions—and everything in between.

What’s the best approach for managing high-volume email today? It’s tempting to say there’s one, easy answer for every scenario. While we at SparkPost are undeniably believers in the cloud, we also know that many companies have made significant investments in on-premises software over the years. Moreover, a particular company may have other business factors that preclude wholesale move away from their existing infrastructure.

whiteboardcloudThe truth is, we think SparkPost provides an ideal middle ground between in-house infrastructure and full-service marketing providers. We deliver both the scalability and operational expertise of a dedicated cloud provider with the API-driven control and extensibility of specialized software products like Momentum and PowerMTA. In fact, it’s this combination of qualities that makes SparkPost an ideal candidate for deploying a hybrid approach to email infrastructure: one that combines the best of the cloud with the existing footprint of on-premises investments.

Here are five scenarios where this hybrid approach makes a lot of sense.

1. Creating options for diverse mail streams. A big benefit of a hybrid email infrastructure is flexibility. Some types of mail are easily segregated to the cloud, while others might be tightly coupled to other in-house systems. For example, marketing messages to well-defined customer segments might be easily migrated to cloud-based sending, while transactional mail, like password resets or shipping confirmations might be generated by in-house systems that offer limited external integration options. A hybrid approach allows you to pick and choose the best solution for each mail stream your company might have—and gives you some runway room to extricate transactional message generation from legacy systems over time. (By the way, segregating different types of mail streams into dedicated address spaces also is a best practice that leads to better deliverability.)

2. Offloading deliverability headaches to the experts. Managing the inbox performance of email programs is no easy task. There are countless factors that shape inbox performance, and these rules are constantly changing as ISPs fight against spammers and other bad actors. SparkPost’s deliverability team is the industry’s best—and their expertise gets results, whether a message is generated completely in our system or relayed from an on-premises server configured to work with our cloud. That deliverability improvement is a quick win for anyone deploying a hybrid cloud approach. Outsourcing your sending also means offloading the headaches of maintaining and managing your own IP reputation, along with the costs associated with monitoring it. Better inbox performance, lower costs, fewer headaches? Win, win, win!

3. Scaling sending capacity for seasonal or other peak demand. In many businesses, message volume can be very unpredictable and bursty. In others, there may be a seasonal peak demand much higher than other periods of sending. For example, a major product launch could spike email volume for a limited period. Or, a retailer might send 100x its usual volume during the Black Friday holiday shopping weekend. Scaling on-premises infrastructure to handle these peak loads is a waste of capital investment that would normally sit idle, but a hybrid architecture allows you to use the elasticity of the cloud to absorb these peak demands, whenever they might occur, while optimizing capital spend.

4. Mitigating risk while maximizing control and compliance. In many regards, a cloud infrastructure provides an inherent advantage for risk mitigation through the redundancy and disaster recovery benefits intrinsic to large-scale virtualization. A hybrid sending architecture builds on this by adding the possibility of switching sending from one environment to the other, should one fail for any reason. At the same time, while SparkPost adheres to stringent security best practices and offers a variety of mechanisms for ensuring the security and authenticity of data transmitted to the cloud, we know some customer systems require particular regulatory controls, need to live off the grid on a private network, or may require zero latency or other quality-of-service factors harder to control over a public network. In these cases, connecting an on-premises email infrastructure to the sensitive systems, while relaying message delivery though the cloud allows for optimum risk management and control.

5. Getting your feet wet and enabling incremental change. The final reason to consider a hybrid of on-premises and cloud email infrastructure is deceptively simple. Because SparkPost is built to scale from small message streams to the very highest volumes of traffic, it provides an ideal route for getting real-world experience with the performance of cloud-based email delivery, one message stream at a time. This incremental approach is a hidden benefit of the SparkPost service. A step-by-step migration to the cloud is the antithesis of wrenching “rip-and-replace” changes, and it provides a path for the gradual, well-managed sunsetting of on-premises infrastructure.

These are just five of the reasons for considering a hybrid cloud/on-premises email infrastructure, but they all share one trait: flexibility. Whether it’s adding cloud sending capacity, controlling capital costs, or boosting deliverability, a hybrid cloud enables as many deployment options as there are email programs.

That flexibility is one of the traits that makes SparkPost so compelling: our industry-leading deliverability, performance, and real-time reporting don’t come at an all-or-nothing price, and they don’t require the risks of rip-and-replace deployments. (And, by the way, configuring PowerMTA to relay to SparkPost is really easy.)

Update: Want to learn more? We are hosting an upcoming webinar about the benefits and approaches to deploying SparkPost in combination with your existing on-premises infrastructure. Join us on December 9 at 10 AM Pacific Time for “Hybrid Email 101: How to Add Cloud Services to Your On-Premises Infrastructure.” Register today!




Shared vs Dedicated Email Environments: A Practical Guide

Imagine for a moment that you were sitting in a meeting listening to a post-mortem on a delivery incident. Your team was busy chewing through a litany of issues from mail injection failures to unknown bounce codes and throttling issues that resulted in a simple fact: your emails didn’t reach your customers. Thoughts race through your mind:

‘I should fire everyone!’

‘Maybe it’s time to get an ESP?!’

‘My grandmother could tune those MTAs faster!’

‘Open source = open heart surgery with obsidian knives and no anesthetic…’

‘Calgon take me away.’

And then it hits you like a ton of bricks: maybe its time for a new MTA. Yeah, that’s the ticket, it’s time to switch our entire mailing infrastructure, the one we’ve been working on for 2-3 years that looks like the kind of Jackson Pollack art left on a wall when you throw a plate of spaghetti marinara in anger.

Excitedly you stand up and announce that you’ve come up with a solution to the ongoing deliverability problems facing your company: “Team, it’s time we scrap our current MTA and switch to a more sophisticated platform purpose built for high volume sending and deliverability!”

A tense moment passes; sweat begins to trickle down your forehead. The lights dim and your colleagues shed their innocence—they’re no longer your colleagues—you’re staring at a frightened and crazed mob!

However far fetched this fictionalized account of an MTA swap might sound it isn’t too far from the truth either. Switching an MTA can inspire, in the best case, heated debate; worse case scenarios might be closer to what happened to poor Caesar in the senate. In truth, an MTA swap can be just the antidote your organization needs in a time of crisis.

Short Term Pain For Long Term Gain

Overcoming organizational challenges to MTA swapping varies depending on how your mailing infrastructure has evolved, and the kind of footprint it now has.

The Open Source Frankenstein

It started with a couple engineers and a Gnu license but has since taken on a life of its own. It no longer resembles the original product, or is used for whatever it was originally meant to do. Lots of code went hand in hand with lots of cooks and engineers that have since flown the coop. You spend upwards of $500,000 a year in customizing it, maintaining it and throwing more hardware at it when you need more capacity. It is, for all intents and purposes, a Frankenstein—a monster built from scraps and salvaged parts and kept alive by a supernatural force that comes straight out of your wallet. And, like the 19th century creature’s namesake, it’s about as efficient as a delivery engine as a horseless carriage.

The Fuselage Without Wings

Five years ago someone knew someone that knew someone and that someone said you should buy this thing that would change your email into something awesome. So you spent the money on a second rate MTA—you’re a hero because you saved the company money! Then it arrives. You get the box, read the manual and realize that this spruce goose comes without wings. So you rope in your Director of Engineering; he’s not thrilled that you pulled him into this IT project because he’s busy ensuring your product actually makes money. Your cost savings just went down the toilet and your Director of Engineer is now breathing down your throat like Attila the Hun. Congratulations, you’re building the wings for your plane and wondering if it wasn’t more cost effective to go DIY all together. I mean if you’re going to inspire the ire of your director, you might as well save more money to pay for the resource suck you’ve just created.

The ESP and Me

Your ESP sends your email—you’re happy with them so long as the mail arrives on time. But, like all vendors they need to make money, and since the CPM market is all but stabilized and the best you can do is save a quarter cent per million by changing vendors, they charge you for account management, deliverability, data exports and more. It’s a nickel and dime fiesta and you’re the only one not dancing. Since it’s 2014 and not 1999 you feel your data should be accessible anytime, anywhere and as soon as an event, like an open, occurs. Unfortunately the best your ESP can do is give you a nightly export or a data dump every four hours as their system parses through your data and the hundreds of other customers they service. Your business is definitely valued, don’t forget that, it’s just not as valuable as the customer that pays them a half million a year and has a four-hour SLA and five account managers at their disposal.

In all of these scenarios, the real costs are not the pain and suffering, the man-hours and resources required to make the switch. No, the costs and the pain are rooted in correcting a terrible mistake that has cost you (and will continue to cost you) real dollars and countless man-hours. Switching an MTA isn’t just about acquiring the ability to send email based on modern sending standards, security and having access to data in real time. It’s about coming to terms with the idea that good enough isn’t good enough and won’t be good enough two or three years from now when you’re so far behind the times, the cost to change will be soul crushing.

That’s right, the pain you suffer today, or think you will suffer by switching to a future-proof email platform, is nothing compared to the fire drills you will avoid because your platform isn’t ready to evolve with the market. Email hasn’t changed all that much, but the technology to secure the channel, authenticate and analyze the medium’s efficacy has evolved beyond anything its creators’ envisioned when they sent those first emails 30+ years ago.

Email is part of a robust and complicated ecosystem of outbound communication channels and feedback loops that fast track data into repositories for crunching and analysis against other customer metrics for distillation into new campaigns and communications. Email is more than just email—email is the outward manifestation that you’re a company capable of doing business in a manner that has been accepted as the gold standard on the Internet. What’s that worth to you?

Looking to make a switch? Find out what questions you should be asking to make the right decision in Finding the Ideal Email Solution Provider.


By Kim Matz & Kate Nowrouzi

Message Systems’ Adaptive Delivery® solves the ongoing deliverability management issues faced by Email Service Providers (ESP) today.

It’s the only solution that monitors temporary failure codes, hard bounces and spam complaint rates, and automatically manages your traffic flow. Adaptive Delivery slows traffic when a receiving domain returns warning messages or bounce and complaint rates rise.  When warning indicators lower, Adaptive Delivery slowly and automatically raises traffic rates.  Over time, Adaptive Delivery builds the traffic volume the receiver is willing to accept.  Momentum ensures issues with one domain do not impact the rest of the traffic by managing traffic to each receiving domain independently via the most sophisticated and comprehensive queue management and traffic shaping capabilities that are core to our solution.

Here’s an example of an alert generated by Adaptive Delivery:

The alert pertains to:
Host: MTA1-marketing
Trigger: 421 4.7.0 [TS01] Messages from temporarily deferred  –;
Action: adjusting throttle down

The system provides SMTP notifications to staff members when conditions are met that warrant human involvement. Not every bounce or deferral requires immediate attention – understanding the difference between normal delays and critical blocks is key to off-loading manual monitoring duties from already overloaded staff… only Adaptive Delivery can do this.

Without Adaptive Delivery, ESPs leave money on the table and their very valuable deliverability team spends time on reactive tasks like:

  • Updating bounce definitions;
  • Monitoring hard & soft bounces;
  • Monitoring Feedback Loops for complaint spikes;
  • Adjusting throughput, connection rates and throttling to comply with ISP requirements; or,
  • Creating and executing ramp up/warm up plans to build positive reputation on new IPs.

Only Message Systems’ Adaptive Delivery allows them to focus on strategic projects that drive serious revenue.

Watch the video below to see how some of our clients have benefited from using Adaptive Delivery.

About The Authors:

Kim Matz is VP of enterprise sales, US East at Message Systems. An experienced technology industry executive, Kim heads up Message Systems’ email services provider practice, working with many of the largest ESPs in North America. Kim writes frequently on issues and trends in the ESP space. 

Kate is director of Product Policy at Message Systems. A recognized authority on email deliverability and anti-spam practices for the past 14 years, Kate worked for many years on the anti-abuse team at AOL and was also a network engineer at the pioneering ISP UUNet/ Verizon Communications (credit proulx). Kate is a member of M3AAWG and OTA and continues to be an active voice in the worldwide messaging community. 

Want to find out more about what Adaptive Delivery can do for your business? Download our free white paper on Improving Delivery & Reducing Costs Through Automation!

Adaptive Delivery Whitepaper