First in a lineage that runs ESP to MAP to CEP. This is the foundation the other two were built on, and one reason the boundaries between them are so hard to cleanly separate today.
Ask a marketer under thirty what an ESP is and you will often get a pause. Email Service Provider. The term has quietly fallen out of the conversation, replaced by “the platform”, “the CEP”, or just the vendor’s name. Yet almost every brand still sends email through one. The acronym faded while the function went everywhere.
That is the interesting thing about ESP, and the reason it is the right place to start this series. It is not a dead category. It is an absorbed one. Understanding what it was, and where it went, is the cleanest way to understand the two acronyms that grew out of it.
What it actually solved
In the early 2000s, sending email at scale was an infrastructure problem, not a marketing one. If you wanted to reach a hundred thousand inboxes, you needed mail servers, IP addresses with a sending reputation, bounce handling, unsubscribe management, and someone who understood why your messages were landing in bulk folders. None of that was marketing work. It was deliverability plumbing, and it was hard enough that a category of vendors appeared to own it for you.
That was the original ESP value proposition, and it is worth stating plainly because it explains everything that came after. The ESP took on the parts of email that were operationally painful and reputationally risky: managing sending infrastructure, protecting IP and domain reputation, handling the mechanics of consent and suppression, and reporting on what was delivered, opened, and clicked. The marketer brought a list and a creative. The ESP made sure it arrived.
This was a genuine architectural decision, even if nobody called it that at the time. It drew a boundary: the brand owned the audience and the message, the vendor owned the send. That boundary is still visible in every stack today, even the ones that have buried it under three layers of newer software.
The market that shaped it
The ESP was born into a batch world, and its data model shows it. The unit of work was the campaign. You built a list, or pulled a segment, designed an email, scheduled a send, and read the report afterwards. The whole system assumed a stable cycle: plan, segment, schedule, measure, repeat. That assumption was reasonable when email was the channel and the customer journey was something you drew once a quarter.
The market rewarded the vendors who made that cycle cheaper and safer. Competition ran on deliverability rates, template editors, list management, and price per thousand sends. For most of the 2000s that was a perfectly good business and a perfectly good tool. The constraint was not the ESP. The constraint was that the world it was built for was about to fragment.
When the smartphone arrived and the journey scattered across web, app, in-store, and service, the campaign-shaped, list-driven model started to strain. Marketers wanted to act on behaviour, not on schedules. They wanted to trigger from an event, not from a calendar. The ESP could bolt some of that on, and many did, but the centre of gravity was still the message and the send. Something had to move the centre of gravity to the customer. That something became Marketing Automation, and later the CEP, which is where the next two articles in this series pick up.
How vendors changed the meaning
Here is where the acronym gets slippery, and where most confusion lives.
The first thing that happened is that ESPs stopped wanting to be called ESPs. The word signalled commodity: a send engine, priced per thousand, easily switched. So vendors climbed the value chain. They added automation, then journeys, then cross-channel, then “customer engagement”, and rebranded accordingly. The product that was an ESP in 2008 was a “marketing cloud” by 2015 and a “customer engagement platform” by 2022, often without any single rewrite that you could point to as the moment it stopped being an ESP.
The second thing that happened is that the send engine never actually left. It got pushed down a layer and renamed. What a vendor today calls its “channel layer” or “delivery layer” for email is, architecturally, an ESP. The IP warm-up, the reputation management, the bounce and complaint handling, the suppression logic: all still there, all still load-bearing, just no longer the headline. The category dissolved upward into bigger platforms while the function stayed exactly where it was.
The clearest proof of this is what sits underneath the platforms that supposedly replaced the ESP. A whole tier of dedicated email-sending infrastructure now lives below the marketing-facing tools: Amazon SES, Twilio SendGrid, SparkPost (now Bird), Mailgun, and a handful of others. Many of the platforms you think of as modern engagement tools route email through one of these providers rather than treating delivery infrastructure as the visible product. Braze sends through SparkPost, SendGrid, or Amazon SES, with the marketer configuring which one. Iterable defaults to Amazon SES and also supports SparkPost, Mailgun, and SendGrid. Customer.io lets you send through its own delivery or through SendGrid, SparkPost, Mailgun, Mailjet, or Amazon SES over SMTP. A second tier of lighter platforms is built directly on top of Amazon SES as their entire sending backend. In each case the headline product is an orchestration layer, and a classic ESP is doing the actual delivery underneath. The acronym you stopped saying is often a configuration setting inside the platform you bought to replace it.
It is worth noticing what happened to those underlying providers, because it tells the same story from the other end. As the ESP brand became unfashionable for marketers, the strongest send engines repositioned as developer-facing email infrastructure and got bought as such. Twilio acquired SendGrid in 2019 in a deal valued at roughly three billion dollars, folding it into a communications API platform. MessageBird (now Bird) acquired SparkPost in 2021 for around six hundred million dollars; SparkPost alone was sending on the order of five trillion emails a year. The ESP did not die. It split in two: the marketing-facing half climbed up into CEPs, and the plumbing half went down and became the email infrastructure that those CEPs, and a long tail of smaller tools, quietly run on.
The analysts make this split visible, even if they never name it. Forrester still publishes a Wave for what it calls Email Marketing Service Providers (the Q1 2026 edition evaluates twelve vendors including Adobe, Salesforce, SAP, Braze, Klaviyo, Iterable, and Bloomreach). Notice that many of those are not pure send engines; they are broader marketing platforms. So when Forrester says “ESP” it means the orchestration layer, not the delivery layer, which is the exact opposite of what the term meant twenty years ago. Gartner, meanwhile, no longer gives standalone email its own Magic Quadrant. It covers email through a Market Guide and folds the execution into its Multichannel Marketing Hubs quadrant. Two of the most authoritative voices in the industry have, in effect, moved away from the original infrastructure meaning of ESP and reused the letters for the layer above it. The word now points at two different things depending on who is speaking: the infrastructure that delivers, or the platform that decides.
This is why “which ESP should we buy” is increasingly the wrong question, a point I made in Email Isn’t Dead. It’s Being Rebuilt From the Inbox Up. The real question is which platform owns email in your stack, and whether email is a standalone tool or one output of a decisioning layer that also drives push, in-app, and SMS. The ESP did not lose that argument. It was simply demoted from being the platform to being a component inside one.
What it means architecturally today
If you strip away the branding, the ESP is best understood today not as a product you buy but as a layer you always have. Somewhere in your stack, something is responsible for turning a decision (“send this person this message now”) into a delivered email with a good chance of reaching the inbox. That responsibility is the ESP function, whether it sits inside Braze, Salesforce Marketing Cloud, Klaviyo, a standalone like a transactional email API, or a combination.
Seeing it as a layer rather than a product changes the questions you ask. You stop asking whether a platform “does email” (they all claim to) and start asking who owns deliverability, whether sending reputation is shared or dedicated, where suppression and consent actually live, and whether the email layer can be driven by the same real-time decisioning that drives your other channels or whether it is a separate batch silo wearing the same logo. Those are architecture questions, and the ESP heritage is exactly what makes them sharp.
It also clarifies a common failure mode. Many organisations migrate to a shiny CEP and quietly keep running email the old way inside it: list pulls, scheduled blasts, a campaign calendar. They bought a decisioning platform and used it as an ESP. The acronym you think you left behind is often the one you are still operating.
What it gets confused with
ESP gets confused with MAP and CEP because all three can send email, and because vendors deliberately blurred the lines as they climbed the value chain. The clean distinction is one of scope. An ESP sends and delivers messages. A MAP (the next article) adds the logic that decides who gets what and when, built around a lead and lifecycle data model. A CEP widens that further into real-time, multi-channel decisioning where email is one output among many. Each absorbed the one before it. The confusion is not yours; it is the fossil record of the absorption.
It also gets confused, in the other direction, with transactional email infrastructure: the APIs that fire receipts, password resets, and shipping notices. Architecturally these are very close to a pure ESP function, sometimes the same plumbing, but they sit on the engineering side of the house rather than the marketing side. Worth knowing they are cousins, because in a well-designed stack the question of whether marketing and transactional email share sending infrastructure and reputation is a real decision with real consequences.
Does it still matter
As a buying category, the acronym matters much less than it used to. Few serious 2026 RFPs should treat “ESP” as the whole category to evaluate. As a label for a complete platform decision, it is largely finished.
The function could not matter more. Every platform that replaced the ESP still has one inside it, and the brands that get email wrong almost always get it wrong at exactly the layer the ESP used to own: reputation, deliverability, consent, suppression. The numbers back this up: email remains one of the highest-ROI channels in the stack, with industry estimates around thirty-six dollars returned per dollar spent, while deliverability benchmarks still show a meaningful share of email failing to reach the inbox. That gap is the ESP layer doing its job well or badly. The newer the platform, the easier it is to forget that this plumbing exists, right up until inbox placement drops and someone has to go looking for it.
ESP is a dead category and a live function: stop shopping for one, but never stop owning the layer it named, because everything you bought to replace it still runs on it.
Sources
Braze
Iterable
Customer.io
Amazon AWS
Twilio
TechCrunch
Forrester
Gartner
Litmus
