Hard bounce, soft bounce: codici SMTP e regola di rimozione

Gmail restituisce la stessa casella piena con due codici opposti: un 452 4.2.2 temporaneo e un 552 5.2.2 definitivo quando l’account è anche inattivo (documentazione Google Workspace, consultata a ottobre 2026). Il primo è un soft bounce, il secondo un hard bounce, per la stessa casella piena a seconda che sia attiva o inattiva. Un hard bounce (rimbalzo permanente) è un rifiuto definitivo: il messaggio non verrà consegnato finché l’indirizzo o il messaggio non cambiano. Un soft bounce (rimbalzo temporaneo) è un errore passeggero che il provider di invio riprova a recapitare. Regola di rimozione: eliminate l’indirizzo al primo hard bounce e rimuovetelo al 3° soft bounce consecutivo, su 3 invii distribuiti in almeno 14 giorni. Qui sotto analizziamo un NDR riga per riga e colleghiamo ogni soglia numerica alla sua fonte.

Hard bounce e soft bounce: confronto punto per punto

I valori della riga «Nuovo tentativo» provengono dalla RFC 5321 (sezioni 4.2.1 e 4.5.4.1). Ogni provider fissa poi la propria durata massima di retry, che trovate nella sua documentazione.

Quali codici SMTP distinguono un hard bounce da un soft bounce?

Un 4xx segnala un errore temporaneo (soft bounce), un 5xx un errore permanente (hard bounce): la prima cifra stabilisce la classe.

Il dettaglio sta nell’enhanced status code, definito dalla RFC 3463 (gennaio 2003). Tre campi separati da punti: classe, soggetto, dettaglio. La classe vale 2 (successo), 4 (errore temporaneo persistente) o 5 (errore permanente). Il soggetto indica l’area coinvolta. L’1 riguarda l’indirizzo, il 2 la casella, il 3 il sistema di posta, il 4 la rete, il 5 il protocollo, il 6 il contenuto, il 7 la sicurezza e le policy.

Il 5.1.1 si legge così: errore permanente (5), problema di indirizzo (1), parte a sinistra della chiocciola non valida (1). Il catalogo è nella guida ai codici di risposta SMTP, i casi 550 5.4.1 e 552 nei codici di errore SMTP.

Leggere un NDR riga per riga: l’esempio del 550 5.1.1

L’NDR (non-delivery report) è un messaggio in formato DSN, descritto dalla RFC 3464, che torna al mittente. L’esempio qui sotto è ricostruito: i campi seguono la RFC 3464 e la diagnostica riprende il testo che Google documenta per il 550 5.1.1. Indirizzi e host mittente sono fittizi.

Reporting-MTA: dns; smtp.esempio.it
Final-Recipient: rfc822; nome.cognome@gmail.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 550 5.1.1 The email account that you tried to reach does not exist.

• Reporting-MTA indica il server che redige il rapporto: qui il vostro provider di invio.
• Final-Recipient riporta l’indirizzo in errore. È la chiave per ricollegarlo alla vostra lista.
• Action: failed indica che la consegna è fallita in modo definitivo.
• Status: 5.1.1 è l’enhanced status code: il 5 classifica l’errore come permanente, l’1.1 indica una casella inesistente.
• Remote-MTA identifica il server che ha rifiutato, qui il server MX di Gmail.
• Diagnostic-Code ricopia la risposta grezza del server: il 550 del livello SMTP, poi il 5.1.1, poi il testo leggibile. Google invita a controllare se c’è un errore di battitura o uno spazio di troppo.

Lo stesso rapporto per una casella che si sta riempiendo cambia in tre righe, secondo il testo di Google per il 452 4.2.2:

Action: delayed
Status: 4.2.2
Diagnostic-Code: smtp; 452 4.2.2 The recipient's inbox is out of storage space.

Il rapporto delayed avvisa che il provider sta ancora riprovando. Un dettaglio cambia la lettura di una dashboard. Una notifica finale può mostrare Action: failed con Status: 4.2.2. La RFC 3463 definisce la classe 4 come una condizione temporanea che ha causato l’abbandono o il ritardo dell’invio. Il provider ha rinunciato dopo i suoi tentativi, senza un rifiuto definitivo del server. Questo caso va classificato come soft bounce esaurito.

Tabella decisionale: dal codice all’azione

Le diciture derivano dalla documentazione Google Workspace sugli errori SMTP di Gmail e dalle definizioni della RFC 3463.

L’ultima riga è la più costosa da leggere male. Un 5.7.26 significa, secondo Google, che il messaggio è bloccato per mancanza di autenticazione (SPF o DKIM) oppure perché la policy DMARC del dominio lo rifiuta. L’indirizzo è valido: a fallire è il vostro dominio. Eliminare questi contatti svuota la lista senza risolvere la causa. Il greylisting rientra nella riga 4.7.x: il server rifiuta di proposito il primo tentativo di un mittente sconosciuto. Il secondo passa.

Bounce sincrono e asincrono: quando arriva il rifiuto

Un rifiuto sincrono arriva durante la sessione SMTP. Il server risponde 550 5.1.1 al comando RCPT TO (o alla fine di DATA): il vostro provider conosce l’esito prima di chiudere la connessione e non c’è nessun NDR da attendere.

Il bounce asincrono segue un altro percorso. Il server risponde prima 250 e prende in carico il messaggio. Se la consegna fallisce poi internamente, la RFC 5321 (sezione 6.1) gli impone di redigere una notifica. Parte verso l’indirizzo di ritorno con un mittente vuoto: il comando MAIL FROM contiene allora <> (sezione 3.6.3), il che evita i loop di notifiche. Questo NDR finisce nella casella dei bounce del vostro dominio, a volte diversi giorni dopo l’invio, nel formato DSN descritto sopra. Per la vostra lista la conseguenza è diretta: un rimbalzo asincrono non compare nel resoconto immediato dell’invio. Si collega all’indirizzo tramite il campo Final-Recipient, poi segue le stesse regole di un rifiuto sincrono: hard bounce, rimozione immediata. Un provider che non legge questa casella di ritorno lascia in circolazione quegli indirizzi e fa salire il tasso di rimbalzo della campagna successiva.

A seconda della configurazione, i domini catch-all producono questo secondo caso: accettano qualsiasi indirizzo durante la sessione SMTP e smistano la posta dopo. Un indirizzo inesistente può allora finire in un NDR differito o sparire senza alcuna risposta. Nessun codice ricevuto durante la sessione permette di prevederlo. Quindi non fissate il tasso di rimbalzo di una campagna prima che sia scaduta la finestra di rinuncia del vostro provider. Trattate inoltre il silenzio di un dominio catch-all come un’informazione incompleta. Le email non consegnate raccolgono questi casi limite, con il modo di smistarli.

Trappole di lettura: il 5xx da conservare e la cache di soppressione

La prima cifra classifica il rimbalzo e non dice nulla sulla validità dell’indirizzo. Le famiglie 5.7.x descritte sopra portano spesso un 5 su contatti validi. Un 5.7.26, ad esempio, significa secondo Google che il messaggio è bloccato per mancanza di autenticazione (SPF o DKIM) o perché la policy DMARC del dominio lo rifiuta. L’indirizzo è valido: a fallire è il vostro dominio. Eliminare questi contatti svuota la lista senza risolvere la causa. Il 4xx vale l’inverso: un 452 4.2.2 ripetuto su tre invii distinti non è più un incidente, e fa uscire l’indirizzo.

Altre due trappole falsano la lettura. La risposta automatica dimostra che il messaggio è arrivato nella casella: non conta come rimbalzo. Classificarla come soft bounce farebbe uscire un contatto attivo. La cache di soppressione gioca in senso opposto: un indirizzo inserito nella lista di soppressione interna del provider non riceve più invii, anche se la casella è stata ricreata nel frattempo. Un contatto che giura di non ricevere nulla pur avendo un indirizzo valido va cercato prima di tutto in questa lista. Lo stesso riflesso vale dopo la correzione di un errore di battitura: il nuovo indirizzo è sconosciuto al provider e passa. Quello vecchio, scritto male, resta in soppressione. Non uscirà mai da un export dei rimbalzi. Confrontate quindi le due righe prima di concludere che un contatto è andato perso.

Regola di rimozione: quanti invii, su quale durata

Per un hard bounce il margine è zero. Klaviyo elimina automaticamente questi profili. Mailchimp ripulisce l’indirizzo dall’audience (pagine di aiuto consultate a ottobre 2026). Le 5.7.x fanno eccezione: riguardano la vostra configurazione. Un errore di battitura alla raccolta si corregge alla fonte, con un double opt-in.

Per un soft bounce applicate quattro regole:

• Contate un rimbalzo per invio. I tentativi di uno stesso provider, distribuiti su più giorni, valgono come uno solo.
• Rimuovete l’indirizzo al 3° soft bounce consecutivo, su invii distinti.
• Consigliamo almeno 14 giorni tra il primo e il terzo rimbalzo, per distinguere una casella fuori uso in modo duraturo da un guasto passeggero presso il destinatario. Questo intervallo è una scelta editoriale: nessuna norma lo impone.
• Azzerate il contatore non appena un invio viene consegnato.

Esempio: un indirizzo in 452 4.2.2 alle campagne del 2 e del 9 ottobre e poi del 23 esce dalla lista il 23. Con tre campagne inviate dal 2 al 4 ottobre resta: tre rimbalzi in 2 giorni dipendono da un unico guasto e l’indirizzo non ha ancora superato i 14 giorni richiesti.

Questa regola di rimozione è una raccomandazione editoriale. I provider pubblicano soglie diverse. MailerLite indica nella sua guida ai bounce che un indirizzo che rimbalza 3 volte di fila viene convertito in hard bounce e diventa inattivo. Mailchimp converte un soft bounce in hard bounce dopo 7 rimbalzi per un indirizzo senza attività di iscritto. Per un contatto con attività precedente il limite sale a 15. L’indirizzo viene poi ripulito (guida ufficiale di Mailchimp, consultata a ottobre 2026). Klaviyo applica una soglia più alta: secondo la sua pagina di aiuto «Suppressed profiles» (aggiornata il 30 marzo 2026), il profilo viene eliminato dopo più di 7 soft bounce consecutivi. Nel conteggio entrano solo quelli degli ultimi 2 anni. Lo stesso indirizzo può quindi sopravvivere a 7 rimbalzi in uno strumento e uscire al 3° nell’altro. Con un provider permissivo, togliete voi stessi l’indirizzo con un segmento di esclusione.

La durata dipende anche dal vostro ritmo di invio. Il conteggio avviene per invio: una campagna settimanale raggiunge il 3° rimbalzo in 3 settimane, una mensile in 3 mesi. Una frequenza troppo bassa ritarda quindi la rimozione: con un invio al mese, un indirizzo morto resta nella lista per un trimestre.

Soglie di bounce: cosa misura ogni percentuale

Le soglie da ricordare sono il 2 % e il 5 % per i rimbalzi, lo 0,3 % per le segnalazioni di spam. Non misurano la stessa cosa.

La prima, il 2 %, è un riferimento del settore per il tasso di rimbalzo (MailerLite). La seconda, il 5 %, è un limite contrattuale: la policy antispam di MailerLite si riserva di sospendere un account e di indagare oltre il 5 % di bounce o lo 0,2 % di segnalazioni.

La terza, lo 0,3 %, viene da Google e riguarda altro: il tasso di spam mostrato in Postmaster Tools, cioè la quota di messaggi che i destinatari segnalano come indesiderati. Dal 1° febbraio 2024 tutti i mittenti verso Gmail devono mantenerlo sotto lo 0,3 %. Google consiglia di restare sotto lo 0,10 %.

Rimbalzo e segnalazione sono due misure distinte: il provider conta le prime, Postmaster Tools le seconde. Una lista può mostrare l’1,5 % di bounce, sotto il 2 %, con lo 0,05 % di spam e non superare nessuna soglia. Esiste anche il caso inverso: 0,4 % di spam con 0,2 % di bounce viola la regola di Google. La soglia del 2 % si applica alla media di una campagna: su 10 000 invii equivale a 200 rimbalzi in totale. Una sola ondata di hard bounce su una lista vecchia basta a superarla. Per riportare un tasso di rimbalzo alto sotto il riferimento del 2 %, vedere la gestione del tasso di rimbalzo.

Bounce, reputazione del mittente e blocklist

Un invio verso una lista vecchia fa emergere dei 5.1.1 nel report della campagna. Ogni 5.1.1 prova che un indirizzo è stato raccolto e poi mai riverificato: il report della campagna fa così l’inventario di ciò che la lista ha perso dalla raccolta. Per leggere la tendenza, confrontate il numero di 5.1.1 per invio su tre campagne consecutive. Una curva in salita segnala una lista che invecchia, una curva piatta un problema puntuale di importazione. Il monitoraggio passa da Postmaster Tools lato Gmail (il tasso di spam vi viene confrontato con il tetto dello 0,3 %) e dal monitoraggio del Sender Score per il punteggio dell’indirizzo IP.

Su un IP nuovo in fase di warm-up ogni 5.1.1 pesa di più: Google chiede di cominciare con destinatari coinvolti, cosa che una lista non ripulita contraddice. Il metodo è descritto in come riscaldare un IP.

Le spam trap (indirizzi esca) si nascondono nelle liste vecchie o acquistate e possono portare alle blocklist. Le trappole di spam e honeypot sono spiegate a parte. Una volta su Spamhaus o su un’altra lista, l’uscita passa da una richiesta al gestore, con la procedura descritta per come rimuovere un IP da una blocklist. La selezione tra blocklist da sorvegliare o ignorare indica quali meritano un allarme.

Cause a monte da trattare già alla raccolta

Le liste acquistate concentrano indirizzi non validi e trappole: il primo invio produce un picco di hard bounce, con un tasso di rimbalzo che supera ogni riferimento. Il double opt-in elimina gli errori di battitura e le email false all’iscrizione. Un nome di dominio scaduto o senza record MX produce un 5.1.2. I rifiuti 5.7.x di autenticazione si risolvono lato SPF, DKIM e DMARC, e la versione DKIM2, in corso di standardizzazione nel gruppo di lavoro DKIM dell’IETF (datatracker.ietf.org, consultato a ottobre 2026), punta a migliorare il valore delle notifiche di mancata consegna. Un contenuto o un oggetto email giudicato sospetto provoca lo stesso tipo di rifiuto per policy, senza che l’indirizzo c’entri.

Domande frequenti sui rimbalzi

Bisogna eliminare un indirizzo dopo un solo soft bounce?

No. Un soft bounce isolato dipende spesso da una casella piena o da un guasto passeggero. Contatelo nella vostra regola: rimozione al 3° rimbalzo consecutivo su invii distribuiti in almeno 14 giorni. Il contatore riparte da zero non appena un messaggio viene consegnato.

Un hard bounce può tornare valido?

Sì, in rari casi: casella ricreata o errore di battitura corretto. Il provider tiene l’indirizzo in soppressione e non riprova più. Toglietelo da quella lista caso per caso, dopo conferma del contatto.

Per quanto tempo un provider riprova un soft bounce?

La RFC 5321 raccomanda almeno 30 minuti tra due tentativi e una durata di rinuncia di almeno 4 o 5 giorni. Ogni provider applica la propria durata: verificatela nella sua documentazione prima di calcolare un tasso di rimbalzo finale.

Verificare la lista prima dell’invio

Filtrare a posteriori equivale a inviare una volta a ogni indirizzo morto: l’hard bounce è già conteggiato nella campagna quando il provider elimina il profilo. La verifica a monte toglie questi indirizzi prima del primo invio. Un verificatore controlla il dominio e l’esistenza della casella: esattamente ciò che il 5.1.1 e il 5.1.2 sanzionano a posteriori. Gli strumenti di verifica delle email sono confrontati in una guida. La manutenzione regolare di un database pulito evita che la lista perda di nuovo ciò che ha guadagnato.

Prima della prossima campagna, passate un campione della lista nello strumento di verifica delle liste email di CaptainVerify e confrontate il risultato con il vostro attuale tasso di hard bounce.