Générateur DMARC

Trois décisions donnent un enregistrement valide. D’abord, la politique (p) : commencez par none pour que les destinataires fassent des rapports sans rien bloquer. Ensuite, une adresse rua : la boîte qui reçoit chaque jour les rapports agrégés montrant qui envoie en votre nom. Enfin, publiez la valeur générée en TXT sur l’hôte _dmarc.votredomaine.com dans votre DNS. Le générateur ci-dessus assemble la chaîne exacte : le seul vrai travail est de choisir la politique et l’adresse de rapport.

Dans le DNS de votre domaine, là où vous le gérez : Cloudflare, GoDaddy, Route 53, registrar ou console DNS de votre MSP. Créez un TXT, mettez _dmarc dans le champ hôte ou nom (certains fournisseurs veulent _dmarc.votredomaine.com en entier), collez la valeur générée et enregistrez. La propagation prend souvent quelques minutes, parfois une heure. Vérifiez ensuite la résolution avec un test DMARC.

Commencez par p=none, sauf si vous connaissez déjà chaque service qui envoie pour votre domaine et avez vérifié leur alignement SPF et DKIM. None est le mode surveillance : rien n’est bloqué, mais les rapports révèlent chaque expéditeur qui utilise votre domaine, y compris les outils qu’un collègue du marketing a souscrits il y a des années. Quand les rapports montrent tout le trafic légitime conforme, passez à quarantine (les échecs vont en spam), puis à reject (les échecs sont refusés). Passer direct à reject sans surveiller, c’est ainsi qu’on bloque ses propres factures.

rua est l’adresse où les destinataires envoient les rapports agrégés : des synthèses XML quotidiennes des IP qui ont envoyé au nom de votre domaine, avec leur résultat SPF, DKIM et alignement. Utilisez une boîte dédiée (dmarc-reports@votredomaine.com) ou, plus pratique, l’adresse d’un service de suivi DMARC, car lire à la main le XML brut de dizaines de destinataires est pénible. C’est ce que Palisade automatise : il collecte les rapports, les traduit en expéditeurs nommés et vous dit quoi corriger.

En général, non. ruf demande des échantillons d’échec par message, mais la plupart des grandes messageries, dont Gmail, n’en envoient pas, par confidentialité : la couverture est faible. Ils peuvent aussi inclure le contenu des messages, ce qui pose des questions de traitement. Vous travaillez en fait avec les rapports agrégés (rua) ; n’ajoutez ruf que pour une enquête précise, avec une boîte prête pour des données sensibles.

Ils fixent à quel point les domaines SPF et DKIM doivent correspondre au domaine From. Souple (par défaut) accepte les sous-domaines : mail.votredomaine.com s’aligne avec votredomaine.com. Strict exige l’égalité exacte. Presque tous les domaines doivent rester en souple : les services légitimes envoient souvent depuis des sous-domaines, et le mode strict les casse pour peu de gain. N’envisagez strict que pour des domaines très contrôlés, avec un seul expéditeur connu.

pct n’applique votre politique quarantine ou reject qu’à un pourcentage du trafic en échec, pour entrer en douceur dans l’application. En pratique, elle a semé la confusion (appliquée de façon inégale) et DMARCbis (la nouvelle norme DMARC publiée comme RFC 9989) la supprime. Pour un déploiement progressif, la voie moderne est none → quarantine → reject, en lisant les rapports à chaque étape, plutôt qu’un échantillonnage en pourcentage.

Le générateur crée l’enregistrement à publier ; le test lit ce que votre domaine publie déjà et l’évalue. Parcours type : générez un enregistrement ici, publiez-le dans le DNS, puis lancez le test pour vérifier qu’il se résout et s’analyse correctement. Si vous auditez un domaine que vous gérez, ou celui d’un client, commencez par le test pour voir l’existant avant de décider quoi changer.