Pourquoi votre boîte de réception déborde-t-elle de rapports de non-remise pour des campagnes que vous n’avez jamais lancées ? Le tableau de bord de votre outil d’emailing affiche zéro envoi. Pourtant, les NDR s’accumulent depuis la veille. Ce phénomène porte un nom précis : le backscatter. Un spammeur a utilisé votre domaine comme adresse de retour sur ses envois frauduleux ; les serveurs qui rejettent ces messages après coup vous renvoient la facture sous forme de rebonds. Rien à voir avec un piratage de votre compte ni une fuite de votre liste de contacts.
Le mécanisme du backscatter : From visible et Return-Path, deux adresses distinctes
Le client mail affiche un expéditeur. La commande SMTP MAIL FROM en porte un autre, invisible dans l’interface. Cette seconde adresse, le Return-Path, sert de destination aux rebonds. Un spammeur usurpe ce champ technique, pas forcément le From visible que voit le destinataire final dans sa messagerie. Il inscrit votre domaine dans l’enveloppe SMTP au moment de la commande MAIL FROM, sans que le corps du message n’affiche jamais votre nom. Cette distinction commande tout ce qui suit, y compris le choix du réglage qui coupe le flux. Le mécanisme complet de l’usurpation, du From falsifié à la contrefaçon d’identité complète, est couvert par notre article sur comment fonctionne l’email spoofing. Ici, la cible est plus étroite : l’enveloppe technique, celle que le protocole utilise pour router les rapports d’erreur, distincte du message que lit réellement le destinataire final.
Pourquoi le serveur du destinataire vous renvoie le rebond à vous
Parce qu’il expédie le rapport d’erreur à l’adresse inscrite dans l’enveloppe. Cette adresse porte votre domaine. Aucun élément du protocole ne lui permet de savoir qu’elle a été falsifiée. Dans le détail, deux comportements existent chez un serveur qui reçoit un email frauduleux. Le premier rejette la connexion en direct, pendant la transaction SMTP, avec un code d’erreur immédiat ; aucun rebond n’est jamais généré, le problème s’arrête net côté serveur émetteur du spam. Le second accepte le message. Il le découvre trop tard : la boîte est pleine ou le destinataire n’existe pas. C’est ce deuxième cas qui produit le backscatter : le serveur génère un NDR (Non-Delivery Report), au format défini par la RFC 3464 (IETF, 2003), puis l’envoie de bonne foi au Return-Path usurpé.
Un chercheur qui a reçu 49 000 messages de backscatter en quatre mois a passé ses rebonds au crible de quatre listes noires : sur 4177 rebonds dont l’IP émettrice était identifiable, 19% de ces IP n’y figuraient pas encore, SpamCop en signalant 73% et CBL 69% (Christopher Fuhrman, École de technologie supérieure de Montréal, 2008).
Ce vieux constat reste d’actualité. Les serveurs mal configurés qui acceptent puis rejettent, plutôt que de refuser à l’entrée, forment un parc résiduel qui continue de tourner, souvent des messageries d’entreprise administrées par des équipes qui ne suivent plus les recommandations SMTP courantes. La typologie complète des différents motifs d’emails non livrables est traitée par ailleurs. Le backscatter s’y ajoute comme un cas particulier, généré par un tiers et sans lien avec votre propre envoi.
Lire les en-têtes du bounce pour confirmer que l’envoi ne vient pas de vous
Un rebond suspect arrive. Trois vérifications suffisent en général à trancher, dans l’ordre :
- La chaîne Received, en haut du message brut, liste chaque serveur traversé du premier au dernier. Si aucun d’entre eux ne correspond à votre infrastructure d’envoi habituelle, IP, MTA, plateforme d’emailing identifiée, l’origine est externe.
- Le Message-ID du message original, généralement inclus dans le corps du bounce sous forme de citation partielle. Un Message-ID que vos propres logs d’envoi n’ont jamais généré confirme que le message n’est jamais parti de chez vous.
- L’Enhanced Status Code du rapport, au format 5.x.x, précise la cause exacte du rejet côté serveur destinataire : boîte inexistante ou quota dépassé.
Un bounce backscatter se reconnaît à l’absence totale de correspondance entre son Message-ID et les journaux d’envoi de l’expéditeur légitime, quelle que soit la plateforme d’envoi utilisée, Twilio SendGrid, Mailjet ou un SMTP maison. Sans cette correspondance, aucune enquête supplémentaire n’est nécessaire.
Ce que ça ne veut pas dire : ni piratage, ni fuite de liste
La première réaction, en découvrant des dizaines de NDR inconnus, penche souvent vers l’hypothèse du compte compromis. Elle se comprend. Mais un backscatter ne suppose aucun accès au domaine ni à la boîte mail, aucune fuite de base de contacts, aucune compromission de l’outil d’emailing. Le spammeur n’a besoin que d’une information publique, votre nom de domaine, pour l’inscrire dans l’enveloppe d’un envoi qui n’implique jamais vos serveurs. On pourrait aussi croire qu’un ESP suffit à couvrir ce risque, puisqu’il gère déjà l’authentification des envois sortants. SPF et DMARC se déclarent pourtant au niveau du DNS du domaine, pas au niveau de l’outil d’envoi : changer d’ESP ne referme donc rien tant que ces enregistrements restent absents ou permissifs.
Une inquiétude revient ensuite systématiquement : ce flot va-t-il me faire blacklister ? Backscatterer.org, la liste noire dédiée à ce phénomène, recense les serveurs qui émettent du backscatter, jamais les domaines usurpés qui en reçoivent. On y entre en renvoyant des rebonds vers des tiers innocents. En recevoir des milliers n’y change rien.
Ce qu’on peut réellement faire : publier un SPF en hard fail
Un enregistrement SPF publié en -all est le seul réglage qui agit sur la source du backscatter. Ce hard fail demande au serveur receveur de rejeter, pendant la transaction SMTP, tout message qui inscrit votre domaine en MAIL FROM sans provenir de vos serveurs autorisés. Le message meurt à la porte, aucun NDR n’est généré, rien ne repart vers vous. La syntaxe complète est détaillée dans notre article sur ce qui se passe quand le SPF est absent. Le piège du dépassement est traité dans ce guide sur la limite des 10 lookups DNS. Ce qu’aucune configuration ne fera, en revanche : empêcher un spammeur d’écrire votre domaine dans une enveloppe ou forcer un serveur tiers mal réglé à respecter SPF.
DMARC intervient sur un autre plan. La nuance décide de ce que vous pouvez en attendre ici. Une politique en p=quarantine ou p=reject s’évalue sur le domaine du champ From d’en-tête, celui que voit le destinataire, après vérification qu’une signature DKIM ou un contrôle SPF authentifie bien ce domaine. C’est la règle d’alignement. Quand le spammeur se contente d’usurper l’enveloppe et signe son message d’un From étranger à votre domaine, votre politique DMARC n’est donc jamais consultée par le serveur receveur. Elle protège votre marque contre l’usurpation visible, elle ne coupe pas à elle seule les rebonds égarés : ce rôle revient à SPF, DMARC prenant le relais dès que le spammeur usurpe aussi le From affiché.
Côté réception, BATV (Bounce Address Tag Validation) règle le tri à la racine. Votre serveur signe l’adresse de retour de chaque envoi sortant avec un jeton daté, puis refuse tout NDR adressé à une adresse non signée. Un backscatter ne peut pas porter ce jeton, puisqu’il répond à une enveloppe que vous n’avez jamais émise. Surveiller les rapports agrégés DMARC (rua) donne par ailleurs une image du volume et de l’origine de l’usurpation, sans jamais l’arrêter à sa source, avec la même réserve que plus haut : ces rapports ne remontent que les messages portant votre domaine dans le From d’en-tête. Une usurpation limitée à l’enveloppe n’y apparaîtra pas. La lecture de ces fichiers XML fait l’objet d’un traitement complet dans notre guide pour lire un rapport DMARC agrégé.
Ce durcissement a un plafond. Un SPF hard fail ne fait pas taire les serveurs qui ignorent la politique, qui n’ont pas mis à jour leur résolveur ou qui appliquent une évaluation partielle des enregistrements DNS. Ce résidu-là continue de produire des rebonds égarés, même après un déploiement correct côté domaine. Le -all a par ailleurs un coût de bord à connaître : un message légitime relayé par un alias ou une boîte de renvoi échoue au contrôle SPF chez le destinataire final, puisque l’IP qui présente le message n’est plus la vôtre. Les serveurs de redirection bien tenus réécrivent l’enveloppe via SRS pour éviter ça ; les autres casseront vos transferts.
Vérifier que votre propre serveur n’en produit pas
Le raisonnement se retourne. Cette moitié du sujet est presque toujours passée sous silence. Un serveur qui accepte tout puis renvoie un NDR fabrique exactement le bruit décrit plus haut, chez quelqu’un d’autre. Les réglages qui produisent ce comportement sont connus :
- une adresse catch-all qui absorbe n’importe quel destinataire avant de découvrir que la boîte n’existe pas ;
- un auto-répondeur d’absence qui répond mécaniquement à une enveloppe usurpée ;
- une passerelle antispam qui filtre après acceptation, au lieu de refuser pendant la transaction SMTP.
Le correctif tient en une règle : valider l’existence du destinataire au moment du RCPT TO et refuser là, avec un code 5.x.x, plutôt que d’accepter puis de s’excuser. C’est ce qui sépare un serveur qui protège les autres d’un serveur qui finit sur Backscatterer.org.
Ne pas confondre backscatter et vraie liste sale
Un pic soudain de rebonds dans les statistiques d’envoi ressemble, à première vue, à une dégradation de la sender reputation. Il n’en est rien la plupart du temps, si les rebonds concernent des campagnes jamais lancées. La confusion coûte cher quand elle pousse à purger une liste de contacts sur la foi d’un signal qui ne vient pas d’elle : les erreurs de remise remontées par Google Postmaster Tools, comme les compteurs de hard bounce de votre plateforme d’envoi, restent sourds aux backscatter qui n’ont jamais transité par vos propres campagnes, puisqu’aucun envoi réel ne les a déclenchés. Avant de conclure à une list hygiene défaillante sur la foi d’un flot de NDR, vérifiez via les en-têtes décrits plus haut si ces rebonds correspondent à un envoi réel ou à une enveloppe usurpée : nettoyer la liste de contacts ne réglera rien si le problème vient d’ailleurs.
L’adoption de DMARC progresse, poussée par les règles imposées aux gros expéditeurs par Google et Yahoo depuis février 2024, qui exigent au minimum une politique publiée en p=none. La révision du standard parue en 2026 sous le nom de DMARCbis (RFC 9989) ne relève pas ce seuil : elle reformule le protocole et remplace la liste des suffixes publics par une remontée d’arborescence DNS, sans imposer de politique stricte à personne. Le parc résiduel de messageries mal configurées, lui, suit un calendrier bien plus lent, celui des mises à jour DNS que personne n’a planifiées.
