Après la nouvelle norme DMARC de 2026, que faire si les e-mails transférés par alias arrivent dans les courriers indésirables ?

Une évolution du standard ne constitue pas, à elle seule, un ordre de modifier votre configuration : RFC 9989, publié en mai 2026, remplace RFC 7489, mais ne prouve pas qu’un message transféré sera classé comme indésirable. Si des e-mails transférés par alias arrivent dans les courriers indésirables, examinez d’abord les résultats SPF, DKIM et DMARC du message, puis déterminez si le problème vient de l’expéditeur, du transfert ou du classement par le service destinataire. Ne changez pas une politique de domaine sur la seule base d’un résultat DMARC en échec.

Dernière vérification : 2 novembre 2026, à partir de RFC 9989, RFC 7960 et des recommandations officielles sur le transfert de messages.

Ce guide s’adresse aux personnes qui utilisent des alias ou le transfert pour recevoir des abonnements et des notifications, ainsi qu’aux indépendants qui séparent les courriels de leurs clients et projets.
Les responsables d’un domaine ou d’une chaîne de transfert y trouveront une méthode pour repérer à quel intervenant confier l’enquête.

La mise à jour de DMARC exige-t-elle une nouvelle configuration ?

Non, pas automatiquement. RFC 9989 est le nouveau standard DMARC et remplace RFC 7489, selon la fiche officielle de RFC 9989. Cette mise à jour ne signifie pas que chaque personne qui reçoit un courriel transféré doit modifier ses alias, changer d’adresse de destination ou toucher aux enregistrements DNS de son domaine. Elle ne permet pas non plus d’expliquer, à elle seule, pourquoi un message précis se trouve dans les indésirables.

Il faut distinguer trois niveaux d’information. Le standard définit un cadre technique ; les consignes d’un service de messagerie décrivent la façon dont ce service recommande de gérer ses propres transferts ; les en-têtes montrent les résultats associés à un message particulier. Ces éléments répondent à des questions différentes et ne sont pas interchangeables. La fiche de RFC 7960 sur DMARC et les flux de courriels indirects traite précisément des difficultés d’interopérabilité que peuvent rencontrer les messages transférés. Elle justifie de contrôler le chemin suivi par le message, pas d’attribuer automatiquement un incident à la nouvelle norme.

En pratique, une modification globale des alias ou de la politique DMARC peut créer davantage de problèmes qu’elle n’en résout. Le remplacement d’une adresse complique la gestion des comptes qui utilisent déjà cet alias ; une politique de domaine modifiée sans audit peut aussi toucher d’autres messages que celui qui a déclenché le signalement. Il vaut donc mieux commencer par une seule livraison identifiable, conserver ses éléments techniques, puis élargir l’analyse uniquement si plusieurs messages comparables présentent la même anomalie.

Le message est-il absent ou simplement mal classé ?

La première distinction à établir est celle entre la non-livraison et le classement. Si un message n’apparaît ni dans la boîte de réception ni dans les indésirables, il faut examiner la recherche du service destinataire, les éventuels dossiers de quarantaine et les règles de filtrage. Si le message est bien présent dans les indésirables, le transfert a peut-être fonctionné jusqu’à la destination ; le problème constaté porte alors sur la décision de classement, pas nécessairement sur l’acheminement.

Prenez un seul message comme objet de vérification et consignez son expéditeur, l’heure approximative de réception et l’adresse alias utilisée. Recherchez-le dans toutes les vues pertinentes en utilisant, si nécessaire, l’adresse de l’expéditeur ou un terme distinctif de l’objet. Lorsque l’adresse est utilisée pour plusieurs listes ou services, vérifiez aussi que le message examiné provient bien de l’envoi attendu : un message de notification et un message publicitaire du même expéditeur peuvent suivre des règles différentes.

Ce relevé évite deux raccourcis coûteux. D’abord, supprimer puis recréer un alias ne répare pas un problème de classement sur des messages déjà reçus. Ensuite, demander immédiatement à l’expéditeur de modifier sa configuration peut faire perdre du temps si le message a été correctement authentifié et que seul le filtre de destination l’a placé dans le mauvais dossier. Pour comprendre cette différence, il est utile de distinguer les rôles d’un alias et d’une adresse temporaire : l’adresse peut isoler l’identité communiquée, mais elle n’indique pas à elle seule à quel endroit le traitement du message a échoué.

Étape 1 : conserver le message et relever ses en-têtes

Ouvrez le message reçu, y compris dans le dossier des indésirables, et affichez ses détails ou sa source originale. Les menus et intitulés varient selon le service ; une aide officielle sur la consultation de l’authentification des messages décrit un exemple de méthode de lecture des détails disponibles. Le principe est de chercher le champ Authentication-Results et de relever séparément les résultats SPF, DKIM et DMARC. La spécification de ce champ est décrite dans RFC 8601.

Ne vous contentez pas de la mention générale « authentifié » ou « échec ». Notez le résultat associé à chaque mécanisme, ainsi que les domaines que l’en-tête indique pour les contrôles concernés. Une synthèse comme « SPF en échec, DKIM réussi, DMARC en échec » est plus exploitable qu’une impression générale, mais elle ne permet pas, sans le contexte, de déterminer qui est responsable.

Étape 2 : séparer le résultat SPF de l’évaluation DMARC

SPF vérifie notamment si l’adresse IP présentée lors de la réception est autorisée pour le domaine concerné. Or, lors d’un transfert, le service intermédiaire peut remettre le message au destinataire final depuis sa propre infrastructure. Le serveur final ne voit alors pas nécessairement la même adresse IP que lors de la première réception. Un SPF en échec après transfert peut donc signaler un effet du chemin, et non prouver que l’expéditeur d’origine a usurpé son identité.

DKIM vérifie une signature associée au message. DMARC, de son côté, évalue l’alignement entre le domaine visible dans l’adresse d’expédition et les domaines authentifiés par SPF ou DKIM, conformément au cadre défini par le standard. Pour interpréter un résultat, il faut donc examiner les relations entre les domaines autant que les mots « pass » ou « fail ». Un SPF qui échoue et un DKIM qui passe ne conduisent pas automatiquement à la même conclusion qu’un échec des deux mécanismes ; l’alignement DKIM peut notamment expliquer pourquoi le message satisfait ou non à DMARC.

Un service de réception peut aussi appliquer ses propres contrôles et décisions de filtrage. Ainsi, la ligne DMARC dans les en-têtes est un élément d’enquête, pas une promesse que le message arrivera dans la boîte principale. Les recommandations officielles relatives au transfert de courriels rappellent que le transfert peut affecter l’authentification et conseillent notamment d’éviter de modifier les messages d’une façon qui détériore leur signature DKIM. Cela décrit une recommandation de gestion du transfert, pas le comportement garanti de tous les services.

Étape 3 : vérifier si le contenu a été modifié

Une signature DKIM peut ne plus être valide si un intermédiaire modifie des éléments protégés par la signature. Certaines transformations visibles — changement de l’objet, ajout d’un préfixe, modification du corps ou réécriture de certains champs — peuvent donc compter dans l’analyse. Toutefois, la présence d’une modification apparente ne suffit pas à conclure qu’elle est la cause de l’échec : il faut vérifier ce que la signature couvrait, ce que les en-têtes indiquent et, si possible, comparer avec une copie du message avant transfert.

Séparez l’authentification à l’origine de celle constatée après transfert. Si les en-têtes du message initial sont disponibles, relevez ses résultats d’authentification et comparez-les à ceux du message reçu à destination. Sans copie initiale, les résultats observés après transfert décrivent le message tel qu’il est arrivé au service final ; ils ne reconstituent pas avec certitude chaque étape précédente.

Le problème peut être subtil dans un contexte professionnel. Une indépendante qui transfère des échanges clients vers une boîte commune peut voir passer les messages habituels tout en constatant que certaines réponses contenant une signature ou un format particulier sont classées différemment. Ce cas ne prouve ni une défaillance systématique de l’alias ni un changement imposé par DMARC : il appelle une comparaison entre un message affecté et un message correctement classé, en tenant compte de l’expéditeur, du chemin et des modifications.

Questions fréquentes sur l’authentification après transfert

La nouvelle norme DMARC impose-t-elle de modifier un transfert déjà configuré ?

Non, la publication de RFC 9989 ne signifie pas que les adresses de transfert existantes doivent être remplacées ou reconfigurées. Commencez par examiner un message concret et ses résultats SPF, DKIM et DMARC dans les en-têtes. N’intervenez sur la politique du domaine qu’après avoir identifié une anomalie vérifiable et fait contrôler l’architecture d’envoi par son administrateur.

Que faut-il vérifier en premier lorsqu’un alias envoie des messages dans les indésirables ?

Recherchez d’abord le message dans la boîte de réception, le dossier des indésirables et, si le service en propose un, le dossier de quarantaine. Notez l’expéditeur, l’heure de réception et l’adresse de destination, puis ouvrez les en-têtes du message. Cette vérification permet de distinguer un problème de livraison d’un classement en indésirable, qui ne se traite pas de la même façon.

Que faire si SPF échoue après transfert alors que DKIM passe ?

Un échec SPF après transfert ne suffit pas à conclure que l’expéditeur est frauduleux : le serveur destinataire peut voir une autre adresse IP que celle autorisée par le domaine d’origine. Si DKIM passe, vérifiez aussi l’alignement DMARC et l’intégrité du message. Si le résultat reste ambigu, transmettez les en-têtes à l’administrateur du transfert ou à l’expéditeur, selon l’endroit où l’anomalie apparaît.

Où lire les résultats SPF, DKIM et DMARC dans les en-têtes ?

Affichez les détails ou la source originale du message dans votre service de messagerie, puis repérez le champ Authentication-Results ajouté par le serveur qui l’a reçu. Relevez séparément les résultats SPF, DKIM et DMARC ainsi que le domaine indiqué pour chaque contrôle. Comparez-les aux en-têtes du message d’origine si vous les avez, sans confondre un résultat observé après transfert avec celui de la première réception.

Qui doit traiter l’incident selon les indices recueillis ?

Le point de contact dépend de l’endroit où les résultats cessent d’être cohérents. Si le message d’origine présente déjà des résultats d’authentification problématiques, transmettez les en-têtes et les informations de livraison à l’expéditeur ou à son équipe technique. Celui-ci peut vérifier sa configuration d’envoi et déterminer si le problème concerne son domaine ou un message particulier.

Si les résultats initiaux sont cohérents mais que le message est modifié ou évalué différemment après transfert, contactez la personne qui administre la règle de transfert ou le domaine concerné. Il peut s’agir du fournisseur du service de transfert, d’un administrateur de messagerie ou de l’équipe qui gère le domaine, selon l’organisation. Joignez le message original si disponible, le message transféré et les lignes pertinentes d’Authentication-Results. Évitez d’envoyer des en-têtes complets à des personnes qui n’en ont pas besoin : ils peuvent contenir des détails sur le trajet et les systèmes impliqués.

Lorsque SPF, DKIM et DMARC paraissent cohérents, mais que le message reste dans les indésirables, le dossier peut relever du classement par le service destinataire. Suivez alors sa procédure de signalement ou son mécanisme d’expéditeur autorisé, si cette option est disponible. Une liste d’expéditeurs autorisés n’est pas un correctif universel : elle peut influencer le classement pour une boîte donnée sans réparer une signature, une règle de transfert ou l’authentification du domaine d’origine.

Pour un domaine que vous gérez, ne copiez pas une valeur DNS générique trouvée dans un tutoriel. Avant toute modification, l’administrateur doit vérifier les systèmes qui envoient réellement les messages, les domaines utilisés, les sélecteurs DKIM et la politique en vigueur. Une valeur adaptée à une autre organisation peut invalider l’authentification ou perturber des flux légitimes. Le diagnostic d’un message transféré ne remplace donc pas l’inventaire de l’architecture d’envoi.

Comparer les vérifications avant de modifier quoi que ce soit

Les avantages d’un alias indépendant restent concrets : il permet de distinguer des usages, de repérer quel service est associé à une adresse et, selon la solution employée, de limiter l’exposition de l’adresse principale. La limite est tout aussi importante : une adresse distincte ne garantit pas l’acceptation des messages par tous les filtres, ni une réponse possible, ni une récupération durable si le mécanisme de transfert ou le compte associé change. Pour protéger une adresse lors d’une inscription, les critères de protection de l’adresse lors de la création d’un compte aident à choisir une adresse adaptée à la durée et à l’importance du service.

Si le message concerne une facture, un accès professionnel ou une procédure de récupération, gardez un canal de réception pérenne et vérifiez régulièrement qu’il fonctionne. Un alias ou un transfert peut organiser les flux, mais ne doit pas devenir l’unique point de dépendance sans procédure de secours. À l’inverse, pour une inscription ponctuelle sans besoin de réponse ni de récupération à long terme, une adresse temporaire peut éviter de communiquer l’adresse principale. OrbForward peut être envisagé dans ce cas d’usage ; consultez ses modalités avant d’y associer un compte important, et ne traitez pas un transfert temporaire comme une garantie de livraison ou d’authentification.

Questions fréquentes