There are many reasons why SparkPost has become the world’s fastest-growing email delivery service. And we’re certainly proud of the technical and business benefits we deliver for developers and enterprises.

But we know you have options when you’re integrating email into your app or web site. In fact, the number and variety of choices sometimes can seem a little overwhelming. That’s why our team has put together a list of questions you should be asking us—or any email delivery service—to see which is the right fit for your business.

  • Does the service have a robust email API? This one should be a no-brainer, but you might surprised at how limiting some APIs can be, especially when they’ve been bolted onto an older platform. A modern technology stack should be built API-first, which is a key requirement for real-time, data-driven transactional email delivery.
  • Does it supply real-time data and analytics? Savvy senders understand that email metrics go way beyond “sent,” “opened,” and “clicked.” And in today’s world, an email service provider needs to supply that data in real-time. It should also give you access to detailed event history for each message, with the ability to access data via API. And if you’re really looking for data-driven insights, ask about the ability to stream activity with webhooks to as many webhook endpoints as you need.
  • Do they really understand email deliverability? A lot of ESPs consider an email “delivered” even if it ends up in a spam trap. The reality is that a provider with deep expertise, strong technology, and great relationships with global ISPs can help ensure as many emails as possible get to where they count— the inbox. A good email delivery service should be able to tell you their inbox placement rate, how they use technology to automate processing of deliverability signals from ISPs, and what they expect from you as a sender to ensure great email deliverability.
  • Is the service you’re considering a true cloud platform? Implementing an on-premises solution made sense a decade (or longer) ago, but it sure doesn’t today. And even a lot of service providers rely on a traditional data center model that’s become less viable every day. When you’re talking with prospective email delivery services, ask them directly about their platform. Are they built on a cloud native platform like Amazon Web Services (AWS)? Can they tell you about cloud auto-scaling and how it delivers radically better scalability, elasticity, and latency?
  • Does it incorporate security by design in every aspect of its platform? A strong perimeter defense should be a given (but ask anyway). Still, every wall can be breached somehow, somewhere. A modern cloud-based platform can defend the “squishy middle” inside its perimeter defense by incorporating security by design throughout its service, and when a provider compartmentalizes its service, it limits runaway vulnerabilities. Ask for certifications. And really do ask about that squishy middle.
  • Does it provide a meaningful service level agreement (SLA)? If email drives revenue for your business, you should ensure that your email delivery service has your back. That includes SLAs with teeth, burst rate guarantees, publicly available uptime history. Ask any service provider you’re considering to explain if they offer an SLA that covers just a narrow piece of their infrastructure—or if they cover the things that really matter, like end-to-end service and business continuity.
  • Does it offer the level of support you need? Whether you’re looking for great API docs and developer-friendly communities like Slack or dedicated account management by a team you know and trust, the right support can make all the difference to your success. So ask a prospective ESP whether they’ll give you support on your terms. And if a problem arises, will you know who you’re talking to, and will they understand your business?
  • Does it have happy customers? Don’t overlook intangibles like business growth. A track record of success backed by happy customers who are willing to publicly sing its praises is better than any marketing claim. And when you speak to references, be sure to ask what other email delivery services they’ve left in the past. You might notice a pattern that should tell you something.

I hope you’ve found these questions to be a helpful starting point when you’re looking at your options to integrate email delivery into your own app or business process. What do you look for when you’re evaluating options for email delivery? I’d love to hear what qualities matter to you—just leave a comment below.


P.S. Want to learn more? We’ve made a downloadable guide that builds on these questions to help you choose the right email delivery service. (Pro tip: it’s great for sharing with your colleagues.)


Big Rewards Blog Footer

data-driven email

If you’re reading this post, I’m pretty sure I don’t need to explain to you why email is an ideal channel for conducting commerce, marketing products and ideas, and more. In fact, I’m willing to bet that email is a fundamental part of how you do business. So, go ahead—send some of that mission-critical, data-driven email. I’ll just wait for you here.

Oh, wait. You mean, it’s more than simply pressing that big green “send” button? Syncing business data up with your ESP is, let’s say, complicated? Yeah, I hear you. You’ve kludged in some mechanisms to generate data files for account and CRM data, transaction data, shipment data, abandoned cart data, product data, loyalty data, and more. And as for getting that data into your ESP? Well, the integration between an ESP and your own internal systems typically involves tedious, brittle mechanisms such as FTP to upload all of that information.

On top of that, core email functions like message injection, reporting, unsubscribing, and templates aren’t programmatically accessible in real-time at most ESPs. That means manual updates and still more data duplication: sends, bounces, clicks, and more. So round-tripping data? Fuhgeddaboudit.

And, as for security around all that data, well… all we have to do is look at the news and see who’s been hacked this week. After working in the security business for 10 years, I’m enough of a realist to know that putting duplicate copies of your core customer data up on someone else’s servers doesn’t make the problem better.

Now, none of this is to say ESPs don’t care about your business or the integrity of your data. Of course they do, but their systems weren’t built for how we use data-driven email today. They were architected for delivering relatively static marketing messages, not for real-time transactions such as password resets, login notifications, triggered commerce flows, guided user onboarding, and more.

What if you took an API-centric approach to generating and delivering email, instead? Your business systems already are the system of record, so let them, not a redundant workflow at an ESP, handle the business logic. Your systems can identify which customer has triggered what action, and simply call a service (via a straightforward REST API, natch) to generate that specific email message right when it’s needed, not in a batched queue for offline processing.

By taking this direct send approach, no business logic needs to be built within the confines of your ESP, nor does the data need to be synced beforehand. That adds up to real-time delivery with a lot less hassle. And, by the way, since your email delivery service is now a triggered service, they no longer need access to all that sensitive business data or retain your customer’s personally identifying information (PII). That might lessen your security concerns, too.

None of this is automagical—you would need to build the right event- or state-based triggers into your business systems. But isn’t it better to have them in your own systems (where they can be reused for multiple purposes) then to build them out-of-phase at an ESP? These sorts of triggers are core to your business process flow. Treat them as such.

Today’s personalized, data-driven email is frankly far more complex than most ESPs were designed to handle. The hassles of synchronizing business logic and data for triggered sends at an ESP make that challenge clear.

So, maybe it’s time to take a step back and see if relying on your strategic business systems to handle the logic, and using API-driven approaches for personalized, triggered, and transactional email delivery is a better choice. Sure, for old school email marketing or soup-to-nuts campaign management, ESPs can give a lot of value. But for data-driven email, there’s a better way. Don’t let your ESP hold you back.


If you like this post, be sure to check out Getting to a Segment of One (Data-Driven Marketing Series, Part 1)

9 Things ISPs Really Want Email Marketers to Know

One of the important things I’ve learned in my nine years at Message Systems is that many of the people who work for ESPs and MSPs are very savvy technologists. We’ve been lucky to work with many of the smartest email industry veterans out there, and some have even come to work with us here. When I get a chance to chat with these technologists, I often ask them for a reality check: How much time did they spend in their previous companies developing technology that they now know Message Systems already has in place, and deploys with its core platform?

The answer is typically prefaced by the remark, “We thought Message Systems was too expensive and too complicated,” followed by: “Without the programmable policy engine included in the Momentum platform, everything else we did required development, which meant diverting precious resources away from our ESP core competency.” Indeed, without a programmable policy engine, activities like bounce/FBL processing need to be handled by routing messages to another application server, and it’s up to the operator to develop and maintain the processing systems. This typically means the operator has several developers dedicated to these external applications.

The Ongoing Value of Programmable Policy Engine

When it comes to managing deliverability, competing MTAs have, at best 20%, of the solution provided by Momentum’s Adaptive Delivery® modules.  Some solutions will stop traffic when certain temp fail messages are received, but have no concept of bounce or FBL rates. Without these capabilities, the operator is missing key indicators of potential trouble.  When an elevated FBL complaint rate eventually triggers a block from the receiver, the damage to the sender’s reputation is already done. The operator will spend excessive time and expense resolving the block.

While some solutions stop traffic based on temp fail messages, they do not restart traffic automatically. The operator must do this manually or develop yet another external application to manage traffic.  When you are managing traffic for hundreds or even thousands of senders, this kind of work can become a full-time job for one or more administrators. Message Systems, conversely, provides all the required logic developed by deliverability professionals based on the collective experience of our customer base. As such, our solutions free up resources in two areas: 1) cutting down on core application development, and 2) relieving deliverability specialists of many of the manual tasks required to maintain steady operation on commodity email servers. Taken together, these attributes within Momentum enable operations teams and deliverability teams to now focus on areas like message contentment, engagement strategies and sending best practices.

IP Warm-up is also very challenging: other solutions may provide a limit setting for traffic from a new IP. This single limit is enforced on each domain, and the setting must be adjusted manually for each IP address on a regular basis to ramp up volume. It’s up to the ESP to decide whether to develop yet another app to automate the process and then determine the ramp-up strategy.

Many of the technology decision-makers we work with in the ESP space look to pure performance metrics to guide buying decisions when it comes to messaging infrastructure. Yet simple performance tests are barely adequate to really drive understanding of what can be achieved using a messaging application server solution with programmable policy engine. Lower-priced MTA offerings might be able to provide performance approaching that of the most advanced commercial offerings like Momentum, but ongoing development and operational costs are where you’re going to see value from lower costs year over year into the future. And on that basis, a programmable policy engine is very valuable indeed.

About The Author: 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. 

In this whitepaper, email expert Len Shneyder introduces Message Systems Adaptive Delivery – The first solution of its kind specifically designed to automate the monitoring of bounces and complaints, and adjust connection rates and throughput accordingly. 

Adaptive Delivery Whitepaper