Une campagne affiche 98 % de messages « délivrés ». Pourtant, plusieurs clients assurent ne rien avoir reçu. Les deux observations peuvent être vraies : le serveur destinataire a accepté le message, puis l’a placé dans les indésirables, dans une catégorie secondaire ou derrière un filtrage interne. Accepté ne signifie pas lu, ni même visible dans la boîte principale.
Changer de plateforme dans cette situation peut déplacer le problème sans le résoudre. Le domaine expéditeur, les destinataires, les pratiques de collecte et certains paramètres d’authentification suivent généralement l’entreprise. Il faut donc reconstituer le parcours du message avant de modifier l’outil.
Ce diagnostic concerne aussi bien une newsletter B2B qu’une facture, une invitation commerciale ou un lien de connexion. Ces flux n’ont cependant ni la même urgence ni les mêmes destinataires. Les mesurer ensemble masque précisément les incidents qu’il faudrait voir.
En bref — Séparez les refus SMTP, les reports temporaires et les messages acceptés mais filtrés. Contrôlez l’identité réellement authentifiée, pas seulement le nom affiché. Analysez les résultats par fournisseur et par flux. Réduisez les envois indésirables avant d’augmenter les volumes. Une authentification correcte est nécessaire à un fonctionnement robuste ; elle ne garantit pas l’arrivée en boîte principale.
Le premier indicateur utile est le lieu de la panne
Le bouton « envoyer » déclenche une chaîne : préparation du message, mise en file, connexion au serveur destinataire, acceptation éventuelle, filtrage et affichage. Une panne en amont n’appelle pas la même correction qu’une plainte après réception.
Conservez pour chaque tentative un identifiant de message, le flux concerné, l’heure, le domaine destinataire, le résultat SMTP et le nombre de reprises. Ajoutez le domaine visible dans le champ expéditeur et, lorsque l’outil l’expose, le domaine de retour utilisé pour les rebonds. Ces informations permettent de suivre un incident sans recopier tout le contenu ni conserver inutilement des données personnelles.
Un code temporaire de classe 4xx indique normalement que la tentative n’a pas abouti et peut être réessayée selon les règles du système. Un code permanent de classe 5xx demande une analyse du motif plutôt qu’une répétition identique. Le texte et le code étendu du destinataire sont importants : « utilisateur inconnu » et « politique d’authentification non respectée » ne conduisent pas à la même action.
Certains rejets surviennent après l’acceptation initiale et reviennent sous forme de notification. Il faut rapprocher ces retours du message d’origine. Une simple moyenne calculée au moment de l’envoi les ignore.
| Observation | Question à poser | Vérification prioritaire |
|---|---|---|
| Message jamais remis au serveur distant | La file ou la connexion est-elle bloquée ? | Journaux d’envoi, délais, configuration réseau |
| Refus lié à l’identité expéditeur | Quel domaine a réellement été authentifié ? | SPF, DKIM et alignement DMARC |
| Reports concentrés chez un fournisseur | Existe-t-il une limitation ou un pic inhabituel ? | Codes SMTP, rythme, réputation observée |
| Acceptation sans visibilité chez le destinataire | Où le message a-t-il été classé ? | En-têtes reçus, filtrage local, retours utilisateurs |
| Factures touchées mais newsletter intacte | Les deux flux partagent-ils la même configuration ? | Domaine, signatures et infrastructure de chaque flux |
Cette grille est un ordre d’investigation, pas une preuve automatique. Une réception réussie sur votre adresse personnelle ne représente pas les filtres d’un groupe industriel ou d’un autre fournisseur.
SPF, DKIM et DMARC ne vérifient pas la même chose
SPF permet de déclarer les systèmes autorisés à envoyer pour un domaine utilisé dans l’enveloppe SMTP. Ce domaine peut différer de l’adresse que voit le lecteur. Un résultat SPF valide pour le prestataire ne suffit donc pas, à lui seul, à établir que votre domaine visible est correctement protégé.
DKIM ajoute une signature vérifiable associée à un domaine. Elle porte sur les éléments signés du message. Le domaine de signature, indiqué par le paramètre d=, mérite un contrôle explicite. Une interface peut afficher « DKIM activé » alors que seule une signature appartenant au prestataire est utilisée.
DMARC relie ces mécanismes au domaine du champ visible From. Un message peut réussir DMARC lorsque SPF ou DKIM réussit avec un domaine correctement aligné. Ce contrôle porte sur l’usage du domaine, pas sur la véracité de la facture ou la qualité de la proposition commerciale. Un message authentifié peut rester indésirable.
Le standard DMARC a été actualisé par la RFC 9989 en mai 2026, qui remplace les RFC 7489 et 9091. Pour l’exploitation, cela invite surtout à consulter une documentation maintenue et à vérifier les capacités effectivement déployées chez ses interlocuteurs. La publication d’un nouveau standard ne signifie pas que tous les serveurs changent simultanément de comportement.
Prenons un exemple fictif : une société utilise contact@entreprise.example, mais le service de campagne signe uniquement avec son propre domaine. SPF passe pour le domaine de retour du service ; DKIM passe également pour ce service. Si aucun de ces domaines n’est aligné avec entreprise.example, DMARC peut échouer malgré deux indicateurs verts. La correction concerne l’identité configurée, pas la rédaction de l’objet.
N’interprétez jamais cette explication comme une invitation à copier des enregistrements DNS trouvés ailleurs. Les valeurs dépendent du prestataire, des domaines autorisés et des services réellement employés. Recenser les expéditeurs légitimes vient avant toute politique restrictive.
Faire l’inventaire avant de verrouiller le domaine
La messagerie principale n’est souvent qu’une partie des envois. Un logiciel de facturation, un formulaire de site, un outil RH ou une application métier peut également expédier au nom de l’entreprise. Un changement DNS qui oublie ces services risque de casser des communications essentielles.
Créez un registre simple : service, responsable, finalité, adresse visible, domaine de retour, signature, volume approximatif, criticité et procédure de test. Si personne ne connaît le responsable d’un expéditeur, le problème est déjà organisationnel. Sa suppression ou sa correction demande un propriétaire identifié.
La politique DMARC en mode observation aide à découvrir les usages, lorsqu’on reçoit des rapports exploitables. Elle n’applique pas à elle seule une instruction de rejet. Le passage à une politique plus restrictive doit suivre la correction des flux légitimes, l’analyse des exceptions et un plan de retour arrière.
Attention aux transferts et aux intermédiaires : le chemin du message peut affecter les résultats d’authentification. Ne classez pas tous les échecs comme une usurpation sans examiner le contexte. Certains flux autorisés nécessitent une adaptation technique ou une compréhension du traitement du destinataire.
Séparez aussi les responsabilités. Le marketing choisit les destinataires et le rythme. L’équipe technique gère le domaine et l’intégration. Le support conserve les exemples précis de non-réception. Lorsque chacun regarde son propre écran sans partager les identifiants, le diagnostic tourne en rond.
Une bonne liste vaut davantage qu’un objet habile
La réputation d’envoi dépend d’un ensemble de signaux et de politiques propres aux destinataires. Elle n’est pas un score universel qu’un fournisseur pourrait garantir à l’identique partout. Les plaintes, les adresses invalides et les changements de cadence donnent néanmoins des indications concrètes sur les pratiques à corriger.
Dans un cas fictif, 10 000 messages sont soumis : 400 reviennent en erreur permanente, 300 restent temporairement différés et 9 300 sont acceptés à l’instant du relevé. Présenter « 93 % délivrés » sans expliquer les 300 reports laisse croire que le résultat est définitif. Si 200 reports aboutissent ensuite et 100 échouent, le bilan final devient 9 500 acceptations et 500 échecs. Cela ne prouve toujours pas 9 500 arrivées en boîte principale.
Regardez séparément les adresses acquises récemment, les contacts anciens, les formulaires et les importations. Un lot dégradé peut suffire à rendre une campagne difficile à analyser. Conservez l’origine et la date de collecte lorsque cela sert la gestion légitime du fichier, avec des règles de conservation adaptées.
Une liste de suppression doit empêcher la réintroduction d’adresses ayant fait l’objet d’un désabonnement ou d’une exclusion pertinente. Importer de nouveau un ancien CSV ne doit pas effacer ces décisions. Ce point rejoint directement les précautions de migration et nettoyage d’un CRM.
La prospection professionnelle comporte aussi des obligations relatives aux personnes et au contexte de contact. Une bonne configuration technique ne rend pas automatiquement licite une collecte ou une campagne. Avant une opération inhabituelle, faites vérifier le cadre applicable et les mécanismes d’opposition, plutôt que de traiter la conformité comme un réglage de serveur.
Désabonnement et cadence : rendre le refus simple
Pour les messages marketing, le destinataire doit pouvoir arrêter les sollicitations sans parcourir un labyrinthe. Une procédure compliquée encourage les plaintes et produit des demandes manuelles difficiles à synchroniser.
Les exigences publiées par Gmail distinguent notamment les expéditeurs dépassant 5 000 messages par jour vers les comptes Gmail personnels. Elles comprennent des dispositions d’authentification et de désabonnement en un clic pour les messages marketing et souscrits concernés. Ce seuil n’est ni une obligation identique pour toute messagerie ni une autorisation d’ignorer les bonnes pratiques sous ce volume. Vérifiez les règles du destinataire visé et leur actualisation.
L’équipe doit tester le parcours complet : demande de désabonnement, inscription dans la suppression, arrêt des automatisations et absence de réimportation. Les messages de service indispensables doivent être distingués des sollicitations commerciales ; leur définition ne doit pas servir à contourner une opposition.
Un changement brutal de volume complique également le diagnostic. Si une campagne quadruple les envois, change de domaine et modifie la liste le même jour, impossible d’identifier simplement le facteur principal. Faites varier un élément à la fois lorsque les contraintes le permettent.
Les ouvertures sont un signal fragile
Les pixels de suivi peuvent être bloqués, préchargés ou traités par des systèmes intermédiaires. Les clics peuvent également provenir de contrôles de sécurité automatisés. Une hausse spectaculaire des ouvertures ne constitue donc pas, seule, une amélioration de la délivrabilité ou de l’intérêt commercial.
Choisissez des résultats plus proches de votre objectif : réponses humaines qualifiées, demandes effectivement reçues, accès au document, paiement après facture ou consommation réelle d’un lien de connexion. Leur mesure doit tenir compte des limites de suivi et des données qu’il est pertinent de collecter.
Pour une campagne B2B, relier l’envoi aux opportunités reste utile, mais demande une méthode explicite. Le dossier sur l’attribution marketing et le pipeline explique pourquoi une influence observée ne suffit pas à démontrer une vente causée par un e-mail.
Les adresses de test, ou boîtes témoins, aident à détecter certains problèmes de rendu et de placement. Elles représentent un échantillon contrôlé, pas toute la population. Un rapport qui annonce 100 % de réussite sur cinq boîtes doit conserver cette limite dans son intitulé.
Un protocole de diagnostic reproductible
Commencez par trois messages réels concernés par l’incident et trois messages comparables reçus normalement. Demandez les en-têtes techniques lorsque le destinataire peut les fournir, en retirant les éléments inutiles au diagnostic. Relevez les chemins, les domaines et les résultats d’authentification.
Comparez ensuite une fenêtre avant l’incident et une fenêtre après. Gardez la même définition des événements et identifiez les changements : nouveau sous-domaine, rotation de signature, import de contacts, pic de volume, modification du modèle ou changement de fournisseur. Les événements datés valent mieux qu’un souvenir approximatif.
Organisez le test par flux et par domaine destinataire. Une facture envoyée depuis une application métier n’est pas un témoin valide pour une newsletter expédiée sur une infrastructure différente. De même, un rejet concentré sur un seul fournisseur ne démontre pas une panne générale.
Attribuez à chaque hypothèse une preuve attendue et une correction réversible. Pour une signature absente, la preuve est visible dans les en-têtes ; pour une liste vieillissante, elle vient des erreurs et des cohortes ; pour une limitation de débit, des réponses du serveur. Le mot « spam » ne décrit pas suffisamment le mécanisme.
Après correction, contrôlez un volume prudent, puis élargissez. Surveillez les reprises : elles doivent éviter de créer des doublons ou une nouvelle surcharge. La gestion des identifiants et des nouvelles tentatives suit les mêmes principes que l’automatisation fiable des processus métier.
Enfin, documentez ce qui reste inconnu. Si le serveur accepte le message mais ne révèle pas son classement, indiquez cette limite. L’entreprise gagne davantage avec un diagnostic précis à 80 % qu’avec une certitude fabriquée.
Changer de prestataire seulement avec un cahier de preuves
Une migration peut être justifiée : journaux insuffisants, mauvaise gestion des suppressions, absence d’authentification adaptée ou support incapable d’expliquer les refus. Mais comparez les candidats sur des critères vérifiables, pas sur une promesse de « délivrabilité maximale ».
Demandez l’accès aux événements, l’export des suppressions, la gestion des signatures, la séparation des flux et la politique de reprise. Évaluez aussi le coût de la migration : modèles, listes, consentements ou oppositions, domaine, tests et formations. Un tarif par message inférieur peut masquer une exploitation plus coûteuse.
Le meilleur livrable du diagnostic est une fiche exploitable : cause démontrée, flux affectés, correction, responsable, résultat observé et date du prochain contrôle. Cette fiche évite de recommencer la même enquête six mois plus tard. Surtout, elle remet la priorité au bon endroit : faire parvenir le bon message aux personnes qui en ont réellement besoin.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
