Statuts des e-mails

Chaque e-mail a un statut qui indique où il en est dans son cycle de vie. Cette page liste les 14 statuts, la façon dont un e-mail passe de l’un à l’autre et ce qu’il faut faire quand un e-mail s’arrête là où vous ne l’attendiez pas. Le statut ne reflète que le dernier état ; l’historique complet se trouve sur la page de détail de l’e-mail et dans les événements.

Référence des statuts

« Définitif » signifie qu’Emailit ne modifiera plus le statut de lui-même. Un e-mail au statut définitif peut tout de même être relancé, ce qui crée un nouvel e-mail avec un nouvel ID.

Les webhooks reçoivent email.canceled et email.held lorsqu’ils sont abonnés à tous les événements, ou lorsque vous ajoutez ces événements à la liste d’événements du webhook avec l’API. Consultez Types d’événements.

Cycle de vie

La plupart des e-mails suivent ce parcours :

1. Création. Un envoi par l’API crée l’e-mail avec le statut accepted, ou scheduled quand scheduled_at est dans le futur. Les envois SMTP commencent aussi à accepted. Les e-mails entrants sont créés avec le statut received, qui ne change jamais.
2. Contrôle. Avant chaque tentative de livraison, Emailit contrôle l’espace de travail, le domaine, la clé API, les crédits, la liste d’adresses bloquées et le score de spam. Un contrôle en échec termine l’e-mail en held, rejected ou suppressed sans l’envoyer.
3. Livraison ou report. La tentative de livraison réussit (delivered), échoue temporairement (attempted, puis nouvelle tentative) ou échoue définitivement (bounced).
4. Engagement. Si le suivi est activé, les ouvertures et les clics font passer un e-mail livré à loaded, puis à clicked.
5. Rapports tardifs. Un rapport de rebond qui arrive après la livraison fait passer le statut à bounced. Une plainte pour spam le fait passer à complained.

À tout moment avant la livraison, un e-mail scheduled, accepted ou attempted peut passer à canceled.

L’échelle d’engagement

Les statuts de livraison et d’engagement ne font qu’avancer :

accepted, scheduled ou attempted → delivered → loaded → clicked

Un événement ultérieur ne fait jamais redescendre un e-mail sur cette échelle. Si un clic est enregistré, l’e-mail reste clicked même si d’autres ouvertures arrivent. Une ouverture ou un clic peut sauter l’étape delivered, car il prouve que le message est arrivé. Les statuts qui mettent fin à la livraison (bounced, failed, rejected, suppressed, complained et canceled) ne sont jamais remplacés par des ouvertures ou des clics.

Calendrier des nouvelles tentatives pour attempted

Quand un serveur destinataire répond par une erreur temporaire (une réponse 4xx comme 421 ou 451, un timeout ou une erreur de connexion), l’e-mail passe à attempted et Emailit réessaie. Chaque attente dure deux fois plus longtemps que la précédente :

Cela fait 7 tentatives de livraison sur environ 21 heures. Une fois qu’elles sont épuisées, l’e-mail est marqué bounced avec « Maximum number of delivery attempts (7) has been reached », et le destinataire est ajouté aux adresses bloquées avec la raison too many soft fails, sauf si vos paramètres de blocage automatique excluent les rebonds.

Chaque tentative figure dans l’onglet Deliveries de l’e-mail avec la réponse du serveur, et chacune envoie un événement email.attempted qui contient smtp_code, smtp_enhanced_code et smtp_response. Certaines réponses temporaires qui signalent clairement un problème définitif, comme une boîte aux lettres désactivée, sont traitées immédiatement comme des rebonds. Quand un fournisseur limite le débit, Emailit peut aussi suspendre brièvement la livraison vers celui-ci ; ces lignes indiquent « Delivery delayed due to… ».

Pourquoi un e-mail est retenu

Un e-mail retenu a été retiré de la file d’envoi sans être envoyé. L’onglet Deliveries de l’e-mail indique la raison qui s’applique :

Les e-mails retenus ne sont pas libérés automatiquement. Après avoir corrigé la cause, sélectionnez Retry sur l’e-mail, ou appelez Relancer un e-mail. La relance crée un nouvel e-mail avec le même contenu et débite de nouveau des crédits.

Pourquoi un e-mail est rejeté

Tant que votre espace de travail n’a pas l’accès production, vous ne pouvez envoyer qu’aux adresses e-mail des comptes des membres de l’espace de travail. Pour les autres destinataires, l’API renvoie 403 et SMTP renvoie 550 au moment de l’envoi : la plupart du temps, vous voyez donc l’erreur plutôt qu’un e-mail. Le statut rejected apparaît quand le même contrôle échoue plus tard, au moment de la livraison, par exemple pour un e-mail programmé auparavant. L’onglet Deliveries affiche « Unverified workspaces can only send to workspace members’ account emails » et l’adresse bloquée.

Règles de relance

Pour un e-mail bloqué, retirez d’abord l’adresse de votre liste d’adresses bloquées, sinon la relance est de nouveau bloquée.

Voir aussi