Outils gratuits

Générateur d’enregistrement DMARC

Écrivez l’enregistrement DMARC de votre domaine réglage par réglage : la politique, la part des e-mails concernés, où partent les rapports et avec quelle rigueur SPF et DKIM doivent correspondre. Commencez en p=none, puis resserrez.

L’enregistrement est construit dans votre navigateur : rien de ce que vous saisissez ne nous est envoyé.

DMARC dit aux destinataires quoi faire d’un e-mail qui prétend venir de votre domaine mais échoue à SPF et à DKIM, et où envoyer leurs rapports quotidiens.

Réglage hérité : pct (RFC 7489)

Vérifier l’enregistrement une fois publié Générateurs CAA, MTA-STS et security.txt

Ce qu’écrit le générateur

La politique et son déploiement
p= none, quarantine ou reject ; sp= pour les sous-domaines quand elle doit différer ; et t=y, le mode test de la RFC 9989, pendant que vous essayez une politique plus stricte : les destinataires qui la suivent appliquent la politique un cran plus bas (reject comme quarantine, quarantine comme none), et ceux encore sur la RFC 7489 ignorent t= et l’appliquent entièrement. pct, la part des e-mails de l’ancienne norme, est rangé à part comme réglage hérité.
Les adresses de rapports
rua= pour les rapports agrégés quotidiens et ruf= pour les rapports d’échec, chacune écrite en adresse mailto:, comme l’exigent les destinataires.
L’alignement
adkim= et aspf= n’apparaissent que si vous choisissez strict : souple est la valeur par défaut et reste implicite pour garder l’enregistrement court.
Une alerte pour les rapports envoyés ailleurs
Quand une adresse de rapports est sur un autre domaine, le générateur indique l’enregistrement d’autorisation que ce domaine doit publier, sans quoi les destinataires n’envoient rien.
Le bon nom
L’enregistrement se place à _dmarc.<votre domaine> ; le générateur affiche ce nom avec votre domaine.

Comment déployer DMARC

Semaine 0 : p=none avec rua
Publiez l’enregistrement et lisez les rapports agrégés : ils listent chaque serveur qui envoie des e-mails au nom de votre domaine.
Semaines 2 à 4 : corrigez vos expéditeurs
Chaque source légitime doit passer SPF ou DKIM avec votre propre domaine. Configurez DKIM pour chaque service, ou SPF avec un return-path personnalisé.
Puis p=quarantine
Les e-mails falsifiés partent en indésirables. Surveillez les rapports deux à quatre semaines : rien de légitime ne doit échouer.
Puis p=reject
Les e-mails falsifiés sont refusés. Continuez à lire les rapports : un service ajouté plus tard y apparaît en premier.

Erreurs à éviter en écrivant un DMARC

Un enregistrement DMARC est court, mais quelques erreurs bloquent vos propres e-mails ou vous laissent aveugle. Les voici, avec la façon de les éviter.

p=reject dès le premier jour

Pourquoi. Lettres d’information, factures ou support pas encore alignés sont refusés d’un coup, et vous l’apprenez par vos clients.

Correction. Commencez en p=none avec une adresse rua, et n’avancez que quand les rapports montrent toutes les sources légitimes en réussite.

L’enregistrement au mauvais nom

Pourquoi. Publié sur le domaine lui-même, ou en _dmarc.exemple.fr.exemple.fr parce que l’interface ajoute la zone : les outils disent alors « No DMARC record found ».

Correction. Nommez-le seulement _dmarc ; l’interface ajoute le domaine. Vérifiez-le avec le vérificateur DMARC après publication.

Une adresse de rapports sans mailto:

Pourquoi. rua=dmarc@exemple.fr n’est pas valide : les destinataires n’envoient aucun rapport.

Correction. Écrivez rua=mailto:dmarc@exemple.fr. Le générateur ajoute mailto: pour vous.

Des rapports vers un autre domaine sans son autorisation

Pourquoi. Les destinataires n’envoient des rapports vers un autre domaine que s’il a publié <votre domaine>._report._dmarc.<son domaine> : sinon ils sont abandonnés sans bruit.

Correction. Utilisez une adresse de votre propre domaine, ou un service qui publie l’enregistrement d’autorisation pour vous.

Rester en p=none pendant des années

Pourquoi. L’enregistrement existe et les rapports arrivent, mais les e-mails falsifiés sont toujours distribués : les outils signalent « DMARC policy not enabled ».

Correction. Quand les rapports sont propres, passez à quarantine, puis à reject. Perimetry Cloud vous dit quand chaque étape est sans risque.

Un alignement strict trop tôt

Pourquoi. adkim=s ou aspf=s fait échouer les services qui signent ou envoient avec un sous-domaine, comme mail.exemple.fr, alors qu’ils sont bien à vous.

Correction. Gardez l’alignement souple jusqu’à ce que les rapports montrent que chaque source utilise le domaine exact.

Questions

Où publier l’enregistrement DMARC ?

En enregistrement TXT nommé _dmarc sur votre domaine ; la plupart des interfaces DNS ajoutent elles-mêmes le domaine au nom.

Quelle adresse doit recevoir les rapports ?

Une boîte que vous, ou un outil, lirez : les rapports agrégés sont des fichiers XML compressés, plusieurs par jour pour un domaine actif. Notre lecteur de rapports DMARC les ouvre dans votre navigateur, et Perimetry Cloud peut les recevoir et les lire chaque jour.

Faut-il demander les rapports d’échec (ruf) ?

C’est facultatif. Peu de destinataires en envoient encore, et ils peuvent contenir des extraits de messages et des adresses e-mail, donc des données personnelles. Les rapports agrégés suffisent pour déployer DMARC.

Combien de temps avant de passer à p=reject ?

En général quatre à huit semaines en tout : deux à quatre en none, puis deux à quatre en quarantine, tant que les rapports ne montrent aucune source légitime en échec.

L’enregistrement est-il construit sur vos serveurs ?

Non, dans votre navigateur. Rien de ce que vous saisissez ne nous est envoyé.