Quand un courrier légitime échoue à DMARC, la cause est presque toujours l'une de ces situations prévisibles : un résultat SPF ou DKIM manquant ou mal aligné, un transfert qui casse SPF, ou un expéditeur tiers qui n'a jamais été authentifié pour votre domaine. La solution consiste rarement à assouplir votre politique. Il s'agit de trouver la source et de l'authentifier correctement.
Comment savoir ce qui échoue ?
Commencez par vos rapports, car ils vous indiquent exactement quelle source échoue et pourquoi. Vos rapports agrégés ventilent le courrier par IP d'envoi et affichent les résultats SPF et DKIM ainsi que l'alignement pour chacun. Une source qui affiche pass pour la vérification brute mais fail après alignement est le schéma le plus courant, et il pointe directement vers le problème. Si vous n'êtes pas encore à l'aise pour les lire, comment lire un rapport DMARC détaille chaque champ.
Une fois que vous voyez quelle source échoue, il s'agit presque toujours de l'une des causes ci-dessous.
Cause 1 : un écart d'alignement
C'est la cause principale. SPF ou DKIM passe, mais pour un domaine qui ne correspond pas à votre adresse From visible, donc DMARC le compte comme un échec. Cela signifie généralement qu'un service d'envoi s'authentifie avec son propre domaine au lieu du vôtre.
La solution est de mettre le service en alignement. Pour SPF, cela signifie envoyer avec un Return-Path (domaine de rebond) sur votre propre domaine. Pour DKIM, cela signifie signer avec une clé publiée sur votre domaine, de sorte que le domaine de signature corresponde à votre From. La plupart des plateformes de messagerie prennent en charge un domaine personnalisé exactement pour cela : vous publiez un ou deux CNAME et l'alignement se met en place. Le concept est expliqué dans comment fonctionne DMARC.
Cause 2 : le transfert
Le transfert casse silencieusement SPF. Quand un message est transféré, le serveur de transfert le renvoie, et ce serveur ne figure pas dans votre enregistrement SPF, donc la vérification SPF échoue à la destination finale. Vous ne pouvez pas faire grand-chose contre les règles de transfert des autres.
La bonne nouvelle, c'est que DKIM survit généralement au transfert, car la signature voyage avec le message. C'est exactement pourquoi DMARC passe sur SPF ou DKIM : tant que votre DKIM est solide et aligné, le courrier transféré passe encore DMARC même quand SPF échoue. La solution pratique pour les échecs de transfert est de vous assurer que DKIM est correctement configuré et aligné, puis de cesser de vous inquiéter de la colonne SPF pour le courrier transféré.
Cause 3 : un expéditeur tiers oublié
Presque toutes les organisations envoient via plus de services qu'elles ne le pensent : un CRM, un service d'assistance, un outil de facturation, une plateforme marketing, un service d'enquêtes. Chacun doit être authentifié pour votre domaine, sinon son courrier échoue à DMARC. Les nouvelles sources qui apparaissent dans vos rapports en font généralement partie.
Traitez-les une par une. Pour chaque service légitime, suivez ses instructions pour configurer SPF et DKIM sur votre domaine (le libellé est souvent "authenticate your domain" ou "use a custom sending domain"). Vérifiez ensuite dans vos prochains rapports que la source est passée à l'état réussi et aligné. Tenez une liste à jour, car c'est la partie qui dérive à mesure que les équipes adoptent de nouveaux outils.
Cause 4 : SPF trop large ou au-delà de la limite de résolutions
Deux pièges propres à SPF. Si votre enregistrement SPF a dépassé 10 résolutions DNS (une limite stricte dans la spécification), il peut échouer purement et simplement, entraînant avec lui du courrier autrement valide. Et un enregistrement trop permissif peut laisser passer du courrier que vous n'aviez pas l'intention d'autoriser. Auditez votre enregistrement SPF, consolidez les entrées include: si vous approchez de la limite, et supprimez les services que vous n'utilisez plus.
Ce que vous ne devez pas faire
Ne corrigez pas les échecs en affaiblissant votre politique à p=none pour l'y laisser. Cela fait taire les rapports, mais cela cesse aussi de protéger qui que ce soit, et le problème d'usurpation que vous étiez en train de résoudre est de nouveau grand ouvert. Traitez un échec comme un signal pour authentifier une source, pas comme une raison de reculer. La façon légitime d'assouplir est de redescendre p= d'un cran et de continuer à lire les rapports, ce que couvre qu'est-ce qu'une politique DMARC.
Synthèse
Lisez le rapport, trouvez la source en échec, déterminez si elle est légitime, puis authentifiez-la ou reconnaissez qu'il s'agit d'une usurpation que vous bloquez désormais. Parcourez la liste jusqu'à ce que chaque expéditeur réel passe et soit aligné, et votre politique peut rester sereinement à reject. Si vous en êtes encore à la mise en place, comment configurer DMARC couvre les bases, et le guide d'authentification de Bird contient les enregistrements propres au domaine. La plupart des échecs semblent alarmants et se révèlent être une correction d'alignement de cinq minutes une fois que vous savez quelle source viser.