Vous mettez des collègues en CC et l’adresse principale renvoie « Undelivered Mail Returned to Sender » ? Voici l’explication SMTP claire, les cas limites, et quoi faire pour vérifier ou corriger la remise.
Vue d’ensemble de la question
Un utilisateur envoie un message à un collègue (champ À) et place d’autres contacts en CC. Le serveur renvoie une notification d’échec pour l’adresse principale. Faut‑il en conclure que personne n’a reçu le courriel ? Non : en SMTP, chaque destinataire est traité séparément. Entrons dans le détail.
Réponse courte et actionnable
- Distribution indépendante : le serveur expéditeur tente la remise pour chaque adresse figurant en À, CC et BCC. Un échec sur une adresse (faute de frappe, quota plein, domaine introuvable) n’interrompt pas la livraison aux autres. Les personnes en CC reçoivent donc normalement le message.
- Lecture des notifications d’échec (DSN/NDR) : la notification liste uniquement les destinataires en échec. L’absence d’un nom signifie que le serveur destinataire a accepté le message (sans garantir l’arrivée en boîte de réception : filtrage antispam ou règles locales peuvent s’appliquer).
- Vérification : utilisez les accusés de réception/lecture (quand disponibles), la journalisation serveur (Message Trace, Email Log Search), ou demandez les en‑têtes complets au destinataire pour confirmer la route suivie.
Comment fonctionne la remise côté SMTP
À l’envoi, le client de messagerie remet votre message à un serveur sortant (MTA) qui dialogue en SMTP avec les serveurs des domaines des destinataires. Deux choses coexistent :
- L’enveloppe SMTP (les vraies adresses de remise, transmises via
RCPT TO:), - Les en‑têtes visibles (
To:,Cc:,Bcc:n’apparaissant pas toujours).
Le MTA regroupe les destinataires par domaine et tente la remise à chacun :
MAIL FROM:<vous@exemple.fr>
RCPT TO:<principal@domaineA.fr> 550 5.1.1 User unknown
RCPT TO:<copie1@domaineB.com> 250 2.1.5 Ok
RCPT TO:<copie2@domaineB.com> 250 2.1.5 Ok
DATA ... 250 2.0.0 Accepted
Ici, l’adresse principale échoue (utilisateur inconnu), mais les deux adresses en CC (même domaine B) sont acceptées et recevront le message.
Cas d’échec qui n’affectent pas les autres destinataires
- Utilisateur inconnu (
5.1.1) pour un seul destinataire. - Boîte pleine (
5.2.2) sur une adresse, les autres passent. - Domaine spécifique temporairement indisponible (
4.x.x) : retard pour ce domaine seulement. - Erreur de syntaxe sur une adresse (
5.1.3), les autres valides sont traitées.
Cas où plusieurs adresses peuvent échouer ensemble
- Rejet « par politique » après DATA (
5.7.1, contenu/expéditeur bloqué) sur une même session SMTP : toutes les adresses traitées dans cette transaction peuvent être refusées en bloc par le serveur destinataire du domaine concerné. - Blocage d’IP (liste noire, réputation) : le destinataire rejette le message pour toutes les adresses de ce domaine lors de cette session.
- Message trop volumineux (limite de taille côté domaine destinataire) : toutes les adresses de ce domaine peuvent échouer ensemble.
Ces situations n’ont rien à voir avec la notion de « destinataire principal » : elles découlent de décisions prises par le serveur du domaine destinataire.
DSN/NDR : bien interpréter les notifications d’échec
La notification d’état de distribution (DSN ou NDR) contient des champs standard :
- Final-Recipient : adresse en échec,
- Action : failed, delayed, delivered,
- Status : code étendu (
2.x.x,4.x.x,5.x.x), - Diagnostic-Code : message du serveur destinataire.
Subject: Delivery Status Notification (Failure)
Final-Recipient: rfc822; principal@domaineA.fr
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown
Elle ne cite que les adresses problématiques. Les destinataires acceptés n’y figurent pas.
Table des codes DSN (résumé)
| Classe | Signification | Que faire |
|---|---|---|
| 2.x.x | Succès (accepté côté serveur) | Aucune action ; attention, le tri antispam local peut encore déplacer le message. |
| 4.x.x | Échec temporaire (retentatives) | Attendre ou réduire la taille/adapter le contenu. Le MTA retentera avant un NDR final. |
| 5.x.x | Échec permanent | Corriger l’adresse, contacter l’admin, revoir l’authentification d’envoi (SPF/DKIM/DMARC), le contenu ou la taille. |
Codes fréquents et explications
| Code | Cause typique | Actions concrètes |
|---|---|---|
| 5.1.1 | Utilisateur inconnu | Vérifier l’orthographe, demander la bonne adresse, supprimer l’autocomplétion obsolète. |
| 5.2.2 | Boîte pleine | Prévenir le destinataire par autre canal ; renvoyer plus tard. |
| 5.4.4 | Domaine introuvable/expiré | Confirmer le domaine, corriger le MX/DNS côté destinataire. |
| 5.7.1 | Rejet de politique (authentification, réputation, contenu) | Activer SPF/DKIM/DMARC, assainir la réputation, simplifier les pièces jointes/liens. |
| 4.4.1 | Timeout temporaire | Patienter ; si récurrent, voir la connectivité/délivrabilité. |
Comment vérifier la remise aux personnes en CC
Accusés de réception et de lecture
- Outlook (Windows/Mac) : lors de la rédaction, onglet Options ➜ cochez Demander un accusé de réception (confirmation côté serveur) et/ou Demander un accusé de lecture (ouverture côté client). Par défaut, la demande de lecture peut être refusée par le destinataire.
- Outlook sur le Web : … (plus d’options) ➜ Suivi ➜ cochez les options de suivi souhaitées.
- Gmail (comptes Google Workspace) : au moment de composer, menu Plus d’options ➜ Demander une confirmation de lecture. (Non disponible sur tous les types de comptes.)
Limites : les confirmations de lecture reposent sur le client du destinataire ; elles ne sont ni universelles ni garanties. Un accusé de réception côté serveur est en revanche un bon indicateur d’acceptation par le système distant.
Journalisation serveur (contexte entreprise)
- Exchange Online / Microsoft 365 : dans le Centre d’administration Exchange (EAC), utilisez Suivi des messages (Message Trace) pour rechercher votre envoi (heure, expéditeur, sujet) et visualiser le statut par destinataire : Delivered, Expanded (pour une liste), Quarantined, Failed, etc.
- Google Workspace : dans la console d’administration, ouvrez l’outil Recherche dans les journaux d’e‑mail (Email Log Search) pour vérifier l’acheminement des messages, les éventuels rebonds, délais ou quarantaines par destinataire.
Pas d’accès admin ? Demandez au destinataire en CC d’ouvrir le message et de vous transmettre les en‑têtes complets. Vous pourrez y lire Received:, Delivered-To:, Return-Path:, ce qui suffit souvent à prouver la remise.
Bonnes pratiques pour éviter les faux diagnostics
- Valider les adresses avant l’envoi : utilisez le carnet d’adresses à jour, supprimez les entrées d’autocomplétion obsolètes, privilégiez les Groupes ou Listes de distribution gérés par l’organisation.
- Séparer les envois critiques : si le message est essentiel, envoyez une version dédiée aux personnes clés (ou utilisez en parallèle Teams/Chat/Téléphone) pour réduire le risque opérationnel.
- Authentifier votre domaine : SPF, DKIM, DMARC correctement configurés augmentent l’acceptation et réduisent les rejets de politique (
5.7.1). - Soigner le contenu : évitez les liens raccourcis excessifs, les mises en page trop « marketing » sur des messages transactionnels, et limitez les pièces jointes volumineuses (privilégiez un partage sécurisé).
- Surveiller l’antispam : informez les destinataires réguliers d’ajouter votre adresse ou domaine à la liste des expéditeurs approuvés si vos mails se perdent.
Scénarios particuliers à connaître
Le cas du BCC
Les destinataires en BCC (copie cachée) n’apparaissent pas dans les en‑têtes visibles ; ils sont traités par l’enveloppe SMTP comme n’importe quel destinataire. Un échec sur l’adresse principale n’empêche pas la remise aux BCC. Les DSN peuvent, selon les systèmes, ne pas révéler explicitement qu’un BCC a échoué (question de confidentialité).
Listes de distribution et groupes
- Listes (Exchange DL, Google Group, Microsoft 365 Group) : vous ne voyez qu’une seule adresse de liste ; c’est le serveur de la liste qui se charge de la diffusion interne. Les rebonds des membres peuvent être gérés en coulisse (par exemple, suppression temporaire d’un membre en échec) et ne pas vous être renvoyés.
- Échec sur la liste elle‑même : si l’adresse de la liste est invalide ou si la politique du groupe rejette votre message, personne dans la liste ne reçoit le courriel.
Alias et redirections
Si un destinataire en CC utilise un alias ou une redirection, le message est d’abord accepté par sa boîte, puis routé ailleurs. Un échec peut survenir après l’acceptation initiale (par exemple, destination finale invalide) : vous ne verrez pas toujours un NDR vous revenir car l’erreur apparaît au second saut.
Quarantaine et dossiers de courrier indésirable
Un message accepté peut être placé en quarantaine ou dans Courrier indésirable. D’où l’intérêt de distinguer acceptation SMTP (preuve de remise au système) et distribution locale (boîte de réception, autre dossier, quarantaines).
Guide de dépannage rapide
| Symptôme | Interprétation | Action immédiate |
|---|---|---|
| NDR mentionne seulement l’adresse principale | Les CC ont probablement été acceptés | Demander un accusé de réception/lecture, ou vérifier via Message Trace/Email Log Search |
| Plusieurs CC du même domaine n’ont rien reçu | Rejet de politique ou limite de taille au niveau du domaine | Tester un envoi texte léger, vérifier SPF/DKIM/DMARC et la taille des pièces jointes |
| Un seul CC n’a pas reçu | Problème local (quota, règle, antispam, alias) | Demander les en‑têtes complets, vérifier le dossier Indésirables et les règles côté client |
| Le NDR parle de « User unknown » (5.1.1) | Adresse invalide/obsolète | Corriger l’adresse, effacer l’autocomplétion et renvoyer |
| Le NDR parle de « Message too large » | Limite de taille dépassée | Compresser, utiliser un lien de partage sécurisé, renvoyer |
Procédures concrètes par plateforme
Outlook (expéditeur)
- Rédigez votre message, allez dans Options.
- Cochez Demander un accusé de réception et/ou Demander un accusé de lecture.
- Envoyez, puis surveillez les notifications de suivi qui s’affichent ensuite dans votre boîte de réception.
- Si un CC dit ne pas avoir reçu, demandez‑lui d’ouvrir l’e‑mail (s’il le retrouve) et de vous envoyer les en‑têtes complets (Fichier ➜ Propriétés ➜ En‑têtes Internet sous Outlook pour Windows).
Exchange Online – Message Trace (administrateur)
- Ouvrez le Centre d’administration Exchange.
- Section Flux de messagerie ➜ Suivi des messages.
- Filtrez par expéditeur, intervalle temporel et, si possible, sujet.
- Inspectez chaque destinataire : Delivered, Expanded (liste), Failed, Quarantined, FilteredAsSpam, etc.
- Téléchargez le rapport détaillé pour obtenir la chronologie SMTP et les codes exacts.
Google Workspace – Recherche dans les journaux d’e‑mail (administrateur)
- Accédez à la console d’administration.
- Ouvrez Recherche dans les journaux d’e‑mail.
- Recherchez par expéditeur/sujet/plage horaire.
- Consultez l’état par destinataire : Delivered, Spam, Rejected, Quarantined, délais, etc.
Exemples concrets
Exemple A : rebond sur l’adresse principale, CC livrés
Final-Recipient: rfc822; principal@domaineA.fr
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown
À retenir : si copie1@domaineB.com et copie2@domaineB.com ne sont pas mentionnés, ils ont été acceptés.
Exemple B : rejet de politique pour tout un domaine
Final-Recipient: rfc822; copie1@domaineB.com
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp; 550 5.7.1 Message rejected by policy
...
Final-Recipient: rfc822; copie2@domaineB.com
Action: failed
Status: 5.7.1
À retenir : vos CC d’un même domaine peuvent tous échouer si la politique du destinataire bloque le message après l’analyse du contenu.
Erreurs fréquentes à éviter
- Confondre en‑têtes et enveloppe SMTP : voir une adresse en À ou CC dans l’e‑mail ne garantit pas qu’elle a été utilisée pour la remise si le MTA a réécrit ou supprimé des destinataires (politiques d’acheminement).
- Supposer que l’acceptation = boîte de réception : un message accepté peut finir en Indésirables ou Quarantaine.
- Ignorer la taille : beaucoup de domaines imposent des limites strictes sur les pièces jointes. Préférez un partage sécurisé quand le fichier est lourd.
- Négliger l’authentification : sans SPF/DKIM/DMARC, vos envois peuvent être rétrogradés ou rejetés.
Checklist express
- Lire la DSN : quels destinataires sont listés ? quel code ?
- Tester un envoi minimal : texte simple, sans pièces jointes.
- Vérifier l’authentification : SPF/DKIM/DMARC actifs.
- Demander un accusé de réception pour les essais.
- Tracer le message via l’outil d’admin si disponible.
- Demander les en‑têtes complets aux CC quand ils disent « rien reçu ».
FAQ
Les CC reçoivent‑ils l’e‑mail si l’adresse en À est invalide ?
Oui, car chaque destinataire est traité individuellement. L’échec d’un destinataire ne bloque pas les autres.
Pourquoi je reçois plusieurs DSN pour un seul message ?
Parce que chaque adresse peut échouer pour une raison différente et à un moment différent. Les NDR sont émis par les serveurs qui détectent l’échec.
Un accusé de lecture prouve‑t‑il la réception ?
Non : il prouve l’ouverture sur le poste du destinataire (s’il l’autorise). L’accusé de réception côté serveur est un meilleur indicateur de remise.
Et si j’ai mis des BCC ?
Ils sont traités comme des destinataires normaux côté enveloppe SMTP. Un échec de l’adresse principale ne les empêche pas d’être livrés.
Pourquoi le CC dit ne rien avoir reçu alors que la DSN ne le cite pas ?
Le message peut avoir été accepté puis filtré (Indésirables, Quarantaine) ou redirigé par une règle. Les en‑têtes complets et le suivi serveur aideront à trancher.
Conclusion
En résumé : le modèle SMTP distribue les messages par destinataire. Un rebond sur l’adresse principale n’annule pas la remise aux contacts en CC. La DSN énumère seulement les adresses en échec ; son silence au sujet d’un CC indique en général que le message a été accepté par son serveur. Pour confirmer, combinez accusés, journaux d’acheminement et en‑têtes complets, et appliquez les bonnes pratiques (authentification, contenu sobre, adresses à jour). C’est la voie la plus sûre pour éviter les malentendus… et les messages perdus.
Annexe : mémo DSN/SMTP
| Élément | Utilité | Exemple |
|---|---|---|
| Final-Recipient | Indique l’adresse qui a échoué | rfc822; utilisateur@domaine.fr |
| Action | Statut de l’opération | failed, delayed, delivered |
| Status | Code étendu normalisé | 5.1.1, 4.4.1, 2.0.0 |
| Diagnostic-Code | Détail du serveur destinataire | smtp; 550 5.1.1 User unknown |
| Received | Trace chaque saut | from mail.exemple.fr by mx.domaine.fr with ESMTPS |
Astuce : quand vous analysez une DSN, identifiez d’abord le code Status (classe 2/4/5), puis l’étape (RCPT vs DATA), et enfin la portée (un destinataire vs tout un domaine). Cette grille explique la quasi‑totalité des cas.
Bonnes pratiques complémentaires (récapitulatif)
- Vérifiez régulièrement les listes de contacts et supprimez les doublons/alias obsolètes.
- Évitez de dépendre d’un seul canal pour les communications urgentes : e‑mail + messagerie instantanée.
- Standardisez des modèles sobres pour l’externe : moins de faux positifs antispam.
- Formez les équipes à reconnaître et à transmettre les en‑têtes complets lors d’un incident.
Message clé : « Un rebond sur un destinataire n’implique pas l’échec des autres. » Faites confiance aux journaux, pas aux intuitions.