Delivery Metrics: Why Measuring Email Delivery is so Important

Recently, I described how to measure the latency of email notifications, a key metric for measuring how effectively an app can generate and send notifications and similar messages.

In today’s post, I will look at the next stage of an email notification’s journey: delivery. Email delivery sounds like a simple matter, but ensuring your app’s emails actually reach your users’ inboxes is surprisingly complicated. Understanding how to measure email delivery is an important part of measuring the overall effectiveness of your emails for driving user engagement with your app.

Key numbers to analyze at this stage include:

  • Acceptance rate
  • Number (and types) of failures
  • Inbox rate

Acceptance Rate

After your message is submitted, it is queued by the sending MTA and then the sending MTA will attempt to deliver the message to the receiving MTA. Typically this next hop will be to the edge of the ISP’s network (for example, from your MTA to an MTA server at the edge of Gmail’s network). The remote server may accept the message, but first it will run a series of checks; looking to see whether your server is on a blacklist, whether the recipient’s email address is valid and active, and even some initial content filtering.

If all of these tests pass, your message will be accepted by the remote MTA, and the local MTA will record that the message was accepted. Not all mail will be accepted, and there are a number of reasons why remote MTAs reject messages (which will be covered below), but the key metric at this stage in the life of the message is the accept rate.

When senders talk about their deliverability, they are usually referring to their accept rate: the percentage of the email message they submitted that was ultimately accepted by the remote MTA. On average, 72% of all email messages are not delivered, so having a high accept rate is critical to the success of your application. Non-delivery of your messages leads to user dissatisfaction, slowed or blocked user onboarding, support costs, and churn.

Temporary Failures (Soft Bounces)

Messages are not always accepted (or rejected) by the remote MTA on the first attempt. The remote MTA can respond with a temporary failure (commonly known as a soft bounce) for a number of reasons, causing the sending MTA to re-queue the message and wait before attempting another delivery. A temporary failure indicates something is wrong with the mail systems, but not the recipient address.

The original reason for temporary failures is still a common one: the remote MTA gets overwhelmed and issues temporary failures to incoming messages in order to catch up with incoming traffic. This is not unusual and does not require any further intervention on your part, the sending MTA will wait and retry.

Remote MTAs can also send temporary failure responses while they are being shut down, reconfigured, and for other technical reasons, and the same response applies: the sending MTA needs to wait and try again later.

Delays caused by temporary failures can also be a result of your sending reputation. When a remote MTA doesn’t consider your sending reputation to be trustworthy, it can greylist your messages so that it can see whether your sending MTA will follow best practices and try again. In addition, some ISPs will enforce rate limits on sending MTAs based on how reputable they consider your sending to be: when you exceed the hourly limit, they will then start responding with temporary failure messages for the remainder of the hour.

While the right course of action for the sending MTA is to wait and try again, senders need to pay attention to reputation-based temporary failures and review their sending practices and take steps to improve their sending reputation. Note that sometimes you can get this response on only part of your email traffic to a give ISP, in this case they will likely be letting through a small sample of your messages to see how their users respond, and then make a decision on the remainder of your messages later.

Permanent Failures (Hard Bounces)

The third potential response a remote MTA can issue is a permanent failure (also called hard bounce). Remote MTAs issue permanent failures to tell the sending MTA to cease attempting to deliver a message.

The most common permanent failure reason is an invalid recipient address. This can happen for a number of reasons: a new user may typo their email address, an established user may shut down their email account in favor of a new one, a malicious third-party may enter an invalid email address into your signup forms to trigger excess hard bounces (this one can be common when an organization has rivals, such as a political party). The ISPs are generally tolerant of these bounces, but they will be watching to see whether your application pays attention and prevents future sends to addresses identified as being invalid. It’s key that your applications process these bounces and stop sending to the recipients as soon as possible (if your sending platform supports webhooks for bounce data, this is a good use for them).

Some permanent failures, such as the invalid recipient bounce mentioned above, are signals that you should not attempt sending to a given recipient again. Other permanent failures can indicate that while the current message should no longer be attempted, future messages may have a different outcome.

One common permanent failure response is a spam block. These can be related to either the source or the content of the message you send, and either type needs to be investigated and acted on promptly. If you get a surge in message related spam blocks, you need to review what you are sending, if you get a source related spam block, you need to review your content and your sending practices.

Additionally, hard bounces can occur for reasons such as the recipient’s mailbox being full, the message containing an attachment that the ISP considers too large, and for other reasons that may or may not support future attempts at sending. The key is to categorize your hard bounce responses and act on a granular basis, removing bad addresses, reviewing spam blocks, adjusting attachment sizes, and pausing sends to users with full mailboxes.

Inbox Rate

Message acceptance (or failure) is not the end of your message’s journey. Once the MTA at the ISPs has accepted the message from the sending MTA, it will often run additional checks, perhaps perform deeper scanning, or even store the messages temporarily while it monitors how a subset of recipients react to your message before releasing the remainder of your messages, or putting them in the spam folder.

All of this means that you need to look further than the accept rate to see whether your messages have successfully reached your user. The ISPs do not provide data on whether messages reach the inbox, the spam folder, or are dropped after delivery, so there is no definitive way to know whether each of your messages was successfully delivered.

Instead, senders can use sampling to determine how many of their messages reached the inbox at the various ISPs. Like measuring real latency, the only way to get an accurate inbox rate is to look at the inbox itself. Some senders will configure mailboxes at the major ISPs they are interested in to see whether test messages deliver regularly, but many will take advantage of a third-party provider such as 250ok and their large networks of monitored mailboxes.

While it’s impossible to get a precise number for your inbox rate, you can use the data from sampling for trending information. If you see dips in your inbox rate over time, you need to review what you’re sending and who you’re sending it to in order to identify any poor sending practices you may have recently adopted.

Up Next: Opens, Clicks, and User Engagement

Message delivery and inbox placement is a crucial part of any product’s email performance. But what comes next might be even more important: did your users actually take action on the email you sent? Stay tuned for our final installment: understanding how to measure user engagement with notifications and other product emails.


debunking email security myths

If you’ve followed technology industry trends for the past several years, you know that all manner of business and consumer technologies have been moving from stand-alone, on-premises systems into the cloud. In fact, we’ve reached the point where we no longer speak of the cloud as the future of software—it’s the present.

For most of us considering developing a new system, there’s really very little debate about whether or not it should be built in the cloud. The answer is a clear yes. But not all of us have the luxury of a greenfield implementation—and as with past shifts in system architecture, how best to deal with legacy systems is a question that requires careful thought.

Shifting marketing and transactional email from on-premises systems to a cloud-based email delivery service is one example of this challenge. Let me try to debunk some of the myths surrounding email security when moving your email from on-premises to the cloud.

Myth: Cloud email services are less secure than using on-premises software.

Email services are neither inherently more or less secure in the cloud. The truth is, email security has much more to do with configuration and practice than with system architecture. And on those fronts, the cloud actually offers some security benefits.

First, the security perimeter is smaller and more defined than in a corporate setting. Second, the user base is easier to move and administrate in a cloud setting, and access is more robust and easy to maintain for users and administrators. Finally, the cloud affords security administrators benefits like:

  • Centralized attachment scanning and blocking
  • Unified storage and lower cost administration and access controls
  • Ease of auditing and monitoring

To my mind, helping security administrators do their job more easily and effectively is the surest route to an overall improved security stance.

Myth: I will lose control over my data by moving my email service to the cloud.

This is an easy myth to debunk. In SparkPost’s cloud infrastructure, email and associated data are still controlled by the customer. Data management remains with the customer regardless of the hosting environment.

Myth: Anyone can access my data in the cloud. Plus, if it happened to Yahoo, couldn’t it happen to me?

A good cloud infrastructure (including Amazon Web Services, the cloud infrastructure used by SparkPost) has a lot of security baked-in and tested in ways few vendors can match. However, there’s no magic bullet here. Odds are that breaches can and will happen to everyone at some point, whether on-premises or in the cloud. Defense is expensive and hard. Even with the best defense, there is always an opportunity to be compromised. The key to success is to practice good data management, backup, and security. So encrypt your volumes, use multi-factor authentication—and most of all, enforce strong standards and procedures. Educate your user base to look for anything unusual and stay alert to the current attack trends. As with so many routines, complacency kills. Stay alert!

Myth: There are no steps I can take to make my cloud infrastructure secure.

Technology is good, however, it’s only as good the processes and controls that enforce it. By that, I mean putting policies and standards in place to enforce strong authentication and data security protocols. Use Multi-Factor Authentication (MFA), VPN, and other protections to control access to the production instances and email services. Drive your user base to use multi-factor authentication and connection protocols requiring multiple steps to access data. Encrypt your data at rest and in motion. (If you look at data breaches historically, the most destructive have been those that gained access to data that wasn’t encrypted. Never assume your fortified perimeters will save you.) Audit your user base and ensure only the right population has access and appropriate user rights. Enforce attachment scanning. Enforce perfect forward secrecy protocols. Are you seeing the pattern here?

Don’t take shortcuts, even though every developer and every user wishes you would for their convenience. Those extra steps, as tedious as they sometime seem, are the keys to keeping your instance secure.

Myth: I’m not sure I’m ready to move all of my data at once and it seems that it’s all cloud-or-nothing.

No, there’s nothing that says cloud use cases have to be all-or-nothing. It’s really a question that depends upon the needs of your particular business and velocity. You will have to determine the best course of action for your business case. For highly sensitive data, an incremental migration or hybrid cloud setup may be the way to go until there is enough trust in the new solution to fully commit. In other instances, you may want to rip the band-aid off and move it all at once, because the benefits of the cloud outweigh the risks. Regardless, ensure you have a good working backup solution during the migration and a solid continuity plan before you move any data.

Myth: It will take a long time to realize the benefits of moving to the cloud.

This is something I could talk about for hours. There’s so much good for both the business and for the technology team. But really it comes down to this: the cost/benefit of email in the cloud seems simple, but the truth is it’s even better than you think. The cloud really has upended the economics of software development and enabled genuine business innovation. Flexibility, scalability, shifting costs from capital to operational expenditures—these are all benefits that business execs love. Technology teams get to offload the operation of infrastructure to service providers who can do it more reliably, with better deliverability, and operate it at lower cost. It frees internal development teams to focus on unique functionality and business differentiators. It’s one of the clearest examples of win-win I’ve seen in my career in tech.

Myth: I won’t save much money by moving to the cloud

Between the costs of hardware, physical plant, and operational staff, operating your own on-premises infrastructure is a significant drag on business flexibility and budgets. SparkPost surveyed several real-world businesses and crunched the numbers. Afterward, we found that moving email delivery infrastructure to the cloud is a strategic win for companies that send high volumes of commercial and transactional email. In fact, a business that sends 750 million emails a year can save up to 40% by migrating email infrastructure to the cloud.

What is the onboarding process like if I choose to move my email service to SparkPost?

At SparkPost, onboarding involves several interactive tools and resources to ensure a successful start for all of our users. For our enterprise customers, the experience also includes the expert support of our Technical Account Managers (TAMs). In fact, the “white glove service” our TAMs deliver is one of the things I’ve consistently heard from our larger customers has helped them to succeed. They help senders lay the groundwork for the highest performance, make sure implementation is successful, help with the go-live transition, and then provide proactive ongoing support. It’s a real differentiator from other email delivery services.

Prime Sending Times: Prime numbers floating from clock to envelope

Determining Prime Sending Times with Prime Numbers

You may remember learning about prime numbers in middle or high school math class. These of course, are numbers that only divide by themselves or one. You may also remember thinking, “I’ll never need to know these”. However, I’m here to tell you that they can be useful to you in ways that might improve your email delivery.

Recently, I was helping one of our clients deal with a problem where most, but not all, of their batch send to a large mailbox provider was getting through on the first try. The rest was getting through eventually (within minutes), but the client really wanted it all sent on the first run. We have a contact at the mailbox provider, so I reached out to him to see about a solution. Over the course of the conversation, he said something that stuck with me:

“Our inbound traffic volume at 8:03 is ten times what it is at 8:43.”

The reason for this, is that there are lots of bulk senders who have regularly scheduled sends during the day. Of those sends, nearly all of them kick off at the top of the hour. Mailbox providers, especially large ones, have the capacity to deal with large spikes in traffic. However, even the largest providers have finite resources, and if everyone and their brother makes demands on them at the same time, some messages are going to have to wait.

This Is Where Prime Numbers Come In

Unless you absolutely have to send your mail at the same time as everyone else, you might find that your delivery times are improved if you pick a time for your regular sends that is not right on the hour, quarter hour, or half hour. Instead, pick a number from the list below (all prime numbers) as the time past the hour for your send, and see if your delivery doesn’t improve a bit:

1, 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59

With the exception of 5, most of these numbers are probably not ones that people would use for scheduling purposes. We’re most likely to use the numbers we remember from the clock face, rather than all the ones in between. It’s likely that if you send your regular mailing at, oh, 8:23 instead of 8:00, you may find that you’ve got more capacity available to you at the destination domains. As a result, your queues may clear much faster. Happy Sending!


ps: Any additional thoughts about prime sending times? We want to hear – comment below or Tweet us!

now sending 15 billion emails

Let me begin by saying that this is the sort of blog post a CEO loves to write.

When SparkPost launched 18 months ago, we knew developers were looking for a better way to send email from their web and mobile apps. We knew enterprise senders needed more reliable delivery for email that was critical to their business. And we had a clear vision for how to meet those needs, with a next-generation cloud architecture backed by a team that understood email better than just about anyone else on the planet.

But even so, we knew that there was one thing that was going to be absolutely essential to our hoped-for success: you. We were optimistic, of course, that the market would recognize the value of what we were building. But the growth we’ve experienced in the last year and a half has exceeded our expectations.

We’re now delivering more than 15 billion messages each month, and that figure is growing by more than 1 billion per month. To put it simply, SparkPost is the fastest-growing email delivery service on the market.

That growth is because of you. We’ve just been thrilled that so many developers and enterprise customers alike understand the benefit of what SparkPost has brought to the table—and to see the sorts of innovative things our customers are doing with email today. SparkPost’s 15,000+ active customers range from small startups to fast-growing major technology companies including Pinterest, Zillow, CareerBuilder, LinkedIn, and Intercom.

Beyond the numbers, I’d like to highlight three areas that reflect SparkPost’s leadership and growth:

  • SparkPost is now the preferred choice of developers for API-driven email delivery. This was evidenced by the recent migration of many Mandrill users to SparkPost after MailChimp announced it would no longer be available as a standalone service. The resulting surge of users to SparkPost was captured in a recent Notablist report analyzing the Mandrill market disruption; this analysis found that over 21 percent selected SparkPost—5 percent ahead of the closest competitor—prompting Notablist to state that “SparkPost Won the Battle for New Users.”
  • SparkPost has earned our reputation as the most reliable and flexible email delivery service provider. Unlike other email delivery providers who continue to expend resources and focus on building and maintaining  their own data centers, SparkPost is the only full-featured cloud email delivery service built 100 percent for the modern cloud.  SparkPost’s leverage of Amazon Web Services, the industry’s preeminent Infrastructure-as-a-Service (IaaS) platform, allows customers and partners alike to experience the benefits of a secure, scalable, and elastic cloud infrastructure—like guaranteed burst rates—while allowing SparkPost to remain focused on developing and expanding its core service offerings and technical innovations.
  • SparkPost is focused on email delivery—and we love our MarTech partners. We’ve developed more than 30 strategic partnerships with innovative marketing technology (MarTech) companies. These marketing application providers give SparkPost customers the combined benefit of leading-edge MarTech functionality with the high-performing email delivery service that is SparkPost’s clear focus.

2016 has proven to be a year of remarkable growth for SparkPost. And I fully expect the next 18 months will be even better.

So, a heart-felt thank you. I can’t wait to see what we build and grow together.

—Phillip Merrick

300x250_EngagementEmail is every business’s bread and butter, whether they realize it or not. But for companies that aren’t that familiar with engagement and revenue costs of some of the low-performing email sending options out there on the market today, the benefits of upgrading to a new email delivery service may not be immediately apparent.

You may have seen in the press that we announced that SparkPost is out of beta and generally available to the public, but readers who aren’t already Message Systems customers and familiar with the engagement and performance benefits of sending on Momentum platform may be asking themselves: “Why SparkPost? And why should I upgrade now?”

Why SparkPost?

To start, SparkPost now offers our customers all the benefits of the Momentum platorm without requiring users to install and manage their own email systems. It is available in a self-service, pay-as-you-go version at that offers quick API integration so you can be up and sending enterprise-grade email communications in no time.

For companies who are already sending significant email volumes, SparkPost Elite provides a dedicated platform instance with guaranteed high burst rates and a dedicated account manager who provides reviews and advice for improvements. In addition to 24×7 monitoring of your email service, we’ll manage the initial set-up and configure the service to meet your needs so there is no delay in getting you up and sending quickly.

Why now?

Putting off upgrading to the right email delivery service can be costly to your bottom line. Aside from the revenue benefits that come from increased engagement and deliverability, SparkPost can save you money in three ways:

  • by saving energy since you probably have idle servers and cloud computing uses less electricity.
  • by having zero capital costs and using that capital to invest in other areas of your business.
  • by allowing you to redeploy your valuable IT resources to areas that make your business more revenue.

Still not convinced? Hear what Justin Newton of Netki had to say:

Contact us or schedule a demo or call us for more information 877-887-3031



Last week, we revealed the top ranked best email marketing blog posts in positions 10 to 6 in 2013. Email deliverability, DKIM and email subject lines were all subjects that our readers were interested, so let’s see what other posts they really liked in 2013. Time for the top five best email marketing blog posts!

#5. Converting to 1024-bit DKIM

In the fifth place, is a post from 2012 by Mike Hillyer from Product Management that snuck into our rankings – looks like information about upgrading DKIM keys to 1024-bit still is a hot topic among our readers in 2013!

#4. Appeasing ISPs: When Speedy Email Delivery Is A Problem

Ahhh which email marketer doesn’t want to be on the good side of Internet Service Providers? And that they can with Adaptive Delivery®! Solution engineer, Tom Cain explains how Adaptive Delivery automatically adjusts the speed of email being sent based on feedback by ISPs in real-time.

#3. The Latest Word on Push Notifications and Mobile App Messaging

Making an entry in third place, is Senior Content Manager, John Pinson’s post on push notifications! Want to increase customer engagement through mobile app marketing with both mobile and push messaging? Talk to us, we’ve got the solution for you with Momentum Mobile. But first, read John’s excellent post on mobile push notifications and their role in driving mobile app engagement!

#2. Tech Tips: How Do I Backup And Restore The Postgres Database?

Karan Singh from Engineering provides a quick guide on how to back up and restore your postgres database! Have you backed up your postgres database lately?

#1. 10 Killer Tips For An Effective Email Marketing Campaign

And in position number 1 is my personal favorite – otherwise known as how Kobo convinced me to shell out a significant amount of money on books in one single email! I’m biased of course, but I very much enjoyed writing this blog post and I’m glad you enjoyed reading it on your part!

Dear readers, thanks for the support in 2013, and we look forward to bringing you even more interesting email mobile marketing news in 2014, be it related to DKIM, postgres, push notifications or email marketing campaign tips!

A successful email campaign starts with understanding what works – or not – in the email industry, download The 6 Secrets of Successful Senders guide today!


Adaptive Delivery® (Over) Simplified

We all know that Momentum can deliver email FAST! But, it turns out that Momentum CAN actually deliver too fast and make big ISPs like Gmail, Hotmail, and Yahoo! sort of cranky.

So, another great feature of Momentum (other than speed) is  controlled speed. That is, Momentum can be instructed to deliver email to ISPs in a controlled fashion through Adaptive Delivery (AD).

In order to understand how AD works, we need to have a general understanding of how our customers are able to control HOW Momentum sends messages.

Momentum customers have always been able to manually control how Momentum does the following:

  1. Limit the number of messages sent per hour (or per N seconds)
  2. Limit the number of connections that we’ve established AT ANY ONE TIME
  3. Limit the number of connections that we establish per hour (or per N seconds)
  4. Limit the number of messages we send on ANY ONE CONNECTION

Momentum has so-called “configuration options” that refer directly to these concepts:

  1. Outbound_Throttle_Messages
  2. Max_Outbound_Connections
  3. Outbound_Throttle_Connections
  4. Max_Recipients_Per_Connection

Customers can manually control Momentum’s delivery habits by manually configuring these options in Momentum. It’s important to know that these values can be set with DIFFERENT values depending on:

  1. Which ISP is receiving the message
  2. Which customer (or IP address) is sending the message from Momentum

For example, you might instruct Momentum to limit its interaction with Gmail:

For the domain, never simultaneously open more than 30 connections. In Momentum this might look something like this:

Domain “” {

Max_Outbound_Connections = 30


All four configuration options listed above may be manually configured, one at a time, for each ISP, and for each of your sending customers. Here’s the problem with statically setting those: It could be that an ISP “gets upset” with one of your marketing campaigns … perhaps you put some content in the message that was considered “spammy” or you targeted the wrong list and a lot of the recipients tagged the message as “unwanted” or “spam”. All of sudden, the ISP may not want so much mail from you. It’s a real hassle to have to commit the human resources to monitor this all day long, 24/7/365!

Adaptive Comes to the Rescue

With Momentum’s Adaptive Delivery we introduce something pretty cool for the customer: The ability to “send more mail” or “send less mail” throughout the day AUTOMATICALLY based upon the feedback from the ISP. Let’s talk more about that. What do we mean by that?

Mail Exchange (MX) servers are machines that “talk” SMTP (which stands for “Send Mail To People” … or was that “Simple Mail Transfer Protocol”?). When Momentum attempts delivery of a message to a specific ISP, the MX servers let us know the outcome of the attempt through so-called Delivery Status Notifications (DSNs). They roughly come in 3 forms: (These examples are REAL responses from a Gmail MX server):

I’ll take the message! … but Gmail says:

  • 250 2.0.0 OK 1363971536 os3si3214339vcb.23 – gsmtp)

I won’t take it now, but I might take it later … but Gmail says

  • 452-4.2.2 The email account that you tried to reach is over quota. Please direct\r\n452-4.2.2 the recipient to\r\n452 4.2.2 a1si964185vef.2 – gsmtp
  • 421-4.7.0 [ 10] Our system has detected an unusual rate of\r\n421- 4.7.0 unsolicited mail originating from your IP address. To protect our\r\n421-4.7.0 users from spam, mail sent from your IP address has been temporarily\r\n421-4.7.0 blocked. Please visit\r\n421 4.7.0 to review our Bulk Email Senders Guidelines. s20si1843829vcp.41 – gsmtp

I’m not taking your message (now or ever) – Goodbye! … but Gmail says:

  • o 550-5.1.1 The email account that you tried to reach does not exist. Please try\r\n550-5.1.1 double-checking the recipient’s email address for typos or\r\n550-5.1.1 unnecessary spaces. Learn more at\r\n550 5.1.1 p8si1427513vdw.10 – gsmtp
  • 550 5.2.1 The email account that you tried to reach is disabled. p19si3057754vcw.43 – gsmtp

How Does Adaptive Work? – A Specific Example

Momentum’s Adaptive Delivery removes a lot of the need for human intervention by adjusting certain traffic shaping options automatically, in real time, while mail is being delivered!

The way that Adaptive does this is through a set of “traffic shaping modification rules” that guides its behavior. Here’s one example of an Adaptive Rule:

[“”] = {

responses = {


code = “Our system has detected an unusual rate of.*unsolicited mail originating from your IP address”,

trigger = “1”,

action = {“suspend”, “2 hours”},

message = “IP blocked temporarily due to high complaint rate”,

phase = “connect”,


Now, let’s show what would happen if a Gmail MX server responded to one of our attempts to deliver a given email with the following error message:

421-4.7.0 [ 10] Our system has detected an unusual rate of\r\n421-4.7.0 unsolicited mail originating from your IP address. To protect our\r\n421-4.7.0 users from spam, mail sent from your IP address has been temporarily\r\n421-4.7.0 blocked. Please visit\r\n421 4.7.0 to review our Bulk Email Senders Guidelines. s20si1843829vcp.41 – gsmtp

So What Exactly Happens?

  • Momentum tries to deliver the message
  • Gmail responds with the “421” error message above
  • Adaptive delivery looks at the response from Gmail and consults its “rules file” to see if there’s a match and finds one.

How? The string in the “code” above has a so-called “wildcard match” within it. We will get a match as long as the response from Gmail has these 2 components in it:

  • ” Our system has detected an unusual rate of” AND “unsolicited mail originating from your IP address”
  • Adaptive delivery tells Momentum: Don’t send any more email to Gmail (from a specific sending IP address) for 2 hours.

After 2 hours, Momentum will resume delivery to Gmail, as normal!

What Other Things Can Adaptive Do?

The example above showed how Momentum would stop sending messages to Gmail under a specific circumstance … when Gmail thinks that there is too much unsolicited mail coming from the sender.

However, adaptive can do much more including (but not limited to): reducing connections, reducing the number of messages sent on connections, and warming up IP addresses. I’ll give more information, at a more technical level in my next “Tips and Tricks” article: “Adaptive Delivery (Less Over) Simplified”. Stay tuned!

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