Constructeur d’enregistrement DMARC

Le Générateur d'enregistrement DMARC crée des enregistrements DNS Domain-based Message Authentication, Reporting, and Conformance (DMARC) via une interface interactive qui vous guide à travers tous les tags de politique disponibles. Sélectionnez une politique comme p=reject, configurez les adresses de rapport et obtenez un enregistrement complet tel que v=DMARC1; p=reject; rua=mailto:[email protected] prêt à publier à _dmarc.votredomaine.com.

Comprendre DMARC

DMARC est la couche de politique qui relie SPF et DKIM en un système d'authentification e-mail cohérent. Seul, SPF vérifie si le serveur d'envoi est autorisé. Seul, DKIM vérifie que le message n'a pas été altéré. Mais ni l'un ni l'autre n'indique aux serveurs destinataires quoi faire en cas d'échec des vérifications, et ni l'un ni l'autre n'exige que le domaine authentifié corresponde au domaine de l'en-tête From que les utilisateurs voient réellement. DMARC comble ces deux lacunes : il définit une politique de gestion des échecs et il exige l'alignement des domaines, rendant beaucoup plus difficile pour les attaquants d'usurper votre domaine dans des campagnes de phishing.

Lorsque vous publiez un enregistrement DMARC, vous communiquez trois informations à chaque serveur de messagerie destinataire sur Internet : comment traiter les messages qui échouent à la fois aux vérifications SPF et DKIM (les ignorer, les mettre en quarantaine ou les rejeter), où envoyer des rapports sur les résultats d'authentification pour que vous puissiez surveiller ce qui se passe, et à quel point les domaines authentifiés doivent correspondre à votre domaine d'en-tête From. Sans DMARC, un fraudeur peut envoyer un e-mail qui échoue aux vérifications SPF et DKIM pour votre domaine, mais le serveur destinataire n'a aucune politique lui demandant de rejeter le message -- il pourrait l'accepter et le laisser arriver dans la boîte de réception du destinataire.

L'autre avantage majeur de DMARC est le reporting. Lorsque vous définissez une adresse rua, les serveurs destinataires vous envoient des rapports XML quotidiens résumant chaque message qu'ils ont vu se déclarant provenir de votre domaine, avec les résultats SPF et DKIM pour chacun. Ces rapports révèlent les expéditeurs non autorisés que vous ne connaissiez pas -- qu'il s'agisse de fraudeurs abusant de votre domaine, de services légitimes que vous avez oublié d'ajouter à votre enregistrement SPF, ou de serveurs de transfert cassant l'authentification. Cette visibilité est essentielle avant de renforcer votre politique, car passer à p=reject sans comprendre votre écosystème e-mail bloquera presque certainement certains e-mails légitimes.

Comment créer un enregistrement DMARC

1. Choisissez votre politique (p=) : none pour la surveillance, quarantine pour le dossier spam, ou reject pour bloquer les échecs
2. Définissez éventuellement une politique de sous-domaine (sp=) si les sous-domaines nécessitent un traitement différent
3. Définissez le pourcentage (pct=) pour appliquer progressivement la politique (ex. : commencez à 10 %)
4. Saisissez l'adresse e-mail de rapport agrégé (rua=) pour recevoir des rapports XML quotidiens
5. Saisissez éventuellement l'adresse e-mail de rapport forensique (ruf=) pour les rapports d'échecs individuels
6. Configurez les modes d'alignement (aspf=, adkim=) pour une correspondance stricte ou relâchée
7. Copiez l'enregistrement généré et publiez-le comme enregistrement TXT à _dmarc.votredomaine.com

Exemples d'enregistrements DMARC

Référence des tags DMARC

Quand utiliser le générateur d'enregistrement DMARC

• Démarrage de l'authentification e-mail sur un domaine sans politique DMARC existante
• Déploiement progressif de DMARC -- passage de p=none à quarantine puis reject au fil des semaines
• Configuration des rapports DMARC pour gagner en visibilité sur les entités envoyant des e-mails au nom de votre domaine
• Définition de politiques de sous-domaines distinctes lorsque les sous-domaines ont des exigences de messagerie différentes
• Audit des paramètres d'alignement pour choisir entre correspondance stricte et relâchée pour SPF et DKIM
• Conformité réglementaire imposant l'application de DMARC (PCI DSS, NIST, directives gouvernementales)

Fonctionnement de l'authentification DMARC

Le flux d'authentification

Lorsqu'un serveur destinataire reçoit un e-mail de votre domaine, il évalue DMARC dans cet ordre :

1. Vérification SPF : l'IP d'envoi correspond-elle à l'enregistrement SPF ? Le domaine RFC5321.MailFrom est-il aligné avec le domaine de l'en-tête From ?
2. Vérification DKIM : existe-t-il une signature DKIM valide ? Le domaine signataire (d=) est-il aligné avec le domaine de l'en-tête From ?
3. Application de DMARC : si l'un ou l'autre SPF ou DKIM passe et est aligné, DMARC réussit. Si les deux échouent ou qu'aucun n'est aligné, la politique DMARC s'applique.

Alignement relâché vs. strict

• Relâché (aspf=r, adkim=r) : le domaine authentifié et le domaine From doivent partager le même domaine organisationnel. Exemple : mail.example.com s'aligne avec example.com.
• Strict (aspf=s, adkim=s) : le domaine authentifié doit correspondre exactement au domaine From. mail.example.com ne s'aligne pas avec example.com.

L'alignement relâché est le mode par défaut et convient à la plupart des organisations. L'alignement strict offre une protection renforcée mais peut interrompre les flux de messagerie légitimes provenant de sous-domaines.

Stratégie de déploiement recommandée

Semaines 1-2 :  v=DMARC1; p=none; rua=mailto:[email protected]
                -> Surveillez les rapports, identifiez tous les expéditeurs légitimes

Semaines 3-4 :  v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
                -> Mettez en quarantaine 10 % des échecs, surveillez les faux positifs

Semaines 5-6 :  v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]
                -> Augmentez à 50 %

Semaines 7-8 :  v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]
                -> Commencez à rejeter 25 % des échecs

Semaine 9+ :    v=DMARC1; p=reject; rua=mailto:[email protected]
                -> Application complète

Déploiement DMARC en pratique

Le plus grand risque dans le déploiement DMARC est de passer à p=reject trop rapidement. De nombreuses organisations publient un enregistrement DMARC avec p=none, collectent les rapports pendant une semaine ou deux, puis passent directement à p=reject parce que les rapports semblent propres. Le problème est que certains flux e-mail légitimes ne se produisent que périodiquement -- newsletters mensuelles, notifications de facturation trimestrielles, rappels de renouvellement annuels -- et peuvent ne pas apparaître dans une courte fenêtre de reporting. Le tag pct existe précisément pour ce scénario : il vous permet d'appliquer votre politique sur seulement un pourcentage des messages en échec, afin de détecter les problèmes à l'échelle sans bloquer tous vos e-mails si quelque chose ne va pas.

Une surprise courante lors du déploiement DMARC est de découvrir combien de services envoient des e-mails en votre nom. Le marketing envoie via Mailchimp, les tickets support viennent de Zendesk, les factures passent par QuickBooks, les réinitialisations de mot de passe viennent d'Auth0, et les alertes système transitent par PagerDuty. Chacun de ces services doit soit passer le contrôle SPF (en étant inclus dans votre enregistrement SPF), soit passer le contrôle DKIM (en signant avec une clé alignée sur votre domaine). La phase de surveillance p=none est votre opportunité d'identifier tous ces services avant le début de l'application. Utilisez les rapports agrégés pour construire un inventaire complet de vos services d'envoi d'e-mails.

La politique de sous-domaine (sp=) mérite une réflexion attentive. Par défaut, les sous-domaines héritent de la politique du domaine parent. Si vous définissez p=reject sur example.com, cela s'applique également à mail.example.com, app.example.com et tous les autres sous-domaines. Si certains sous-domaines envoient des e-mails via une infrastructure différente ou ne sont pas encore configurés pour DKIM, définissez sp=none ou sp=quarantine pour vous donner de la marge afin de travailler sur l'authentification des sous-domaines séparément du domaine principal.

Questions fréquentes

Où publier l'enregistrement DMARC dans le DNS ?

Les enregistrements DMARC sont toujours publiés comme enregistrement TXT à _dmarc.votredomaine.com. Par exemple, si votre domaine est example.com, l'enregistrement se place à _dmarc.example.com. Il s'agit d'un emplacement fixe défini par la spécification DMARC -- il n'y a aucune flexibilité dans le nommage.

Quelle est la différence entre les rapports rua et ruf ?

Le tag rua spécifie la destination des rapports agrégés -- ce sont des résumés XML quotidiens montrant les résultats d'authentification pour tous les messages. Le tag ruf spécifie les rapports forensiques -- des rapports détaillés sur les messages individuels ayant échoué à l'authentification. De nombreux fournisseurs ne prennent en charge que les rapports agrégés en raison des préoccupations de confidentialité liées aux données forensiques. Commencez avec rua uniquement ; ajoutez ruf si vous avez besoin d'une investigation détaillée des échecs.

Puis-je envoyer les rapports DMARC à une adresse e-mail sur un autre domaine ?

Oui, mais le domaine destinataire doit publier un enregistrement d'autorisation DNS. Si votre domaine est example.com et que les rapports sont envoyés à [email protected], alors monitor.com doit publier un enregistrement TXT à example.com._report._dmarc.monitor.com avec la valeur v=DMARC1. Cela empêche les abus où quelqu'un publie un enregistrement DMARC dirigeant un flux de rapports vers une adresse e-mail arbitraire.

Que signifie pct=25 en pratique ?

Cela signifie que seuls 25 % des messages échouant à DMARC verront la politique appliquée. Les 75 % restants sont traités comme si la politique était none (surveillés mais sans action). Les serveurs destinataires utilisent ce pourcentage de manière probabiliste. Cela vous permet d'augmenter progressivement l'application et d'observer l'impact avant de passer à l'application complète à pct=100 (qui est la valeur par défaut lorsque pct est omis).

Comment lire les rapports agrégés DMARC ?

Les rapports agrégés DMARC sont des fichiers XML compressés en gzip ou zip. Ils contiennent des données sur chaque message reçu de votre domaine : IP d'envoi, résultat SPF, résultat DKIM et la disposition (none, quarantine ou reject). La lecture du XML brut est impraticable à grande échelle. La plupart des administrateurs utilisent un service de reporting DMARC qui analyse le XML et présente des tableaux de bord montrant les taux de réussite/échec d'authentification, les expéditeurs non autorisés et les problèmes d'alignement.

DMARC affecte-t-il le transfert d'e-mails ?

Oui. Le transfert d'e-mails est l'un des plus grands défis avec l'application de DMARC. Lorsqu'un message est transféré par un intermédiaire (comme une liste de diffusion ou une adresse de transfert universitaire), l'IP d'envoi change, ce qui casse SPF. Si le serveur de transfert modifie également le message (ajout d'un pied de page, modification de l'objet), DKIM est aussi cassé. Avec p=reject, le message transféré sera rejeté par le serveur du destinataire final. Les solutions incluent ARC (Authenticated Received Chain), que certains destinataires supportent pour préserver l'authentification à travers le transfert.

Outils associés

• Générateur d'enregistrement SPF - Créer des enregistrements SPF avec la syntaxe correcte
• Vérificateur de longueur d'enregistrement SPF - Vérifier la longueur et les limites de résolutions des enregistrements SPF
• Formateur d'enregistrement TXT DKIM - Formater les enregistrements DKIM avec le bon découpage entre guillemets
• Dédoublonneur d'enregistrements DNS - Trouver et supprimer les enregistrements DNS en double
• Linter de fichier de zone - Vérifier les fichiers de zone pour les erreurs de syntaxe et les doublons