Cos'è un ESP? L'architettura dietro l'acronimo

Questo articolo è una traduzione assistita dall’AI dell’originale in inglese, revisionata dall’autore.

Primo di una lineage che va da ESP a MAP a la CEP. Questa è la fondazione su cui le altre due sono state costruite, e una delle ragioni per cui i confini fra loro sono così difficili da separare in modo netto oggi.

Chiedete a un marketer sotto i trenta cosa sia un ESP e spesso otterrete una pausa. Email Service Provider. Il termine è uscito silenziosamente dalla conversazione, rimpiazzato da “la piattaforma”, “la CEP”, o semplicemente il nome del vendor. Eppure quasi ogni brand invia ancora email attraverso uno di essi. L’acronimo è sfumato mentre la funzione si è diffusa ovunque.

È questa la cosa interessante dell’ESP, ed è la ragione per cui è il punto giusto da cui far partire questa serie. Non è una categoria morta. È una categoria assorbita. Capire cosa fosse, e dove sia finita, è il modo più pulito per capire i due acronimi che ne sono nati.

Cosa risolveva davvero

Nei primi anni 2000, inviare email su scala era un problema di infrastruttura, non di marketing. Se volevate raggiungere centomila caselle di posta, vi servivano mail server, indirizzi IP con una reputazione di invio, gestione dei bounce, gestione delle disiscrizioni e qualcuno che capisse perché i vostri messaggi finivano nelle cartelle bulk. Niente di tutto ciò era lavoro di marketing. Era idraulica della deliverability, ed era abbastanza difficile da far comparire una categoria di vendor pronti a vendervela.

Questa era la value proposition originale dell’ESP, e vale la pena dirlo chiaramente perché spiega tutto quello che è venuto dopo. L’ESP si prendeva le parti dell’email che erano operativamente dolorose e reputazionalmente rischiose: gestione dell’infrastruttura di invio, protezione della reputazione di IP e dominio, gestione dei meccanismi di consenso e soppressione, e reportistica su cosa veniva consegnato, aperto e cliccato. Il marketer portava una lista e una creatività. L’ESP si assicurava che arrivasse.

Era una vera decisione architetturale, anche se all’epoca nessuno la chiamava così. Tracciava un confine: il brand possedeva l’audience e il messaggio, il vendor possedeva l’invio. Quel confine è ancora visibile in ogni stack di oggi, persino in quelli che lo hanno sepolto sotto tre strati di software più recente.

Il mercato che l’ha plasmato

L’ESP è nato in un mondo batch, e il suo data model lo dimostra. L’unità di lavoro era la campagna. Costruivate una lista, o estraevate un segmento, disegnavate un’email, schedulavate un invio e leggevate il report a posteriori. L’intero sistema assumeva un ciclo stabile: pianifica, segmenta, schedula, misura, ripeti. Quell’assunzione era ragionevole quando l’email era il canale e il customer journey era qualcosa che si disegnava una volta a trimestre.

Il mercato premiava i vendor che rendevano quel ciclo più economico e più sicuro. La competizione correva su tassi di deliverability, editor di template, gestione delle liste e prezzo per mille invii. Per buona parte degli anni 2000 quello era un business perfettamente valido e uno strumento perfettamente valido. Il vincolo non era l’ESP. Il vincolo era che il mondo per cui era stato costruito stava per frammentarsi.

Quando è arrivato lo smartphone e il journey si è disperso fra web, app, in-store e assistenza, il modello a forma di campagna e guidato dalle liste ha iniziato a scricchiolare. I marketer volevano agire sul comportamento, non sugli schedule. Volevano innescare da un evento, non da un calendario. L’ESP poteva aggiungere qualcosa di tutto ciò, e molti lo fecero, ma il centro di gravità restava il messaggio e l’invio. Qualcosa doveva spostare il centro di gravità sul cliente. Quel qualcosa è diventato la Marketing Automation, e più tardi la CEP, che è dove i prossimi due articoli di questa serie riprendono il filo.

Come i vendor ne hanno cambiato il significato

È qui che l’acronimo diventa scivoloso, ed è qui che vive gran parte della confusione.

La prima cosa che è successa è che gli ESP hanno smesso di voler essere chiamati ESP. La parola segnalava commodity: un motore di invio, prezzato per mille, facilmente sostituibile. Così i vendor hanno scalato la catena del valore. Hanno aggiunto automation, poi journey, poi cross-channel, poi “customer engagement”, e si sono rinominati di conseguenza. Il prodotto che era un ESP nel 2008 era un “marketing cloud” nel 2015 e una “customer engagement platform” nel 2022, spesso senza una singola riscrittura che si possa indicare come il momento in cui ha smesso di essere un ESP.

La seconda cosa che è successa è che il motore di invio non se n’è mai davvero andato. È stato spinto un livello più in basso e rinominato. Quello che un vendor oggi chiama il suo “channel layer” o “delivery layer” per l’email è, architetturalmente, un ESP. Il warm-up degli IP, la gestione della reputazione, la gestione di bounce e reclami, la logica di soppressione: tutto ancora lì, tutto ancora portante, semplicemente non più il titolo principale. La categoria si è dissolta verso l’alto dentro piattaforme più grandi mentre la funzione è rimasta esattamente dov’era.

La prova più chiara di questo è ciò che sta sotto le piattaforme che si suppone abbiano rimpiazzato l’ESP. Un intero tier di infrastruttura dedicata all’invio email vive ora sotto gli strumenti rivolti al marketing: Amazon SES, Twilio SendGrid, SparkPost (ora Bird), Mailgun e una manciata di altri. Molte delle piattaforme che considerate strumenti di engagement moderni instradano l’email attraverso uno di questi provider invece di trattare l’infrastruttura di delivery come il prodotto visibile. Braze invia attraverso SparkPost, SendGrid o Amazon SES, con il marketer che configura quale. Iterable usa di default Amazon SES e supporta anche SparkPost, Mailgun e SendGrid. Customer.io consente di inviare attraverso il proprio delivery o attraverso SendGrid, SparkPost, Mailgun, Mailjet o Amazon SES via SMTP. Un secondo tier di piattaforme più leggere è costruito direttamente sopra Amazon SES come intero backend di invio. In ciascun caso il prodotto in vetrina è uno strato di orchestrazione, e un classico ESP sta facendo la consegna vera e propria sotto. L’acronimo che avete smesso di pronunciare è spesso un’impostazione di configurazione dentro la piattaforma che avete comprato per rimpiazzarlo.

Vale la pena notare cosa è successo a quei provider sottostanti, perché racconta la stessa storia dall’altro capo. Man mano che il brand ESP diventava fuori moda per i marketer, i motori di invio più forti si sono riposizionati come infrastruttura email rivolta agli sviluppatori e sono stati acquisiti come tali. Twilio ha acquisito SendGrid nel 2019 in un’operazione valutata circa tre miliardi di dollari, integrandolo in una piattaforma di API di comunicazione. MessageBird (ora Bird) ha acquisito SparkPost nel 2021 per circa seicento milioni di dollari. L’ESP non è morto. Si è diviso in due: la metà rivolta al marketing è salita dentro le CEP, e la metà più tecnologica è scesa ed è diventata l’infrastruttura email su cui quelle CEP, e una lunga coda di strumenti più piccoli, girano silenziosamente.

Come l'ESP si è diviso in due: uno strato di orchestrazione rivolto al marketing in cima, la classica infrastruttura di delivery email sotto

Gli analisti rendono visibile questa divisione, anche se non la nominano mai. Forrester pubblica ancora una Wave per quelli che chiama Email Marketing Service Provider (l’edizione Q1 2026 valuta dodici vendor fra cui Adobe, Salesforce, SAP, Braze, Klaviyo, Iterable e Bloomreach). Notate che molti di questi non sono puri motori di invio; sono piattaforme di marketing più ampie. Quindi quando Forrester dice “ESP” intende lo strato di orchestrazione, non lo strato di delivery, che è l’esatto opposto di ciò che il termine significava vent’anni fa. Gartner, dal canto suo, non dedica più all’email standalone un proprio Magic Quadrant. Copre l’email attraverso un Market Guide e ripiega l’esecuzione nel suo quadrante Multichannel Marketing Hubs. Due delle voci più autorevoli del settore hanno, di fatto, abbandonato il significato infrastrutturale originale di ESP e riutilizzato le lettere per lo strato sopra di esso. La parola ora punta a due cose diverse a seconda di chi parla: l’infrastruttura che consegna, o la piattaforma che decide.

È per questo che “quale ESP dovremmo comprare” è sempre più la domanda sbagliata, un punto che ho sostenuto in L’email non è morta. Viene ricostruita a partire dall’inbox. La domanda vera è quale piattaforma possiede l’email nel vostro stack, e se l’email è uno strumento standalone o un output di uno strato di decisioning che guida anche push, in-app e SMS. L’ESP non ha perso quella discussione. È stato semplicemente retrocesso dall’essere la piattaforma all’essere un componente all’interno di un’altra.

Cosa significa architetturalmente oggi

Se togliete il branding, l’ESP oggi si comprende meglio non come un prodotto che comprate ma come uno strato che avete sempre. Da qualche parte nel vostro stack, qualcosa è responsabile di trasformare una decisione (“invia a questa persona questo messaggio ora”) in un’email consegnata con buone probabilità di raggiungere l’inbox. Quella responsabilità è la funzione ESP, che risieda dentro Braze, Salesforce Marketing Cloud, Klaviyo, uno standalone come un’API di email transazionale, o una combinazione.

Vederla come uno strato piuttosto che come un prodotto cambia le domande che ponete. Smettete di chiedere se una piattaforma “fa email” (lo dichiarano tutte) e iniziate a chiedere chi possiede la deliverability, se la reputazione di invio è condivisa o dedicata, dove vivono davvero soppressione e consenso, e se lo strato email può essere guidato dallo stesso decisioning in tempo reale che guida gli altri canali oppure è un silo batch separato che indossa lo stesso logo. Queste sono domande architetturali, ed è proprio l’eredità dell’ESP a renderle taglienti.

Chiarisce anche una modalità di fallimento comune. Molte organizzazioni migrano verso una CEP luccicante e continuano silenziosamente a gestire l’email alla vecchia maniera dentro di essa: estrazioni di liste, invii massivi schedulati, un calendario di campagne. Hanno comprato una piattaforma di decisioning e l’hanno usata come un ESP. L’acronimo che credete di esservi lasciati alle spalle è spesso quello che state ancora operando.

Con cosa viene confuso

L’ESP viene confuso con MAP e la CEP perché tutti e tre possono inviare email, e perché i vendor hanno deliberatamente sfumato i confini mentre scalavano la catena del valore. La distinzione pulita è di scope. Un ESP invia e consegna messaggi. Un MAP (il prossimo articolo) aggiunge la logica che decide chi riceve cosa e quando, costruita attorno a un data model di lead e lifecycle. Una CEP allarga ulteriormente verso il decisioning in tempo reale e multicanale, dove l’email è un output fra molti. Ciascuno ha assorbito il precedente. La confusione non è colpa vostra; è il registro fossile dell’assorbimento.

Viene confuso anche, nell’altra direzione, con l’infrastruttura di email transazionale: le API che fanno partire ricevute, reset di password e notifiche di spedizione. Architetturalmente queste sono molto vicine a una pura funzione ESP, ma stanno dal lato ingegneristico della casa piuttosto che dal lato marketing. Vale la pena sapere che sono cugine, perché in uno stack ben progettato la domanda se email di marketing e transazionale condividano infrastruttura di invio e reputazione è una decisione vera con conseguenze vere.

Conta ancora

Come categoria di acquisto, l’acronimo conta molto meno di un tempo. Pochi RFP seri del 2026 dovrebbero trattare “ESP” come l’intera categoria da valutare. Come etichetta per una decisione di piattaforma completa, è in gran parte finito.

La funzione non potrebbe contare di più. Ogni piattaforma che ha rimpiazzato l’ESP ne ha ancora uno dentro, e i brand che sbagliano l’email quasi sempre la sbagliano esattamente allo stesso modo: reputazione, deliverability, consenso, soppressione. I numeri lo confermano: l’email resta uno dei canali a più alto ROI nello stack, con stime di settore attorno ai trentasei dollari restituiti per dollaro speso, mentre i benchmark di deliverability mostrano ancora una quota significativa di email che non raggiunge l’inbox. Quel divario è lo strato ESP che fa il suo lavoro bene o male. Più nuova è la piattaforma, più facile è dimenticare che questa dinamica esiste, fino al momento in cui il posizionamento in inbox crolla e qualcuno deve andarla a cercare.

L’ESP è una categoria morta e una funzione viva: smettete di cercarne uno da comprare, ma non smettete mai di possedere lo strato che ha battezzato, perché tutto ciò che avete comprato per rimpiazzarlo continua a girarci sopra.