Recovery · Gestione bounce

Guida alla gestione dei bounce email

I bounce fanno parte dell’email transazionale. Il modo in cui li classifichi, sopprimi e recuperi determina se la tua reputazione di invio regge a volumi elevati.

events · ciclo de vida del mensaje · msg_01HF2K…
03:14:02 accettato api · idempotency_key=otp_8842
03:14:02 in coda pool=transactional-critical
03:14:03 inviato relay=eu-primary
03:14:051 deferred 421 limitato · eu-primary
03:14:06 reroutato policy=failover → us-relay
03:14:07 consegnato inbox

UI prodotto rappresentativa — dati illustrativi, non metriche live dei clienti.

Piano di controllo

Come Sendarix classifica, sopprime e instrada in base ai segnali di bounce

Gli eventi di bounce alimentano decisioni di routing e soppressione per tenant, non solo una blocklist statica. Gli hard bounce vengono soppressi subito; i soft bounce seguono la tua policy di retry prima dell’escalation.

L’isolamento per tenant impedisce che la lista errata di un cliente impatti gli altri. Gli eventi webhook (bounce, soft_bounce, complaint) danno all’applicazione i dettagli per aggiornare il CRM e attivare flussi di recovery. Consulta email routing per configurare le policy.

deliverability · salute relay · 24h
Percorso relaySegnaleStato
Transazionale UEEntrega establesano
Bulk USADeferrals bajossano
Dedicated tenantDeferrals elevadosdegradato

UI prodotto rappresentativa — dati illustrativi, non metriche live dei clienti.

Hard bounce vs soft bounce - classificazione

Non tutti i bounce sono uguali. Il codice di risposta del server ricevente indica se il problema è permanente o temporaneo, e il sistema deve gestire i casi in modo diverso.

Hard bounce

Errore di consegna permanente. La mailbox non esiste, il dominio non è valido o il destinatario ha rifiutato permanentemente le email dal tuo dominio.

Codici di risposta:
550 Mailbox unavailable, 550 User unknown, 550 No such recipient

Azione richiesta: Aggiungi subito alla lista globale di soppressione. Non inviare più a questo indirizzo.

Soft bounce

Errore di consegna temporaneo. La mailbox è piena, il server è temporaneamente non disponibile o c’è un problema di connessione.

Codici di risposta:
450 Mailbox full, 421 Service temporarily unavailable, 451 Server busy

Azione richiesta: Riprova con backoff esponenziale. Converti in hard bounce dopo N errori consecutivi.

Strategia di retry e backoff

I soft bounce devono essere ritentati, ma non subito e non all’infinito. Una schedulazione strutturata evita di sovraccaricare server già degradati.

TimingAzione
ImmediatoPrimo tentativo al momento dell’invio
+15 minPrimo retry - errore server o rete
+1 oraSecondo retry
+4 oreTerzo retry
+12 oreQuarto retry
ScartaDopo 5 errori consecutivi, converti in hard bounce e sopprimi

Gestione delle liste di soppressione

La lista di soppressione è la difesa primaria contro l’invio ad indirizzi che non possono ricevere email.

Hard bounce

Permanente. Non tentare la riconsegna. Salvato definitivamente con timestamp.

Reclami (FBL)

Utente ha segnato come spam. Soppressione a lungo termine con data del reclamo.

Richieste di disiscrizione

Da sopprimere immediatamente secondo i requisiti CAN-SPAM e GDPR.

Errori transitori

Non sopprimere durante la finestra di retry. Sopprimere solo dopo il superamento dei retry massimi.

Per piattaforme SaaS multi-tenant, le liste di soppressione devono essere isolate per tenant. Vedi tenant isolation per i confini di soppressione per dominio.

Tracciamento eventi webhook per i bounce

Gli eventi di bounce inviati tramite email webhooks forniscono il massimo dettaglio. Traccia questi tipi di evento:

  • bounce — hard bounce. Sopprimi subito il destinatario.
  • soft_bounce — errore temporaneo. Pianifica il retry secondo la policy di backoff.
  • complaint — destinatario ha segnato come spam. Soppressione a lungo termine.
  • delivery — conferma l’accettazione dal server ricevente.
  • reject — server rifiutato prima della coda. Verifica record SPF/DKIM/DMARC.

Sendarix gestisce automaticamente la classificazione dei bounce

Gli eventi di bounce sono tracciati per messaggio, classificati come hard o soft, e le liste di soppressione vengono aggiornate automaticamente. Le schedulazioni di retry e la logica di failover sono configurabili tramite l’API email routing.