Comment effectuer une vérification DMARC pour les e-mails applicatifs ?

Considérer une vérification DMARC comme quatre tests, pas une seule requête

Une vérification utile comporte quatre niveaux. D’abord, découvrir la politique qui s’applique au domaine auteur du message. Ensuite, valider l’enregistrement TXT en tant que politique DMARC, plutôt que d’accepter n’importe quel texte renvoyé par le DNS. Troisièmement, tester l’alignement des identifiants sur un message réel : le domaine MAIL FROM authentifié par SPF ou un domaine de signature DKIM vérifié doit s’aligner sur le domaine de l’en-tête From visible. Enfin, confirmer la couverture opérationnelle en envoyant depuis chaque application, fournisseur, région et catégorie de message légitimes qui utilisent le domaine. Une requête DNS au vert ne couvre qu’une partie des deux premiers niveaux. Elle ne peut pas montrer qu’un fournisseur signe avec le domaine voulu, qu’un return path personnalisé est actif, qu’un transfert a modifié le comportement de SPF, ni qu’un système oublié survivra à une politique stricte.

Interroger le bon nom DNS et suivre la découverte de politique

Partez du domaine exact de l’en-tête From RFC5322, souvent appelé domaine auteur. Interrogez le TXT à _dmarc suivi de ce domaine. Pour un message envoyé depuis alerts@notify.example.test, commencez par _dmarc.notify.example.test plutôt que par l’hôte du site web, l’hôte MX ou le domaine du return path. La RFC 9989 définit une découverte de politique qui va au-delà d’une seule requête : si le domaine auteur n’a pas d’enregistrement valide, un destinataire peut parcourir l’arborescence DNS pour trouver la politique organisationnelle ou de suffixe public applicable. Le traitement des sous-domaines peut provenir de la balise sp, np ou p selon ce qui existe et l’endroit où la politique est trouvée. Un vérificateur doit donc indiquer à la fois le nom interrogé et le domaine de politique effectivement retenu. Un résultat qui se contente d’annoncer « enregistrement trouvé » peut masquer des erreurs d’héritage ou une politique de sous-domaine explicite qui modifie le traitement attendu.

Valider la structure de l’enregistrement avant d’interpréter la politique

Un enregistrement de politique DMARC utilise une syntaxe de paires balise-valeur. Selon la RFC 9989, v=DMARC1 est obligatoire, sensible à la casse et doit apparaître en premier ; une balise p valide fournit la politique d’évaluation demandée. Les valeurs de politique courantes sont none, quarantine et reject. Les balises facultatives décrivent les destinations de rapport, le comportement des sous-domaines et l’alignement SPF et DKIM strict ou relaxed. Ne corrigez pas silencieusement les balises mal orthographiées, une valeur p manquante, les enregistrements dupliqués ou conflictuels, les séparateurs non valides ou une valeur copiée avec des artefacts de guillemets du fournisseur DNS. Traitez une erreur d’évaluation permanente comme un résultat à corriger, et non comme une réussite ou un échec DMARC. Distinguez également une erreur temporaire de recherche DNS d’un enregistrement malformé. Réessayez une défaillance transitoire du résolveur par un chemin contrôlé, mais n’affirmez pas que le domaine n’a aucune politique tant que le DNS faisant autorité ne peut pas être interrogé de manière fiable.

Vérifier l’alignement SPF et DKIM sur un message réel

DMARC est évalué sur l’authentification du message, pas sur la configuration DNS prise isolément. Pour SPF, comparez le domaine MAIL FROM authentifié au domaine From visible. Pour DKIM, comparez le domaine d= de chaque signature vérifiée avec succès au domaine From visible. L’alignement relaxed accepte des domaines qui partagent le même domaine organisationnel ; l’alignement strict exige des domaines identiques. Un message réussit lorsqu’au moins un identifiant authentifié réussit son mécanisme sous-jacent et est aligné. Par exemple, le return path d’un fournisseur peut faire réussir SPF pour le domaine du fournisseur tout en restant non aligné avec billing.example.test. Si DKIM est vérifié avec d=example.test en alignement relaxed, le message peut tout de même réussir DMARC. Récupérez l’en-tête Authentication-Results brut depuis des comptes destinataires contrôlés, mais interprétez-le dans son contexte : il reflète le résultat du destinataire qui l’a évalué et peut contenir plusieurs sauts ou signatures.

Lire précisément les résultats pass, fail, none et error

Une réussite DMARC signifie qu’un enregistrement de politique s’applique et qu’un identifiant SPF ou DKIM authentifié est aligné sur le domaine d’auteur. Un échec signifie qu’une politique s’applique, mais qu’aucun identifiant authentifié aligné n’existe. None signifie qu’aucune politique applicable n’a été trouvée. Permerror et temperror indiquent des erreurs lors de l’évaluation DMARC ; un message comportant une erreur DNS ne peut être considéré ni comme réussissant ni comme échouant DMARC. Ces résultats n’indiquent pas où le fournisseur de messagerie a placé le message. La RFC 9989 limite explicitement une réussite à la validation de l’autorisation de l’usage du propriétaire de domaine ; elle n’affirme pas que le message est sûr, souhaité, réputé ou digne d’arriver en boîte de réception. Conservez l’acceptation du fournisseur, l’acceptation du serveur de réception, le résultat DMARC, les signaux de plaintes et le placement observé dans des champs distincts des diagnostics et tableaux de bord.

Recenser chaque expéditeur légitime avant l’application stricte

Inventoriez tous les systèmes qui placent le domaine dans le From : applications de production, e-mails d’authentification, avis de facturation, outils de support, plateformes marketing, alertes de supervision, workflows CRM, comptes régionaux et systèmes d’urgence. Pour chaque flux, relevez le domaine From visible, le domaine MAIL FROM, le domaine d= et le sélecteur DKIM, le compte fournisseur, le responsable, la catégorie de message et le volume attendu. Envoyez des messages contrôlés par le chemin de production normal et vérifiez à la fois l’authentification et l’alignement. Les rapports DMARC agrégés peuvent révéler les sources qui utilisent le domaine, mais ils doivent être interprétés et peuvent inclure du trafic transféré ou non autorisé. Commencez par la surveillance tant que l’inventaire est incomplet, puis corrigez les flux légitimes non alignés avant de demander un traitement plus strict aux destinataires. Ne modifiez pas une politique organisationnelle partagée uniquement pour faire passer une application au vert, et ne passez pas à l’application stricte sur la base d’un seul message de test.

Diagnostiquer les échecs courants des e-mails applicatifs

Si aucune politique n’est trouvée, vérifiez la zone DNS et le nom de l’enregistrement avant de modifier la valeur. Si l’enregistrement présente une erreur permanente, ramenez-le à une seule politique valide et vérifiez l’ordre et la syntaxe des balises. Si DKIM échoue, vérifiez que le sélecteur attendu existe, que le fournisseur a bien signé le message testé, que le corps ou les en-têtes signés n’ont pas été modifiés en transit et que le domaine d= vérifié est aligné. Si SPF réussit mais que DMARC échoue, comparez le domaine MAIL FROM au domaine From visible plutôt que de considérer tout pass SPF comme suffisant. Si seuls les e-mails transférés échouent, rappelez-vous que le transfert modifie souvent le chemin de l’enveloppe et peut casser SPF, alors qu’une signature DKIM valide et alignée peut survivre. Si un déploiement provoque des rejets, conservez les en-têtes en échec et la réponse du destinataire, stoppez tout durcissement supplémentaire de la politique et corrigez le flux responsable au lieu d’affaiblir des contrôles d’authentification sans rapport.

Appliquer délibérément les règles d’alignement propres à chaque fournisseur

Les expéditeurs tiers ont besoin d’une configuration qui rattache leurs identifiants authentifiés à un domaine contrôlé par l’organisation. Amazon SES documente deux voies : un domaine MAIL FROM personnalisé aligné pour SPF et un domaine de signature DKIM aligné. Son return path par défaut, qui appartient au fournisseur, peut s’authentifier avec SPF sans être aligné sur le domaine From visible ; DKIM est donc souvent le mécanisme aligné le plus pratique, sauf si un domaine MAIL FROM personnalisé est configuré. D’autres fournisseurs emploient des noms différents pour les return paths, les domaines de bounce, l’authentification de domaine et les identités de signature. Vérifiez le message réellement émis plutôt que de supposer qu’un badge « vérifié » dans un tableau de bord établit DMARC. Les recommandations actuelles de Gmail pour les expéditeurs exigent aussi l’authentification et l’alignement pour le trafic concerné et recommandent le reporting DMARC. Les exigences des destinataires et les fonctionnalités des fournisseurs peuvent évoluer : revérifiez leur documentation officielle au lancement et lors des revues d’incident.

Utilisez les preuves du fournisseur sans les traiter comme un verdict DMARC

SendHQ prend en charge l’envoi depuis un domaine vérifié, les événements de livraison, les suppressions et un tableau de bord web. Utilisez ses informations sur le domaine d’envoi et la livraison pour examiner un flux de messages, puis vérifiez DMARC à partir de l’en-tête Authentication-Results du destinataire et séparez les preuves SPF, DKIM et d’alignement. L’acceptation par le fournisseur et les événements de livraison ne prouvent pas le placement en boîte de réception.

Consigner un résultat de vérification DMARC auditable

Un résultat durable doit contenir le domaine auteur, l’heure de la requête, le résolveur, le nom _dmarc interrogé, le domaine de politique retenu, l’enregistrement exact normalisé, les modes de politique et d’alignement, le statut DNS et le résultat de l’analyse : syntaxe acceptable, permerror ou temperror. Ajoutez une ligne par message contrôlé avec un identifiant de message non sensible, le système d’envoi, le domaine From visible, le domaine SPF authentifié et son résultat, les domaines et sélecteurs DKIM vérifiés, les décisions d’alignement, le résultat DMARC final et le destinataire. Conservez les en-têtes bruts dans un stockage à accès restreint, car ils peuvent exposer des adresses, des détails de routage et des identifiants internes. Associez chaque constat à un responsable et à une date de correction. Revérifiez après l’expiration des TTL DNS, un changement de configuration du fournisseur, une rotation de clés, l’ajout de flux de messages ou un durcissement de la politique. Ces preuves rendent la vérification reproductible et évitent qu’une capture d’écran ou un badge d’outil ne devienne une preuve permanente après un changement de la configuration sous-jacente.

Questions fréquentes

Sources

• RFC 9989 : Domain-Based Message Authentication, Reporting, and Conformance — RFC Editor
• Se conformer au protocole d’authentification DMARC dans Amazon SES — Amazon Web Services
• Consignes pour les expéditeurs d’e-mails — Google
• Déploiement recommandé de DMARC — Google Workspace
• Contrat OpenAPI de SendHQ — SendHQ