Configuration DMARC, politique et rapports

1. Vue d’ensemble du bloc DMARC Configuration

Cette ligne de votre rapport DNSprobe confirme qu’un enregistrement DMARC a été trouvé, en affiche la valeur brute et fournit un court résumé des réglages principaux.

Pourquoi c’est important

De nombreux grands fournisseurs de boîtes aux lettres s’attendent désormais à trouver un enregistrement DMARC. Il contribue à protéger votre marque contre l’usurpation et vous donne de la visibilité sur les envois effectués avec votre domaine.

Comment lire ce bloc

Vérifiez que le nom d’hôte est _dmarc.votredomaine, que la valeur commence par v=DMARC1 et que la politique globale (none, quarantine ou reject) correspond à ce que vous souhaitez. DNSprobe affiche aussi votre « vrai » DMARC une fois les valeurs par défaut appliquées.

Bonnes pratiques générales

• Publier un seul enregistrement DMARC par domaine, sur l’hôte _dmarc.
• Passer progressivement de p=none (surveillance) à p=quarantine puis p=reject une fois SPF et DKIM correctement configurés.
• Garder l’enregistrement lisible afin de pouvoir le vérifier rapidement dans des outils comme DNSprobe.

2. Résumé de la politique (p, sp, pct, alignement)

Le bloc Policy summary de votre rapport répond à trois questions : que faire des messages en échec, que faire pour les sous-domaines et à quel pourcentage de trafic la politique s’applique.

Pourquoi la politique est importante

Ces paramètres déterminent à quel point les serveurs de réception doivent être stricts avec les messages qui ne s’alignent pas sur votre SPF ou votre DKIM, pour le domaine principal comme pour ses sous-domaines.

Comment DNSprobe interprète la politique

DNSprobe lit les balises p, sp et pct et les traduit en une phrase lisible comme « Politique : reject; Politique des sous-domaines : reject; Pourcentage appliqué : 100% ».

Bonnes pratiques pour la politique DMARC

• Commencer avec p=none et pct=100 pour collecter des rapports sans impacter la délivrabilité.
• Une fois l’alignement SPF/DKIM confirmé, passer à p=quarantine, puis éventuellement à p=reject.
• Utiliser sp uniquement si vous avez réellement besoin d’une politique différente pour les sous-domaines, sinon les laisser hériter de p.

3. Paramètres de rapports (rua, ruf, fo, ri, rf)

La section Report settings indique où sont envoyés les rapports agrégés (rua) et les rapports forensiques (ruf), ainsi que le comportement souhaité pour les rapports d’échec.

Pourquoi les rapports DMARC sont utiles

Les rapports agrégés permettent de voir quels IP et fournisseurs envoient du courriel pour votre domaine et à quelle fréquence les messages échouent. Les rapports forensiques peuvent fournir des exemples détaillés des messages en échec.

Comment DNSprobe affiche la configuration de rapports

DNSprobe liste vos adresses rua et ruf en mailto:, les options fo et l’intervalle ri, et met en évidence les cas où aucun rapport ne sera envoyé faute de balises configurées.

Bonnes pratiques pour les rapports DMARC

• Toujours configurer au moins une adresse rua qui pointe vers une boîte ou un service d’analyse DMARC que vous contrôlez.
• Utiliser fo=1 si vous souhaitez une meilleure visibilité sur les échecs, en gardant à l’esprit le volume de rapports supplémentaire.
• N’activer ruf que si vous en avez réellement besoin et que vous pouvez gérer les implications en matière de confidentialité et de protection des données.

4. Balises DMARC parsées dans le rapport

Le tableau Parsed DMARC tags montre chaque balise, sa valeur brute et une courte description pour vérifier rapidement que toutes les options sont définies comme prévu.

Comment DNSprobe construit le tableau des balises

Après avoir parsé la chaîne DMARC, DNSprobe applique les valeurs par défaut lorsque nécessaire et affiche un tableau en trois colonnes Tag, Value et Description pour v, p, sp, rua, ruf, fo, pct, adkim, aspf, ri et rf.

Comment utiliser ce tableau efficacement

• Repérer les valeurs par défaut inattendues, par exemple un alignement relaxed ou un pct inférieur à 100%.
• Confirmer que les adresses de rapport et les modes d’alignement correspondent à votre stratégie DMARC.
• Comparer le tableau parsé avec l’interface de votre fournisseur DNS pour déceler les fautes de frappe ou les valeurs tronquées.

5. Balises DMARC et valeurs possibles

Ce tableau de référence résume les balises DMARC les plus courantes, indique si elles sont obligatoires, leur rôle, les valeurs autorisées et le comportement lorsqu’elles sont omises.

Tous les fournisseurs n’implémentent pas l’ensemble des options de rapport, mais rester dans ces valeurs supportées assure une bonne compatibilité globale.

Un enregistrement DMARC complet ressemble à ceci :
v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; ruf=none; fo=0; pct=100; adkim=s; aspf=s; ri=604800; rf=afrf;

Sous sa forme la plus simple, un enregistrement DMARC est :
v=DMARC1; p=none

6. Guide d’interprétation rapide

Cette section ajoute des vérifications très pratiques (style “inspector”) : validité du record, valeurs par défaut, alignement, comportement des sous-domaines, reporting et erreurs fréquentes.

1) Validité du record et emplacement DNS

DMARC doit être publié en TXT sur l’hôte _dmarc du domaine à protéger. Si le record est mal formé, plusieurs receveurs l’ignorent complètement.

• Nom d’hôte : _dmarc.votredomaine
• La valeur doit commencer par : v=DMARC1 (et ce tag doit être le premier).
• Un seul record DMARC par domaine (plusieurs records peuvent invalider DMARC).

Exemple de record :

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Garde la chaîne lisible (séparateurs clairs, format cohérent). C’est beaucoup plus facile de repérer une typo.

2) Comportement de la politique : p, sp et pct

Ces tags définissent quoi faire lorsqu’un message échoue DMARC (authentification + alignement), si ce comportement s’applique aux sous-domaines, et à quel pourcentage du trafic.

• p=none : monitoring seulement (pas d’application stricte).
• p=quarantine : traiter comme suspect (souvent spam/indésirables).
• p=reject : refuser le message côté receveur.
• pct contrôle le pourcentage d’application (surtout pertinent pour quarantine/reject).

3) Alignement : adkim et aspf (relaxed vs strict)

L’alignement répond à une question simple : est-ce que le domaine qui authentifie correspond au domaine visible dans From: ? En relaxed, un match “organisationnel” peut suffire; en strict, il faut un match exact.

• adkim contrôle l’alignement DKIM (d= vs From:).
• aspf contrôle l’alignement SPF (MailFrom/Return-Path vs From:).

En pratique, relaxed est très courant. Strict offre un contrôle plus serré, mais demande une infrastructure d’envoi plus disciplinée.

4) Sous-domaines et comportement “organisationnel”

DMARC est évalué sur le domaine exact dans From:. Si ce domaine n’a pas de record DMARC, les receveurs peuvent appliquer le DMARC du domaine organisationnel, selon les règles de suffixes publics.

• sp définit une politique dédiée aux sous-domaines; sinon ils héritent de p.
• Si tu envoies depuis des sous-domaines (news.votredomaine, billing.votredomaine), planifie-les dans ton déploiement DMARC.
• Sois cohérent : évite des politiques “surprises” sur des sous-domaines sans intention claire.

5) Reporting : rua, ruf, fo, ri et rf

Les tags de reporting contrôlent où envoyer les rapports agrégés (rua) et, optionnellement, des rapports forensiques/échecs (ruf), ainsi que le niveau de détail demandé.

• rua : rapports agrégés (souvent les plus utiles et les plus supportés).
• ruf + fo : rapports forensiques/échecs (support variable; enjeux de confidentialité/volume).
• ri : intervalle demandé en secondes, mais plusieurs receveurs envoient au plus une fois par jour.

6) Adresses de rapports externes : autorisation DNS requise

Quand rua/ruf pointe vers un autre domaine (ex. un service d’analyse DMARC), ce domaine de destination doit généralement publier un TXT d’autorisation. Sans cela, certains receveurs refuseront d’envoyer des rapports à cette adresse externe.

Exemple d’enregistrement d’autorisation :

example.org._report._dmarc.sample.net TXT "v=DMARC1;"

Ton fournisseur DMARC indique normalement le nom d’hôte et la valeur exacte à publier pour l’autorisation “external destination”.

7) Erreurs fréquentes à éviter

La plupart des problèmes DMARC viennent de petits détails DNS ou de syntaxe. Voici les premiers points à vérifier :

• Publier plus d’un record DMARC TXT à _dmarc (ça peut invalider DMARC).
• v=DMARC1 pas en premier, ou mauvaise casse (DMARC1 doit être exact).
• Points-virgules manquants ou séparateurs qui cassent le parsing.
• Utiliser des adresses de rapports non contrôlées (ou oublier l’autorisation externe).
• Passer à reject avant que toutes les sources légitimes soient alignées SPF/DKIM.

7. Tester les enregistrements DMARC manuellement depuis votre propre terminal

La section DMARC de DNSprobe lit l’enregistrement TXT situé sur _dmarc.votredomaine et analyse les balises telles que la politique (p), la politique pour les sous-domaines (sp), les adresses de rapports (rua/ruf) et les modes d’alignement (adkim/aspf). Vous pouvez consulter l’enregistrement DMARC brut depuis un terminal en interrogeant l’enregistrement TXT du sous-domaine _dmarc.

Linux : utiliser dig (outils BIND)

Sur la plupart des distributions Linux, la commande dig est fournie par le paquet d’outils BIND. Les commandes ci-dessous interrogent l’enregistrement TXT DMARC de votre domaine puis se concentrent sur la ligne qui commence par v=DMARC1 :

                dig _dmarc.example.com TXT
                dig _dmarc.example.com TXT +short
    
                # Optionnel : filtrer les enregistrements TXT pour n’afficher que la politique DMARC (la ligne qui commence par v=DMARC1)    
                dig _dmarc.example.com TXT | grep "v=DMARC1"
        

macOS : utiliser dig avec les outils intégrés

macOS inclut dig dans ses outils en ligne de commande. Ouvrez Terminal et exécutez les mêmes commandes que sous Linux pour lister l’enregistrement TXT DMARC et isoler la ligne de politique qui commence par v=DMARC1 :

                dig _dmarc.example.com TXT
                dig _dmarc.example.com TXT +short
    
                # Optionnel : filtrer les enregistrements TXT pour n’afficher que la politique DMARC (la ligne qui commence par v=DMARC1)    
                dig _dmarc.example.com TXT | grep "v=DMARC1"
        

Windows : utiliser nslookup

Sous Windows, l’outil historique nslookup permet d’interroger les enregistrements TXT sur le sous-domaine _dmarc. Depuis une fenêtre Invite de commandes ou PowerShell, vous pouvez récupérer la politique DMARC principale et, si nécessaire, tester un enregistrement DMARC spécifique à un sous-domaine :

                nslookup -type=TXT _dmarc.example.com
    
                REM Optionnel : interroger un enregistrement DMARC spécifique comme _dmarc.sub.example.com si vous définissez une politique différente pour ce sous-domaine    
                nslookup -type=TXT _dmarc.sub.example.com
        

Important : n’interrogez que les enregistrements DMARC de domaines que vous possédez ou que vous êtes autorisé à analyser. Des requêtes automatisées et répétées vers des domaines tiers sans autorisation peuvent être considérées comme du trafic abusif par certains fournisseurs.