Maintenant que DMARC est largement déployé, voici quelques astuces utiles à avoir dans votre manche lorsque vous recherchez leurs enregistrements DNS pertinents. Les résolutions du DMARC impliquent à la fois des résolutions du FPS et du DKIM. Souvent, les administrateurs informatiques devront résoudre les défaillances SPF et/ou DKIM pour déterminer pourquoi un enregistrement DMARC échoue également à la validation. Sous Windows, un moyen rapide de vérifier les enregistrements DMARC est d’utiliser nslookup à partir de la bonne vieille invite de commande. Cliquez sur « Touche du logo Windows + R » pour faire apparaître la fenêtre de commande Exécuter et tapez cmd, appuyez sur Entrée et votre invite de commande apparaîtra. Notez que nslookup n’est pas exclusif à Windows, c’est juste que l’exemple que je décrit est fait sous Windows et que nslookup est l’outil de requête par défaut.

Examinons la capture d’écran suivante en détail :

Notez que le texte de couleur rouille ci-dessus n’est fourni qu « à des fins explicatives et a été ajouté par moi après avoir pris la capture d » écran.

Passons-les en revue étape par étape.

1. Lancez nslookup

2. Bien que vous puissiez faire toutes les recherches DNS à l’aide de votre serveur DNS local, dans cet exemple, je spécifie le serveur DNS que j’aimerais interroger comme 8.8.8.8 (un serveur DNS public de Google). Souvent, lorsque vous résolvez des problèmes DNS pour vos propres domaines, il est utile d’interroger des serveurs DNS externes, car vos serveurs DNS internes peuvent ne pas refléter ce que le monde voit. La commande est serveur 8.8.8.8

3. Tous les enregistrements SPF/DKIM et DMARC sont des enregistrements TXT, donc je précise ici que je veux des réponses d’enregistrements TXT. La commande est set type=TXT

4. J’interroge les enregistrements TXT pour gmail.com. Ici vous voyez la réponse « v=sp1 redirect=_spf.google.com ». Vous pouvez rechercher davantage les enregistrements TXT SPF de _spf.google.com en tapant simplement _spf.google.com. Expliquer les enregistrements SPF dépasse le cadre de cet article, mais il existe plusieurs validateurs SPF en ligne (p. ex. http://www.kitterman.com/spf/validate.html) si vous souhaitez analyser votre dossier SPF en détail. En bref, compte tenu de l’adresse IP du serveur de messagerie qui se connecte, en examinant de manière récursive l’enregistrement SPF du domaine du chemin de retour (MAIL FROM), on vérifie la présence de l’adresse IP dans la liste des adresses IP autorisées dans les champs ip4 ou ip6 de l’enregistrement SPF. La capture d’écran suivante montre cette recherche récursive pour gmail.com :

Une vérification SPF est valide si l’adresse IP du MTA de connexion figure dans la liste des adresses autorisées. Revenons maintenant à la capture d’écran précédente et continuons à suivre les étapes.

[cta id= »18654″]

5. Ici, j’interroge l’enregistrement DKIM pour gmail.com. Pour ce faire, on spécifie le sélecteur ajouté à _domainkey.gmail.com. Dans cet exemple, le sélecteur est 20161025. La requête est donc faite pour 20161025._domainkey.gmail.com. Les sélecteurs se trouvent dans les enregistrements DKIM qui se trouvent dans les en-têtes des courriels. La signature DKIM gmail que j’ai utilisée pour cet exemple était :

Signature DKIM : v=1; a=rsa-sha256; c = détendu/détendu;

d=gmail.com; s=20161025;

h=MIME-version :en-réponse-à :références :de :date :message-id :sujet :à;

bh=JWVD5+eW+yPgYlj8T/c7+8MGFAiHueou4sunWzvtl2U=;

b=tRh2dTdfC5zKQB76UDl0c7g0Ld9FJlYbSc95JzVHOz4DdNfjIj/2rvN7YzuHILFM0L

OO1LGCq5kVK0g1vwAABV8KGcYl/LFD+bC7gu4AHuXeM282CCKDHsemF7AE/mCTNL3VPe

j7YcXpIe+AZwvF/A8+RdDmvcWKEpwZomfvcyGTo5CDa0LeAAiliwE+jsN5uLIlwVg0fA

ELfdkXzzCY1mg8g/HSnvx4+NCypiCdkQXkyTeqw6jbH8EdcGomHe9sTSyxUKOS2TbvKs

Snin4uQd/0aaiIWPc5/cC6f1pHeXHpNzRm/pIWBVjBl3mOd5MtNUcvdlGuY1pFUYnUW+

3VRQ==

6. Notez que la partie s=20161025 ci-dessus est le sélecteur utilisé pour faire la requête. Le résultat de la requête nous donne la clé publique (champ p=) qui peut être utilisée pour déchiffrer le hachage fourni dans la signature DKIM afin que l’on puisse valider que les en-têtes et le corps spécifiés dans l’en-tête DKIM n’ont pas été falsifiés.

7. Enfin, nous demandons la politique DMARC. Cela se fait simplement en préposant _dmarc au domaine gmail.com, pour obtenir _dmarc.gmail.com. Le champ p= est intéressant ici. p peut être aucun, rejeter ou mettre en quarantaine. « Aucun » signifie ne rien faire en cas d’échec de validation DMARC, c’est-à-dire laisser passer le courriel. Rejeter signifie ne pas transmettre le message. « quarantaine » signifie envoyer le message à la quarantaine des utilisateurs finaux. Pour qu’une validation DMARC réussisse, les validations SPF et/ou DKIM doivent réussir et le domaine de l’un ou l’autre des algorithmes de passage (domaine du chemin de retour (MAIL FROM) pour SPF, domaine spécifié dans le champ d= de la signature DKIM pour DKIM) doit s’aligner avec l’en-tête du domaine. Les alignements peuvent être stricts ou assouplis selon la présence des champs adkim= et aspf=. Si ces valeurs sont s, cela signifie qu’un alignement strict est nécessaire (c’est-à-dire que les domaines doivent correspondre exactement). S’il s’agit de valeurs r (par défaut), les sous-domaines peuvent également correspondre aux domaines. Les enregistrements DMARC sont généralement assez simples, mais avec seulement un champ p= et un champ rua. Le champ rua est pour spécifier l’adresse courriel où les rapports quotidiens doivent être envoyés. La plupart des autres champs restants sont destinés à spécifier les types et la fréquence des rapports que l’adresse électronique rua s’attend à recevoir.

modusGate est une solution de sécurité des courriels primée qui protège désormais les utilisateurs à l’aide de DMARC. Contactez-nous pour en savoir plus.