Générateur d'enregistrement DMARC

Un enregistrement DMARC (RFC 7489) est un unique TXT composé de paires tag=valeur séparées par des points-virgules. Seuls deux tags sont obligatoires ; tous les autres ont une valeur par défaut qui s'applique en leur absence.

• v=DMARC1 - le tag de version, obligatoire, toujours cette valeur exacte, toujours en premier
• p=none|quarantine|reject - obligatoire, la politique appliquée au courrier qui échoue l'alignement SPF ou DKIM pour ce domaine
• sp= - optionnel, une politique distincte pour les sous-domaines ; en son absence, les sous-domaines héritent de p=
• rua=mailto:... - optionnel mais vivement recommandé, l'adresse qui reçoit les rapports agrégés
• ruf=mailto:... - optionnel, l'adresse qui reçoit les rapports forensiques par message
• pct= - optionnel, 100 par défaut, le pourcentage de courrier en échec auquel la politique s'applique
• aspf= et adkim= - optionnels, tous deux par défaut à r (relâché), le niveau de rigueur de l'alignement SPF/DKIM

Le tag de politique est la seule décision qui change réellement la remise du courrier. C'est aussi celle qu'il vaut mieux prendre dans le bon ordre : une politique trop stricte dès le premier jour peut mettre en quarantaine ou rejeter du courrier légitime que personne n'a encore testé.

Le tag pct= permet d'appliquer une politique à seulement une fraction du courrier en échec, sous forme d'un nombre entier de 1 à 100. Les destinataires appliquent p= à ce pourcentage des messages qui échouent l'alignement, et retombent sur un traitement plus léger pour le reste - c'est ainsi qu'une politique quarantine ou reject se déploie progressivement plutôt que de s'activer d'un coup pour tout le courrier.

Omettre pct= équivaut à pct=100 : la politique s'applique à tout le courrier en échec. Un générateur qui inscrit toujours pct=100 explicitement, ou qui omet complètement le tag, produit le même enregistrement effectif - les destinataires traitent un pct= absent comme valant 100, conformément à la RFC 7489.

DMARC sans adresse rua est une politique sans boucle de retour - le propriétaire du domaine n'apprend jamais quels serveurs envoient du courrier en échec d'alignement, ni si un expéditeur légitime est sur le point d'être bloqué.

• rua - rapports agrégés, une synthèse XML quotidienne par fournisseur destinataire, couvrant chaque message évalué pour le domaine. C'est le rapport à mettre en place avant même de toucher au tag de politique.
• ruf - rapports forensiques, un message par échec avec les en-têtes joints. La plupart des grands fournisseurs de messagerie ont arrêté de les envoyer depuis des années pour des raisons de confidentialité, donc un champ ruf vide est normal, pas une erreur.
• Plusieurs adresses sont autorisées pour chaque tag, séparées par des virgules - pratique pour envoyer une copie à une boîte interne et à un service tiers d'analyse de rapports DMARC.
• Chaque adresse a besoin du préfixe mailto: ; une simple adresse email sans ce préfixe n'est pas une syntaxe valide dans l'enregistrement.

Passer SPF ou DKIM ne suffit pas en soi - le domaine authentifié par ce contrôle doit aussi s'aligner avec l'adresse From: visible, et les tags aspf/adkim fixent la rigueur de cette correspondance.

• r (relâché) - le défaut pour les deux tags. Un sous-domaine du domaine From: compte comme aligné : un courrier envoyé depuis news.exemple.fr s'aligne avec une adresse From: sur exemple.fr.
• s (strict) - le domaine authentifié doit correspondre exactement au domaine From:, sans tolérance de sous-domaine.
• aspf et adkim se règlent indépendamment. Un domaine peut avoir un alignement SPF strict avec un alignement DKIM relâché, ou toute autre combinaison.
• L'alignement relâché reste le choix courant car il tolère du courrier envoyé via des sous-domaines (plateformes marketing, services d'emailing transactionnel) sans avoir à ajouter un include SPF ou un sélecteur DKIM pour chacun.

Un enregistrement construit avec p=quarantine, sp= laissé sur "identique à la politique", rua réglé sur une adresse, pct= à 50, et les deux tags d'alignement laissés en relâché, s'affiche sur une seule ligne :

• v=DMARC1; p=quarantine; adkim=r; aspf=r; pct=50; rua=mailto:dmarc-reports@exemple.fr
• L'ordre des tags dans le résultat suit v, p, sp, adkim, aspf, pct, rua, ruf - les destinataires analysent chaque tag par son nom, pas par sa position, donc un ordre différent dans un enregistrement modifié à la main reste tout aussi valide.
• Le tag sp= n'apparaît que si une politique de sous-domaine distincte a été choisie explicitement ; le laisser sur "identique à la politique" omet le tag, puisqu'un sp= absent retombe déjà sur p= pour tous les sous-domaines.
• Une valeur pct= n'a de sens qu'avec p=quarantine ou p=reject ; sous p=none, rien n'est appliqué, donc il n'y a aucune fraction à échelonner.

L'enregistrement se place dans la zone DNS comme un TXT, pas sur le domaine lui-même - le nom d'hôte est toujours _dmarc.votredomaine.com, avec le préfixe underscore et sans les champs de priorité ou de poids qu'exige un enregistrement MX ou SRV.

La plupart des serveurs faisant autorité acceptent la valeur avec ou sans guillemets autour ; il faut vérifier la syntaxe de fichier de zone attendue par l'hébergeur DNS utilisé, car certains suppriment les points-virgules si la valeur n'est pas entre guillemets. Après publication, il faut compter avec le TTL et une éventuelle propagation côté fournisseur avant qu'une nouvelle recherche ne reflète l'enregistrement à jour.