Récupération · Gestion des bounces
Guide de gestion des bounces email
Les bounces font partie de l’email transactionnel. Votre façon de les classifier, les supprimer et les récupérer détermine si votre réputation d’envoi tient à fort volume.
UI produit représentative — données illustratives, pas de métriques client live.
Plan de contrôle
Comment Sendarix classe, supprime et route selon les signaux de bounce
Les événements de bounce alimentent les décisions de routing et la suppression par tenant, pas seulement une blocklist statique. Les hard bounces sont supprimés immédiatement; les soft bounces suivent votre politique de retry avant escalade.
L’isolation par tenant empêche la mauvaise liste d’un client d’affecter les autres. Les événements webhook (bounce, soft_bounce, complaint) donnent à votre application les détails nécessaires pour mettre à jour le CRM et déclencher les flux de récupération. Voir email routing pour configurer les règles.
| Chemin relay | Signal | Statut |
|---|---|---|
| Transactionnel UE | Entrega estable | sain |
| Bulk US | Deferrals bajos | sain |
| Dedicated tenant | Deferrals elevados | dégradé |
UI produit représentative — données illustratives, pas de métriques client live.
Hard bounce vs soft bounce - classification
Tous les bounces ne se valent pas. Le code de réponse du serveur destinataire indique si l’échec est permanent ou temporaire, et votre système doit traiter chaque cas différemment.
Hard bounce
Échec de livraison permanent. La boîte n’existe pas, le domaine est invalide ou le destinataire a rejeté définitivement les emails de votre domaine.
Codes de réponse :550 Mailbox unavailable, 550 User unknown, 550 No such recipient
Action requise : Ajouter immédiatement à la liste globale de suppression. Ne plus envoyer à cette adresse.
Soft bounce
Échec de livraison temporaire. La boîte est pleine, le serveur est temporairement indisponible ou il existe un problème de connexion.
Codes de réponse :450 Mailbox full, 421 Service temporarily unavailable, 451 Server busy
Action requise : Réessayer avec backoff exponentiel. Convertir en hard bounce après N échecs consécutifs.
Stratégie de retry et backoff
Les soft bounces doivent être réessayés, mais pas immédiatement ni indéfiniment. Un planning structuré évite de marteler des serveurs déjà dégradés.
| Timing | Action |
|---|---|
| Immédiat | Première tentative au moment de l’envoi |
| +15 min | Premier retry - erreur serveur ou réseau |
| +1 heure | Deuxième retry |
| +4 heures | Troisième retry |
| +12 heures | Quatrième retry |
| Abandon | Après 5 échecs consécutifs, convertir en hard bounce et supprimer |
Gestion des listes de suppression
La liste de suppression est votre défense principale contre l’envoi vers des adresses qui ne peuvent pas recevoir d’email.
Hard bounces
Permanent. Ne jamais retenter la livraison. Stocker définitivement avec horodatage.
Plaintes (FBL)
L’utilisateur a marqué comme spam. Suppression long terme avec date de plainte.
Demandes de désabonnement
À supprimer immédiatement selon les exigences CAN-SPAM et RGPD.
Échecs transitoires
Ne pas supprimer pendant la fenêtre de retry. Supprimer seulement après dépassement du maximum de retries.
Pour les plateformes SaaS multi-tenant, les listes de suppression doivent être isolées par tenant. Voir tenant isolation pour les limites de suppression par domaine.
Suivi des événements webhook pour les bounces
Les événements de bounce livrés via email webhooks fournissent le plus de détails. Suivez ces types d’événement :
bounce— hard bounce. Supprimer immédiatement le destinataire.soft_bounce— échec temporaire. Planifier un retry selon votre politique de backoff.complaint— le destinataire a marqué comme spam. Suppression long terme.delivery— confirme l’acceptation par le serveur destinataire.reject— serveur refusé avant mise en file. Vérifier les enregistrements SPF/DKIM/DMARC.
Sendarix classe automatiquement les bounces
Les événements de bounce sont suivis par message, classés hard ou soft, et les listes de suppression sont mises à jour automatiquement. Les plannings de retry et la logique de failover sont configurables via l’API email routing.
