- API & Integration
- SparkPost vs SendGrid
- Learn More
- Volume Pricing
Choose your sending volume and get up and running in minutes.
- Add-on Plans
Combine with any volume tier for a custom tailored plan.
- Get Started for Free
From start-up to enterprise, we deliver customer success.
Expand your service with add-on, solution and integration partners.
- User Community Slack Channel
- Help & Docs
- Deliverability Guide
- Case Studies
- Email Explained
- White Papers & Guides
- Webinars & Videos
#1 There is no uniform standard for expressing bounce codes
As a sender’s subscriber base grows and the number of ISPs you’re sending to increases, the number of bounce types grows exponentially. In the real world, there is no uniform standard for expressing codes, and each ISP uses its own variation. Senders, therefore, must be able to track and understand codes from many, many ISPs. Further, as bounces return to the sending system, the operator must remediate those bounces, or take corresponding action to resolve the problem. For example, if an address is reported as invalid by the receiving domain, it is critical for the sender to immediately stop sending – or risk getting blocked to a greater extent by that ISP.
#2 Feedback Loop Processing Is A Complicated Programming Effort
Processing feedback loops (FBLs) is another time consuming task. FBLs are records of recipient responses to email — when you mark a message as spam, for instance — and most domains send a standard Abuse Reporting Format (ARF) report to the originator. But as with bounce codes, report formatting and content varies by reporting domain, making FBL processing a complicated programming effort. Low cost MTAs have little or no FBL functionality, at best providing a mechanism for routing FBL reports to a folder or dedicated mailbox.If the operator wants to automate the process for interpreting the FBL information and implementing remediation policies, that would require designing, building and maintaining an application to do so.
#3 Bounce and FBL processing represent a very expensive hidden cost of owning a legacy or an open source MTA
Some ISPs publish their rules to help guide senders into optimal sending practices. Others don’t publish rule sets at all. Some change their rules frequently, others seldom do. Given there are more than 12,000 ISPs worldwide (about 7,000 in the U.S. alone) and millions of IP domains, it’s impossible for senders to:
a) Keep track of rules worldwide, and
b) Continually tweak/update their sending infrastructure to reflect constant changes.
#4 Momentum includes dedicated bounce and FBL processing and remediation modules
SparkPost provides a simple mechanism for managing this critical part of your messaging infrastructure. We monitor unclassified bounce codes from the worldwide ISP community, and regularly upload new interpretations to our customers’ systems. The module automatically sorts bounces to approximately 20 classifications. Because the classification is available to the policy engine, a simple script can be written to manage remediation policies. The entire process is completely automated, or Momentum operators can choose to customize rules for their own environment.
Additionally, Momentum has an Adaptive Delivery® module, which uses rules and the data streamed through the FBL and bounce modules to optimize outgoing traffic, throttling it down or accelerating it based on ISP feedback.
With commodity infrastructure, users find that they know when messages leave their own campaign management or CMS application, but have no idea how long it takes their MTA to send the messages after that. In some cases, it could take several hours — and this is deeply frustrating for their clients. All of these issues are easily addressed by the SparkPost solution.SparkPost © 2017 All Rights Reserved