Tasso di rimbalzo email: come misurarlo e cosa correggere

Il tasso di rimbalzo email è la quota di messaggi inviati che il server ricevente ha rifiutato, divisa per i messaggi inviati. Su una lista sana, tieni i bounce hard sotto l'1%, tratta il 2% come la soglia oltre cui indagare e considera il 5% un incidente. Molti team leggono un unico numero aggregato dalla dashboard e non notano che denominatore, tipo di rimbalzo e finestra temporale cambiano la risposta.

Il resto di questo articolo riguarda prima come ottenere il numero giusto, poi come decidere cosa fare.

La formula è semplice. Il denominatore è il punto di disaccordo.

Tasso di rimbalzo uguale a messaggi rimbalzati diviso messaggi inviati, per 100. Alcuni ESP dividono invece per i messaggi consegnati, e il risultato sale perché i consegnati escludono già i rimbalzi. Prima di confrontare il numero con un benchmark, verifica quale delle due definizioni usa il tuo provider.

Amazon SES, per esempio, calcola il proprio tasso solo sui bounce hard, rapportati a quanto hai inviato dall'account. Il dettaglio conta: una dashboard che mescola bounce soft e hard mostra un numero più alto di quello con cui il provider valuta il tuo account.

Scegli una definizione e scrivila accanto alla metrica, se serve nel titolo del grafico. Noi usiamo i bounce hard sugli invii, per dominio di invio, su 24 ore e su 7 giorni. Se due persone del team citano numeri diversi per la stessa settimana, il primo elemento da confrontare è il denominatore.

Bounce hard, soft e block sono tre segnali diversi

Un bounce hard è un errore permanente: l'indirizzo non esiste, il dominio non risolve o la casella è stata chiusa. SMTP lo segnala con un codice di stato avanzato 5.x.x, definito nella RFC 3463.

Un bounce soft è un errore temporaneo: casella piena, server non raggiungibile, messaggio troppo grande. Arriva con codici 4.x.x e un mittente corretto li ritenta. Per la classificazione completa dei codici SMTP rimandiamo al nostro precedente articolo sulla differenza tra soft bounce e hard bounce.

La terza categoria è quella che le dashboard nascondono: il block. È un rifiuto 5.x.x che non dice nulla sull'indirizzo e tutto su di te: un IP finito in blacklist, un controllo di autenticazione fallito, un filtro di contenuto o di reputazione. Contare un block come bounce hard fa sembrare sporca la lista quando il problema è la configurazione dell'invio.

Diffida di ogni report che mostra una sola riga "bounce". Separa le tre serie, altrimenti finirai per ripulire una lista che non era il problema.

Qual è un buon tasso di rimbalzo nel 2026?

Non esiste un numero unico pubblicato, e conviene saperlo prima di citarne uno. Gmail e Yahoo pubblicano soglie per i reclami di spam, non per i bounce. Google chiede ai mittenti in blocco di mantenere il tasso di spam riportato in Postmaster Tools sotto lo 0,10% e di non superare mai lo 0,30%, come indicato nelle sue linee guida per i mittenti.

Per i bounce, le soglie di riferimento arrivano dagli ESP e dalla pratica. Le usiamo come livelli di allerta, non come garanzie di un provider di caselle di posta. Tasso di bounce hard per dominio su 24 ore, e come lo trattiamo:

• Sotto lo 0,5%: normale per una lista coinvolta e verificata.

• Dallo 0,5% all'1%: osserva e controlla la provenienza dei nuovi indirizzi.

• Dall'1% al 2%: indaga e sospendi il segmento con il tasso più alto.

• Dal 2% al 5%: blocca gli invii di massa da quello stream e trova l'import o il form che li genera.

• Oltre il 5%: incidente. Amazon SES mette l'account sotto revisione a questo livello.

L'ultima riga è una soglia documentata. Nella sua documentazione della dashboard di reputazione, Amazon SES dichiara che un account con un tasso di bounce pari o superiore al 5% viene messo sotto revisione, e che l'invio può essere sospeso se il tasso resta sopra il 10%. Gli altri provider usano numeri e formulazioni diversi, quindi leggi il contratto del tuo.

Segmenta prima di tutto: un tasso aggregato nasconde lo stream che fallisce

Un 0,8% complessivo nell'account può contenere uno stream transazionale allo 0,1% e un import di riattivazione al 6%. La media sembra accettabile, mentre il secondo stream danneggia in silenzio il dominio di invio.

Calcola il tasso per stream, per fonte e per dominio del destinatario. Quattro tagli individuano la maggior parte dei problemi:

• Per stream. Transazionale, lifecycle e campagne di massa non dovrebbero condividere lo stesso numero.

• Per fonte di iscrizione. Form, iscrizioni via API, import CSV e liste di partner hanno una qualità degli indirizzi molto diversa.

• Per dominio del destinatario. Un picco presso un solo provider di solito indica una politica di rifiuto, non una lista sporca.

• Per anzianità dell'indirizzo. Gli indirizzi raccolti più di 12 mesi fa rimbalzano più spesso dei più recenti.

Non è un vezzo da report. È la differenza tra correggere un bug di validazione in un'ora e svuotare una lista sana nel panico.

Un quinto taglio utile da aggiungere quando gli altri sono attivi: per IP o dominio di invio. Se usi un IP dedicato per la posta transazionale e un pool condiviso per le campagne, un picco su uno dei due indica dove guardare prima di aprire una sola riga di log.

Leggere gli eventi di bounce dal provider senza perderne nessuno

Ogni ESP serio espone i bounce come eventi: un webhook, un topic di notifica o un'API di eventi. Tratta quel flusso come fonte di verità e scrivilo nel tuo storage, perché le dashboard aggregano e perdono il dettaglio che ti servirà in seguito.

Per ogni evento conserva questi campi: id del messaggio, destinatario, tipo di bounce, codice di stato avanzato, testo diagnostico e timestamp. Con questi sei puoi rispondere quasi a ogni domanda che emerge in un postmortem.

{
  "event": "bounce",
  "message_id": "msg_01H9",
  "recipient": "user@example.com",
  "bounce_type": "permanent",
  "status": "5.1.1",
  "diagnostic": "550 5.1.1 user unknown",
  "stream": "lifecycle",
  "ts": "2026-11-02T09:14:03Z"
}

Rendi il gestore idempotente, con chiave sull'id evento del provider più l'id del messaggio. I provider ritentano i webhook, e un evento di bounce hard duplicato che incrementa due volte un contatore distorce il tasso e può sopprimere un indirizzo che in realtà va bene.

Postmark e Resend separano i tipi di bounce nei loro eventi e permettono di estrarli per stream di messaggi, il che rende poco costoso costruire la divisione per stream descritta sopra.

La regola di soppressione fa la maggior parte del lavoro

Il controllo con più leva è la soppressione automatica. Dopo un bounce hard smetti di scrivere a quell'indirizzo in modo permanente, a livello applicativo e non solo affidandoti alla lista del provider.

La maggior parte degli ESP sopprime già i bounce hard. Il vuoto compare quando cambi provider, ne usi due in parallelo o invii da un sistema che non legge la lista di soppressione. Una tua tabella con l'indirizzo normalizzato chiude quella falla.

Per i bounce soft usa un contatore invece di un singolo evento. Il nostro default è sopprimere dopo tre bounce soft consecutivi in almeno sette giorni. Una casella piena da una settimana, per scopi lifecycle, è ormai persa.

Non cancellare dalla tabella utenti gli indirizzi che hanno rimbalzato. Segnalali con il codice di stato e la data. Una riga cancellata non può dirti che lo stesso indirizzo è rimbalzato due volte il trimestre scorso, e ti serve quel dato per non reimportarlo dal CSV successivo, che è il modo più comune in cui una lista «ripulita» torna sporca.

Perché il tasso sale all'improvviso: le cause più comuni, in ordine

Quando il tasso si muove, cerca la causa in quest'ordine. Le prime tre spiegano la maggior parte dei picchi.

1. Un nuovo import. Un CSV da un evento, da un partner o da un vecchio export del CRM. Controlla il tasso per fonte prima di tutto il resto.

2. Un form di iscrizione senza validazione. Errori di battitura come gmial.com e domini usa e getta. Un controllo di sintassi e MX al momento dell'invio elimina la maggior parte dei casi, e una email di conferma elimina il resto prima che contino come invio in un flusso lifecycle.

3. Una modifica all'invio. Un nuovo IP, un nuovo dominio o un warmup salito troppo in fretta, che si trasforma in block anziché in bounce hard.

4. Un'autenticazione rotta. Allineamento SPF, DKIM o DMARC che fallisce dopo una modifica al DNS.

5. Una politica di rifiuto lato provider. Un dominio destinatario ha irrigidito i filtri. Il tuo tasso sale solo su quel dominio.

La diagnosi passa dalla distribuzione dei codici di stato, raggruppata per stream e per dominio destinatario sulla stessa finestra del picco. Un aumento di 5.1.1 (utente sconosciuto) indica la lista. Un aumento di 5.7.x indica politica, autenticazione o reputazione. Le due situazioni richiedono correzioni opposte, ed è il motivo per cui conservi il codice.

Cosa vorremmo far scattare come allarme

Un allarme sulla media giornaliera arriva troppo tardi. Un import sbagliato può inviare 40.000 messaggi in un'ora. Usa invece una finestra mobile.

• Tasso di bounce hard sopra l'1% sugli ultimi 1.000 invii di qualsiasi stream.

• Qualsiasi dominio destinatario sopra il 5% su almeno 200 invii in un'ora.

• Un numero di block 5.7.x che supera la baseline normale con un margine netto.

Collega i primi due a una pausa dello stream responsabile, non a una pagina per una persona. Una persona può indagare dopo. La pausa è ciò che protegge la reputazione nei dieci minuti successivi.

Esporta il tasso nel monitoraggio che usi già, che sia Grafana, Datadog o una soluzione interna, e mantieni l'etichetta dello stream sulla serie, così la divisione sopravvive all'export.

Per la rendicontazione verso il management, usa il tasso di bounce hard per stream su una finestra di 7 giorni, più il conteggio dei block. Lascia i bounce soft nella vista ingegneristica, dove sono utili, e fuori da quella esecutiva, dove creano confusione. Non riportare mai da solo il numero aggregato dell'account, perché si muove per ragioni che nessuno nella stanza sa spiegare.

Se qualcuno chiede una sola cifra, dai il tasso di bounce hard dello stream transazionale. È lo stream in cui un errore costa un reset della password o una fattura, ed è la lettura più pulita dello stato della tua infrastruttura.

Il prossimo passo concreto è piccolo: estrai gli eventi di bounce degli ultimi 30 giorni, raggruppali per stream e codice di stato, e guarda quale riga non ti aspettavi.