IP dedicati: scopri quando conviene sceglierli

20 Ottobre 2020

In questo articolo

I primi passi

Molte volte i nostri clienti ci chiedono se sia meglio inviare le email da IP condivisi oppure avere IP dedicati.
Di solito, come primo passo, segnaliamo le pagine della nostra guida dove sono raccolte le informazioni basilari che possono aiutare nella decisione.

Eppure su internet ci sono molte opinioni discordanti e contrastanti sull’argomento, la maggior parte delle quali non ha un sufficiente livello di approfondimento. Ne approfitto per condividere le mie considerazioni in merito.

Il punto di vista di un ESP

Non desidero soffermarmi sugli aspetti strettamente tecnici – già affrontati nella nostra guida e che probabilmente non farebbero altro che portare alla ovvia conclusione che “dipende da numerosi fattori” – ma vorrei considerare invece un altro punto di vista: quello di un Email Service Provider che ritiene la deliverability delle email dei clienti così importante al punto da investire moltissimo tempo e risorse nella lotta allo spam.

In molti ritengono l’uso di IP condivisi una possibile fonte di problemi: non avendo il mittente il pieno controllo della reputazione, se gli invii di altri clienti generano segnalazioni spam anche il sender più diligente può essere penalizzato.

Un’affermazione che potrebbe essere ritenuta vera (il condizionale è d’obbligo per i motivi che spiegherò), ma che non dà abbastanza risalto agli sforzi degli ESP che, come noi di MailUp, fanno gestire tutto il traffico in uscita. Non tutti gli ESP sono uguali e non tutti hanno le stesse pratiche.

MailUp non usa migliaia di IP contemporaneamente per agevolare il traffico dei clienti in uscita; utilizziamo diverse categorie di IP e separiamo, in modo molto rigoroso, il traffico di quanti usano IP condivisi sul pool più idoneo alla tipologia di invio.

Questa scelta avviene considerando moltissimi dati:

pattern distribuzione del volume
tasso di bounce
segnalazioni spam
tasso di aperture
tasso di clic
tipologia delle comunicazioni
“fingerprinting” del contenuto
modalità di acquisizione.

Da non sottovalutare, inoltre, i bounce e le segnalazioni spam: superate soglie stabilite, il nostro team di compliance si attiva subito per verificare le attività del cliente e la correttezza dell’acquisizione del consenso.

Per questo motivo mi sento di affermare con sicurezza che, se l’email service provider lavora bene, il “rischio” di usare IP condivisi è veramente marginale e può tramutarsi invece in un vantaggio, perché aiuta i clienti a mantenere una buona consistenza del traffico su tutte le direttive, cosa che non sempre è possibile senza sforzi aggiuntivi da parte dei clienti stessi.

IP condivisi: opinioni a confronto

Mi rammarico come con molta (troppa) facilità vengono offerti IP dedicati per migliorare la deliverability come prima soluzione, senza preoccuparsi del resto. In realtà se tale proposta non è legata a motivazioni più solide (come potrebbe essere, per esempio, la certificazione Return Path) o non viene da una attenta analisi dei flussi email del cliente potrebbe essere vista più che altro come uno scarico di responsabilità, dall’ESP verso il cliente, specialmente per chi cerca di isolare le cattive pratiche dei clienti in questo modo.

Personalmente non sono d’accordo con questa linea. La responsabilità dell’ESP rimane inalterata, sia nei confronti dei clienti che hanno IP condivisi, sia – soprattutto – nei confronti di chi ha IP dedicati. Del resto è lo stesso ESP che ha accettato il cliente e gli ha consigliato una soluzione anziché un’altra. A maggior ragione se sto configurando un canale di invio dedicato che, a differenza dei canali condivisi, richiede una configurazione iniziale e, possibilmente, l’indicazione del nome del cliente nei domini utilizzati.

Come non sono d’accordo (e l’esperienza me lo conferma) con il concetto per cui se alcuni IP dedicati sono problematici il problema sia isolato e non contribuisca più di tanto alla reputazione globale dell’Email Service Provider. Gli ISP possono decidere di ritenerlo opportuno e di bloccare intere subnet o – peggio – i domini / PTR, compromettendo così la deliverability sia delle classi dedicate che di quelle condivise.

Se da un lato avere una buona segregazione del traffico in uscita è sicuramente una strategia ottimale, attenzione a non abusarne per aggirare i problemi di reputazione e blocco. Del resto la reputazione di un ESP viene data dalla somma della reputazione dei suoi clienti, nessuno escluso.

A conferma di quanto sopra e come testimoniato da diverse fonti autorevoli – quali Laura Atkins in un recente follow up a un suo stesso articolo – per i sender legittimi la reputazione dei soli IP è un fattore oramai veramente marginale, in quanto i provider più importanti (e a seguire quelli meno rilevanti) si stanno spostando verso analisi delle attività dei destinatari (engagement) e – a seguito dell’introduzione delle tecnologie quali SPF, DKIM e DMARC – la reputazione si sta spostando sempre di più sul dominio piuttosto che sugli IP.

Il consenso è la vera soluzione

Attenersi alle best practice e raccogliere il consenso dei destinatari a norma di legge è l’unica soluzione che paga veramente. Per il resto, vi consiglio di affidarvi all’esperienza dei (buoni) Email Service Provider.

Questa è di fatto una buona notizia per i marketer, che in tal modo possono concentrarsi sull’obiettivo principale: inviare contenuti rilevanti a destinatari che non solo li aspettano, ma sono felici di riceverli.

Alberto Miscia

Lavoro nel settore dell'email marketing da più di 10 anni. Amo i numeri, riuscire a capire quello che "dicono" e - ancora di più - quello che "non dicono". Questo ha fatto si che il mio sviluppo naturale sia stato nel campo della Email Deliverability, un territorio dove le certezze sono poche e l'unica è che che l'email arriva a destinazione se il destinatario la vuole ricevere e la ritiene rilevante. Il mio ambizioso obiettivo è far in modo che siano sempre di più i destinatari che vogliono ricevere le email inviate dai clienti MailUp e che tali destinatari le ricevano in inbox.