--- title: Pourquoi les campagnes de masse finissent en spam source: https://synapx.fr/blog/campagnes-email-masse-spam-delivrabilite/ date: 2026-07-14 category: Email site: SynapxLab --- # Pourquoi les campagnes de masse finissent en spam Une campagne ne devient pas du spam parce qu'elle contient le mot « gratuit » ou trois points d'exclamation. Elle devient indésirable lorsque les systèmes destinataires observent un ensemble de signaux incompatibles avec un expéditeur attendu : volume soudain, destinataires inconnus, adresses invalides, plaintes, liens peu fiables, identité instable ou absence de réaction aux erreurs. Les filtres modernes ne publient pas leur recette exacte. C'est volontaire : une pondération entièrement prévisible serait immédiatement contournée. Le diagnostic sérieux part donc des preuves que l'expéditeur possède — journaux SMTP, origine des contacts, cadence, authentification, plaintes et conversions — plutôt que d'un mystérieux « spam score » universel. Ce billet constitue le volet « réputation et incidents de diffusion » du [guide de l'e-mailing professionnel en 2026](/blog/emailing-professionnel-2026/). ## Le filtre ne prend pas une seule décision ```mermaid flowchart TD A["Connexion SMTP"] --> B{"IP, PTR, EHLO,
cadence acceptables ?"} B -->|non| C["Rejet ou délai 4xx/5xx"] B -->|oui| D["SPF, DKIM, DMARC
et structure du message"] D --> E["Réputation domaine/IP,
liens et historique"] E --> F["Signaux du destinataire :
plaintes, suppressions, intérêt"] F --> G{"Classement"} G --> H["Boîte principale"] G --> I["Onglet ou dossier"] G --> J["Spam / quarantaine"] G --> K["Rejet après politique"] ``` Une décision peut intervenir pendant la conversation SMTP, lors de l'analyse du message, après acceptation ou au niveau de chaque utilisateur. Deux personnes chez le même fournisseur peuvent donc voir le même message dans des dossiers différents. ## Les identités qui accumulent une réputation Le destinataire ne voit pas seulement une adresse IP. Il rapproche plusieurs éléments : - l'IP ou le pool qui établit la connexion ; - le nom annoncé par `EHLO` et son DNS inverse ; - le domaine d'enveloppe, souvent visible dans `Return-Path` ; - le domaine de signature DKIM et son sélecteur ; - le domaine du `From:` visible ; - les domaines des liens, redirections et images ; - la forme habituelle du message et son historique de trafic. Cette pluralité explique pourquoi changer d'IP sans changer les pratiques échoue. Le domaine et les liens conservent leur historique ; le nouveau couple IP/domaine arrive en plus sans réputation positive. La bonne séparation consiste à isoler des **catégories légitimes de trafic** — par exemple `transactionnel.example.com` et `news.example.com` — pas à multiplier les domaines jetables. L'authentification de ces identités est détaillée dans [SPF, DKIM et DMARC](/blog/securite-email-spf-dkim-dmarc/). Elle est indispensable, mais elle ne compense jamais une mauvaise liste. ## Le volume est un changement de comportement Passer de 2 000 à 200 000 messages en une heure ne multiplie pas seulement le débit par cent. Le changement modifie simultanément : - le nombre de connexions vers chaque opérateur ; - la proportion d'adresses anciennes ou peu engagées ; - le nombre absolu de plaintes, même si leur pourcentage paraît faible ; - la vitesse à laquelle une erreur de configuration se propage ; - le risque de remplir les files et de retarder les messages transactionnels. Il faut donc observer le trafic **par domaine destinataire**. Une cadence globale de 100 messages par seconde peut représenter 80 messages par seconde vers Microsoft et presque rien vers de petits domaines ; ce sont les limites du premier groupe qui seront atteintes. ```mermaid xychart-beta title "Exemple conceptuel : volume sans historique et signaux négatifs" x-axis [J1, J2, J3, J4, J5, J6] y-axis "indice relatif" 0 --> 100 line "volume" [5, 8, 15, 90, 100, 100] line "plaintes et rebonds" [2, 2, 4, 35, 55, 70] line "placement utile" [75, 78, 76, 48, 25, 16] ``` Ce schéma n'est pas une courbe universelle ni un seuil de fournisseur. Il montre le mécanisme : si la montée en charge révèle de mauvais destinataires, poursuivre au même rythme aggrave rapidement l'apprentissage négatif. ## Spam traps : ce que leur présence révèle Un piège à spam ne s'inscrit pas normalement à une newsletter. Sa présence peut provenir de plusieurs scénarios : | Type courant | Origine | Signal probable | |---|---|---| | Adresse créée comme piège | Jamais utilisée pour une relation normale | Scraping, génération ou achat de données | | Adresse recyclée | Ancienne boîte abandonnée puis convertie en piège | Base vieillissante et absence de nettoyage | | Adresse issue d'une faute fréquente | Variante d'un domaine ou saisie douteuse | Collecte sans confirmation et validation insuffisante | Les opérateurs ne publient pas nécessairement la nature de chaque piège. Un expéditeur doit chercher la cause dans ses sources : imports récents, formulaires attaqués, anciens concours, partenaire de collecte, réactivation d'un segment inactif ou absence de double opt-in. Retirer seulement l'adresse supposée ne répare pas le processus. Si une base contient un piège, elle peut aussi contenir des milliers de personnes qui ne reconnaîtront pas le message. ## Hard bounce, soft bounce et réponse SMTP complète Les catégories commerciales « hard » et « soft » simplifient des réponses plus riches. Les codes étendus de la RFC 3463 suivent la forme `classe.sujet.détail`, par exemple : ```text 550 5.1.1 Recipient address rejected: User unknown 421 4.7.0 Temporary rate limit; try again later 550 5.7.26 Unauthenticated email is not accepted ``` - `5.1.1` décrit généralement une adresse destinataire inexistante : l'expéditeur doit la supprimer. - `4.7.0` annonce ici une décision temporaire de politique : le MTA doit ralentir et réessayer, pas abandonner immédiatement. - `5.7.26` décrit un rejet permanent lié à l'authentification ou à la politique. Un code seul ne suffit pas. Conservez la ligne complète, le domaine destinataire, l'heure, le serveur appelé, l'IP d'envoi, l'identifiant de file et la tentative. Certains messages temporaires deviennent définitifs après expiration de la file ; certaines plateformes les regroupent alors sous un libellé qui masque la cause initiale. ### Politique de traitement minimale | Événement | Décision automatisée | Alerte utile | |---|---|---| | Destinataire inconnu certain | Suppression immédiate | Pic par source de collecte | | Boîte pleine ou indisponibilité temporaire | Réessais espacés par le MTA | Persistance anormale par domaine | | Limitation de débit | Réduire connexions et cadence pour ce domaine | Hausse rapide des `4.7.x` | | Échec d'authentification | Suspendre le flux mal configuré | Dès le premier rejet significatif | | Plainte | Supprimer du marketing | Taux par campagne et source | | Désabonnement | Appliquer immédiatement | Échec du mécanisme ou délai | ## Le warming n'est pas une cérémonie Le *warming* consiste à établir progressivement l'historique d'une nouvelle identité d'envoi. Il n'existe pas de calendrier officiel valable pour tous les volumes et tous les destinataires. Une séquence de 100, 200, 400 puis 800 messages n'a aucun sens si les 800 adresses sont anciennes ou si 90 % vont vers un seul fournisseur qui commence à limiter le trafic. Une montée en charge défendable suit ces principes : 1. commencer par les contacts récents dont la relation est la plus claire ; 2. séparer marketing et transactionnel pour que l'un ne bloque pas l'autre ; 3. augmenter seulement si les réponses SMTP, plaintes et résultats métier restent sains ; 4. garder une cadence prévisible d'un jour à l'autre ; 5. ralentir par opérateur dès l'apparition de limitations ; 6. ne jamais fabriquer de faux échanges ou utiliser des services d'engagement artificiel. Le premier envoi d'une nouvelle IP est aussi le pire moment pour réactiver cinq ans d'archives. Il combine deux inconnues : aucune réputation technique et aucune certitude sur l'intérêt des destinataires. ## Une IP dédiée n'est pas un vaccin | Configuration | Avantage | Risque | |---|---|---| | Pool partagé administré | Historique mutualisé, adapté aux petits volumes | Comportement des autres clients, contrôle limité | | IP dédiée | Isolation et pilotage fin | Réputation à construire, coût et besoin de volume stable | | Plusieurs IP par flux | Isolation transactionnel/marketing ou par entité réelle | Complexité, fragmentation et erreurs de routage | | Rotation pour contourner les filtres | Aucun avantage durable | Signal d'abus et réputation instable | Une IP dédiée qui envoie uniquement une newsletter mensuelle massive reste inactive puis produit un pic. Un relais partagé de qualité peut être plus cohérent. Le choix doit partir du volume continu, des exigences d'isolation et de la capacité de l'équipe à surveiller les files. ## Les listes de blocage ne sont qu'un signal Une DNSBL peut lister une IP de botnet, une plage qui ne devrait pas émettre directement, un domaine observé dans des messages indésirables ou un réseau entier selon sa propre politique. Les grands fournisseurs utilisent aussi des données internes invisibles publiquement. Trois conséquences : - ne pas apparaître sur une DNSBL publique ne prouve pas une bonne réputation ; - apparaître sur une petite liste non utilisée par vos destinataires n'explique pas forcément l'incident ; - demander un retrait avant de fermer un relais ouvert ou un compte compromis ne fait que retarder une nouvelle inscription. Le fonctionnement, les listes actives et la procédure de retrait sont détaillés dans [le guide des DNSBL](/blog/listes-noires-email-dnsbl/). ## Le « spam score » universel n'existe pas Un test SpamAssassin, une vérification de mots, un score de plateforme et le filtre Gmail sont quatre systèmes différents. Un `10/10` chez un outil de précontrôle signifie que les contrôles testés ont réussi ; il ne prédit ni l'historique de chaque destinataire ni les signaux privés d'un fournisseur. Utilisez un score pour détecter une régression — DKIM cassé, URL listée, HTML invalide, absence de version texte — mais ne l'optimisez jamais en supprimant au hasard des mots légitimes. Le [comparatif des outils avant envoi](/blog/tester-email-avant-envoi/) précise ce que chacun observe réellement. ## Gmail, Yahoo et Microsoft : interpréter les seuils Google recommande de maintenir le taux de spam observé dans Postmaster Tools sous `0,1 %` et de ne jamais atteindre `0,3 %`. Yahoo demande aux expéditeurs en volume de rester sous `0,3 %`. Ces valeurs sont des limites de risque publiées par chaque opérateur, pas une autorisation d'envoyer à 0,29 % de plaignants. À titre d'ordre de grandeur, `0,1 %` représente déjà une plainte pour 1 000 messages comptabilisés dans le dénominateur du fournisseur. À 500 000 messages, un petit pourcentage devient un grand nombre de personnes mécontentes. Le taux peut aussi différer de votre tableau de bord selon la population et les événements que l'opérateur sait mesurer. ## Tableau de bord de crise ### Retour terrain En cinq ans d’activité de mailing, c’est le premier courrier de la CNIL reçu à la suite d’une campagne. Il ne s’agissait ni d’un contrôle ni d’une sanction, mais de la transmission d’une réclamation demandant une réponse à l’usager : l’adresse concernée avait bien été supprimée des bases, sans que cette suppression lui soit confirmée. ![Courrier de la CNIL anonymisé reçu après une campagne de mailing B2B](/assets/img/blog/retour-experience-cnil-anonymise.png) *Retour d’expérience réel - document anonymisé.* Le suivi d’une crise ne s’arrête donc pas aux signaux SMTP : il doit aussi tracer les désinscriptions et les réponses aux demandes de droits. Surveillez au minimum par campagne, flux, IP et domaine destinataire : - messages soumis, acceptés, différés et rejetés ; - distribution des codes SMTP étendus ; - âge et taille de la file ; - hard bounces par source de collecte ; - plaintes et désabonnements ; - alignement SPF/DKIM/DMARC ; - domaines et IP inscrits sur des listes pertinentes ; - clics probables et conversions, en séparant les robots lorsque possible. ```mermaid flowchart LR A["Hausse de 4xx"] --> B{"Un seul
fournisseur ?"} B -->|oui| C["Réduire la cadence
vers ce domaine"] B -->|non| D["Contrôler IP, file,
DNS et configuration"] C --> E["Comparer codes,
heure et segment"] D --> E E --> F{"Plaintes ou rebonds
en hausse ?"} F -->|oui| G["Suspendre le segment,
auditer la collecte"] F -->|non| H["Vérifier réputation,
incident et changement technique"] ``` ## Ordre de diagnostic 1. **Geler les changements** et conserver les journaux. 2. **Identifier le périmètre** : campagne, IP, domaine d'envoi, fournisseur destinataire ou tous les flux. 3. **Lire les réponses SMTP complètes**, pas seulement le taux de livraison. 4. **Vérifier l'authentification et le DNS** depuis le message réellement reçu. 5. **Comparer les sources de contacts** et rechercher un import récent. 6. **Mesurer plaintes, hard bounces et retraits** par cohorte. 7. **Réduire ou suspendre** le trafic qui aggrave l'incident. 8. **Corriger la cause**, puis reprendre sur un petit segment récent et observé. Le filtre anti-spam n'est pas un adversaire à tromper. C'est un système qui reflète, imparfaitement mais à grande échelle, la confiance construite entre l'expéditeur et ses destinataires.