2026 Cloudflare Email Service affiche « Delivered », mais vous n’avez pas reçu l’e-mail ?

Le journal indique « Delivered », mais votre boîte de test est vide.

Verdict — adapté si vous cherchez à localiser un message ; insuffisant pour prouver son arrivée dans la boîte de réception. Avec Cloudflare Email Service, « Delivered » signifie que le serveur de messagerie destinataire a accepté l’e-mail. Vérifiez ensuite le dossier consulté, l’adresse exacte, les suppressions et les en-têtes : le statut ne révèle pas où le fournisseur a classé le message.

Cet article s’adresse aux développeurs, aux ingénieurs QA et aux indépendants qui testent les e-mails de leur propre produit.
Il est particulièrement utile si l’Activity log affiche « Delivered », mais que votre adresse de test ne montre aucun message.

Les quatre résultats à ne pas confondre

Un envoi comporte plusieurs étapes observables. Le service qui traite la demande, le serveur destinataire, le classement du message dans la messagerie et sa lecture par une personne ne constituent pas un seul événement. Si vous les confondez, vous risquez de modifier la configuration d’envoi alors que le message a déjà été accepté par le destinataire.

Cloudflare définit « Delivered » comme l’acceptation du message par le serveur de messagerie destinataire. La documentation précise que cela ne garantit pas une arrivée dans la boîte de réception. Pour confirmer le sens des statuts et les limites du journal, consultez les explications officielles sur le dépannage et la livraison.

Les définitions de statut sont à vérifier dans la documentation Cloudflare sur l’Activity log. Pour votre diagnostic, retenez surtout cette distinction : l’acceptation par le serveur destinataire est une preuve de transport, pas une preuve de classement ni de lecture.

L’Activity log comme point de départ

L’Activity log Cloudflare Email Service permet de rapprocher une ligne d’envoi d’un résultat. Évitez de vous fier à une capture d’écran du tableau de bord sans vérifier qu’elle correspond au bon message : plusieurs essais proches peuvent viser des adresses différentes ou utiliser des données de test similaires.

Avant de modifier quoi que ce soit, relevez les informations disponibles pour l’envoi concerné :

• l’adresse destinataire exacte, y compris les caractères après le signe « + » s’il existe ;
• l’heure et le résultat affichés pour cet envoi ;
• le domaine utilisé pour envoyer le message ;
• le Message-ID, lorsqu’il est disponible dans le journal ou dans les informations d’envoi ;
• les détails d’erreur associés à un refus ou à un échec.

La documentation sur les états et les informations du journal d’activité vous aide à interpréter ce que le service a enregistré. Le Message-ID sert ensuite de clé de rapprochement entre les traces de l’application, le journal et les en-têtes récupérés auprès du destinataire. Si votre application journalise uniquement « e-mail envoyé » sans adresse ni identifiant corrélable, vous aurez peu d’éléments pour isoler l’envoi fautif.

Vérifiez aussi que vous ouvrez le compte, l’environnement et l’adresse prévus. Un test en préproduction peut envoyer vers une boîte différente de celle utilisée en développement ; un alias peut afficher les messages dans un autre dossier ou les transférer ailleurs. La comparaison doit porter sur l’adresse complète réellement passée au code, pas seulement sur le nom affiché dans votre interface.

La vérification des dossiers avant tout changement

Si le statut est « Delivered », commencez par chercher le message dans les dossiers disponibles du compte destinataire. Examinez la boîte de réception, les courriers indésirables, les archives et, si votre environnement en dispose, les quarantaines ou dossiers gérés par une règle. Une recherche par expéditeur, objet ou Message-ID peut être plus efficace qu’un balayage manuel, à condition que l’interface conserve ces éléments.

Vérifiez également les règles automatiques du compte de test. Un filtre peut déplacer ou supprimer un message, tandis qu’un transfert peut l’envoyer vers une autre adresse. Si le compte est partagé au sein de l’équipe, demandez si une autre personne a déplacé le message ; ne supposez pas que l’absence dans la vue principale signifie une absence de livraison.

Pour éviter les faux diagnostics, utilisez un destinataire dont vous contrôlez la consultation et notez son adresse exacte avant de déclencher le test. Si vous comparez plusieurs comptes, consignez séparément le résultat de chaque adresse. Cela aide à distinguer un problème limité à un destinataire d’un problème touchant toute la configuration d’envoi.

Lorsqu’il s’agit d’un code de validation, l’objectif n’est pas seulement de constater un événement « Delivered » : vous devez vérifier que le contenu est lisible, exploitable et associé au bon compte de test. Le guide consacré à la réception et au diagnostic des codes de vérification peut compléter ce contrôle fonctionnel.

Les suppressions et les refus de destinataire

Une adresse peut être concernée par un mécanisme de suppression après un incident antérieur. Dans ce cas, un nouvel essai peut être traité différemment de ce que vous attendez. Examinez la configuration et les informations disponibles dans votre compte autorisé, puis reliez toute suppression à l’adresse précise et au résultat de l’envoi concerné.

La documentation Cloudflare sur la gestion des suppressions explique les mécanismes prévus par le service. Consultez-la avant de changer une option de traitement ou de relancer un envoi. Si le journal mentionne un refus ou un échec, lisez les détails associés plutôt que d’interpréter le statut comme un message simplement « perdu ».

Ne désactivez pas les protections et ne cherchez pas à contourner une suppression comme solution générique. Une suppression peut refléter un problème réel de destinataire ou de traitement ; l’ignorer ne produit pas une preuve fiable de réception et peut introduire de nouveaux échecs dans vos essais. Pour une enquête légitime, utilisez une adresse contrôlée, vérifiez la cause documentée et suivez le comportement attendu de votre configuration.

Enfin, séparez les tests de votre propre produit de toute tentative d’inscription automatisée sur des services tiers. Les essais décrits ici doivent être réalisés dans un environnement que vous administrez ou pour lequel vous avez reçu une autorisation.

L’authentification DNS sans promesse de classement

Les paramètres DNS liés à l’envoi méritent d’être vérifiés si les messages sont refusés ou si les en-têtes indiquent un échec d’authentification. Assurez-vous de consulter la configuration correspondant à Cloudflare Email Service et au domaine d’expédition utilisé par votre application. Ne confondez pas ces réglages avec les enregistrements destinés au routage entrant : ils concernent des usages distincts.

La documentation Cloudflare sur la configuration des domaines pour l’envoi décrit les éléments à contrôler. Comparez les enregistrements publiés avec les valeurs attendues pour le domaine effectivement employé. Si vous venez de modifier le DNS, ne concluez pas à partir d’une seule lecture effectuée dans un autre environnement : vérifiez les données visibles et la configuration rattachée au domaine concerné.

SPF, DKIM et DMARC aident les systèmes destinataires à évaluer l’authenticité et l’alignement d’un message. Un résultat positif est utile, mais il ne garantit pas que le message apparaîtra dans la boîte de réception principale. Le fournisseur destinataire reste responsable de ses filtres, de ses règles locales et de la présentation dans son interface. Par conséquent, un message correctement authentifié peut être classé dans un autre dossier sans que le statut « Delivered » soit erroné.

Cette distinction évite une erreur fréquente : modifier les DNS à chaque message introuvable. Si le serveur destinataire a accepté l’envoi et que les résultats d’authentification sont satisfaisants, l’étape suivante consiste à examiner le classement et les éléments reçus côté destinataire, pas à présumer une panne DNS.

La checklist de diagnostic reproductible

Pour fermer le problème sans mélanger les preuves, reprenez les étapes suivantes dans l’ordre. Effectuez-les uniquement sur votre produit ou dans un environnement de test autorisé.

1. Choisissez une adresse contrôlée. Vérifiez que vous pouvez ouvrir la boîte correspondante et que vous consultez le bon compte. Notez l’adresse complète attendue par l’application.
2. Déclenchez un message identifiable. Utilisez un objet ou un contenu de test distinctif, sans données personnelles réelles. Conservez l’heure de déclenchement et l’identifiant de l’utilisateur de test.
3. Reliez l’envoi à l’application. Enregistrez le destinataire transmis, le domaine d’expédition et le Message-ID lorsqu’il est accessible. Évitez de journaliser le corps complet si celui-ci contient des informations sensibles.
4. Retrouvez la ligne correspondante dans l’Activity log. Confirmez l’adresse, l’heure, le résultat et les détails disponibles. Une entrée voisine ne suffit pas à prouver le résultat de votre essai.
5. Traitez le statut selon sa signification. Pour « Rejected », « Delivery failed » ou « Failed », examinez l’explication et la configuration concernée. Pour « Delivered », poursuivez vers les vérifications côté destinataire au lieu de conclure que l’e-mail est dans la boîte principale.
6. Inspectez les dossiers et les règles. Recherchez le message dans la boîte principale, les indésirables, les archives et les éventuelles quarantaines. Vérifiez les filtres et transferts qui pourraient le déplacer.
7. Contrôlez les suppressions et l’authentification. Consultez les informations relatives à l’adresse dans votre configuration autorisée, puis vérifiez les enregistrements du domaine d’envoi. Ne contournez pas les protections pour obtenir artificiellement un résultat positif.
8. Récupérez les en-têtes si le message est accessible. Relevez le Message-ID et les résultats Authentication-Results, puis comparez-les aux traces de votre application et au journal Cloudflare.
9. Rejouez l’essai et consignez les preuves séparément. Notez le statut d’envoi, la preuve d’acceptation par le destinataire et le résultat de lecture dans la boîte. Ces observations ne doivent pas être résumées par un seul « succès ».

Ce déroulé est aussi utile pour les tests automatisés : l’assertion ne devrait pas se limiter à l’absence d’erreur retournée par l’application. Elle doit, selon votre objectif, vérifier que l’envoi a été enregistré, qu’un destinataire contrôlé peut retrouver le message et que le contenu nécessaire au scénario est présent. Si votre test ne peut pas accéder aux en-têtes ou à une boîte lisible, indiquez clairement cette limite au lieu de présenter le statut Cloudflare comme une validation de bout en bout.

Les en-têtes comme preuve supplémentaire

Quand vous avez accès au message, les en-têtes fournissent des éléments plus précis que la seule ligne « Delivered ». Recherchez le Message-ID pour établir le lien avec les journaux de votre application, puis lisez Authentication-Results pour voir les résultats annoncés par le système destinataire. Le contenu des en-têtes dépend du message et du fournisseur ; ne déduisez pas une cause à partir d’un champ isolé.

La documentation Cloudflare de dépannage rappelle que le statut de livraison ne renseigne pas sur le dossier final. Les en-têtes peuvent aider à analyser le chemin et l’authentification, mais ils ne remplacent pas la vérification de l’interface et des règles du compte. Si le message est introuvable, demandez au responsable de la boîte contrôlée s’il peut fournir les informations complètes associées à une copie reçue ou mise en quarantaine.

Pour les essais qui portent sur des notifications, des aperçus de créations audio ou vidéo, ou des messages déclenchés par un outil de conception, vérifiez aussi le rendu du contenu dans une boîte réellement consultable. Un statut de transport ne valide ni les liens, ni les pièces jointes, ni la mise en page, ni l’expérience de la personne qui reçoit le message.

Cette collecte doit respecter le principe de minimisation des données. Employez des comptes de test et un contenu synthétique ; évitez d’insérer dans les journaux des noms, adresses ou détails de compte réels qui ne sont pas nécessaires au diagnostic. Les règles d’utilisation des données pour les tests donnent un cadre complémentaire pour limiter les données exposées dans vos scénarios.

Questions fréquentes

« Delivered » confirme-t-il l’arrivée dans la boîte de réception ?

Non. Le statut confirme l’acceptation par le serveur de messagerie destinataire, pas le dossier où le message est rangé ni sa lecture. Vérifiez les dossiers de courrier indésirable, d’archives et de quarantaine, puis récupérez les en-têtes complets si le message est accessible. Si vous ne disposez que du journal Cloudflare, vous n’avez pas encore de preuve de classement dans l’interface.

Que faire si l’Activity log affiche « Delivered », mais que le message de test est introuvable ?

Confirmez d’abord que vous consultez l’adresse exacte utilisée pour cet envoi et la bonne ligne du journal. Cherchez ensuite dans les dossiers secondaires et vérifiez les règles de déplacement ou de transfert. Si le message reste introuvable, rapprochez le Message-ID des journaux de l’application et demandez les éléments disponibles au responsable de la boîte de test.

Comment vérifier si une adresse est supprimée ?

Consultez la configuration des suppressions de votre domaine et les informations auxquelles votre compte autorisé permet d’accéder. Rapprochez l’adresse exacte du statut et des détails de l’envoi concerné. Si une suppression est en cause, enquêtez sur son origine et suivez la procédure documentée ; ne désactivez pas une protection pour forcer un nouvel envoi.

Comment localiser un message retrouvé dans les indésirables ?

Conservez le message et examinez ses en-têtes, notamment le Message-ID et Authentication-Results. Vérifiez les résultats SPF, DKIM et DMARC ainsi que les DNS associés au domaine d’envoi, sans les confondre avec le routage entrant. Même si l’authentification réussit, le fournisseur peut classer le message ailleurs : cela ne signifie pas que « Delivered » garantit la boîte principale.

Pour valider la réception réelle

Si votre dernier contrôle porte sur la lecture effective d’un message, choisissez une boîte de test que vous pouvez consulter et consignez séparément l’état du journal, l’acceptation par le destinataire et la présence du contenu. Emailbye peut constituer une option de réception temporaire lorsque les capacités actuellement proposées correspondent à votre scénario ; vérifiez-les avant de l’intégrer à un test. Pour un compte bancaire, administratif ou de paiement, ou pour toute adresse qui doit rester joignable et recevoir des réponses, préférez une boîte durable que vous contrôlez.

Questions fréquentes

Le statut « Delivered » signifie-t-il que l’e-mail est dans la boîte de réception ?

Non. Dans Cloudflare Email Service, « Delivered » signifie que le serveur de messagerie destinataire a accepté le message. Ce statut ne confirme ni son classement dans la boîte de réception principale, ni sa visibilité dans l’interface que vous consultez. Vérifiez les autres dossiers, puis demandez les en-têtes complets au fournisseur destinataire pour poursuivre l’analyse.

Que vérifier si le journal affiche « Delivered », mais que le message de test reste introuvable ?

Commencez par confirmer l’adresse exacte et la ligne d’envoi correspondante dans l’Activity log. Recherchez ensuite le message dans les dossiers de courrier indésirable, d’archives et de quarantaine, selon les options du fournisseur. Si vous ne le trouvez toujours pas, reliez le Message-ID aux journaux de votre application et examinez les en-têtes disponibles.

Comment savoir si une adresse de test est supprimée dans Cloudflare Email Service ?

Vérifiez la configuration des suppressions associée à votre domaine et recherchez l’adresse concernée dans les informations auxquelles votre compte autorisé vous donne accès. Consultez aussi le résultat de l’envoi et les éventuels détails de refus. Ne désactivez pas la protection pour contourner une suppression : identifiez d’abord la cause et testez avec une adresse contrôlée.

Comment analyser un e-mail Cloudflare trouvé dans le courrier indésirable ?

Conservez le message et ses en-têtes complets, puis examinez les résultats Authentication-Results, notamment pour SPF, DKIM et DMARC. Confirmez que les enregistrements DNS consultés concernent l’envoi et non le routage entrant. Une authentification réussie est un élément de diagnostic, pas une garantie de classement dans la boîte principale.