Pourquoi générer un enregistrement DMARC ?
DMARC relie SPF et DKIM à une politique que les destinataires appliquent. Il protège l'identité du domaine, améliore la lisibilité des incidents et fournit des rapports utiles. Ce générateur construit un enregistrement propre, prêt à publier, en tenant compte des sous-domaines, des pourcentages d'application et des adresses de rapport.
Mode d'emploi du générateur
Domaine : Renseignez le domaine organisationnel. L'enregistrement sera publié sur
_dmarc.votre-domaine.Politique principale
p: ChoisissezNonepour observer,Quarantinepour mettre en quarantaine,Rejectpour bloquer. Démarrez en None, lisez les rapports, corrigez, puis montez progressivement.Politique sous-domaines
sp: Laissez « hériter » ou fixez une politique différente pour les sous-domaines envoyeurs.Pourcentage d'application
pct: De 1 à 100. Utile pour monter doucement enQuarantineouReject.Rapports agrégés
rua: Une ou plusieurs adressesmailto:séparées par des virgules.
Exemple :mailto:dmarc@exemple.com,mailto:secops@exemple.com
Si vous utilisez une adresse d'un domaine tiers, ce tiers doit vous autoriser via un enregistrement DNS_report._dmarc(exigence DMARC).Rapports judiciaires
ruf(facultatif) : Rapports détaillés d'échec. Peu d'opérateurs les envoient. Attention au volume et aux données sensibles.Alignements
adkimetaspf: Relaxed par défaut. Strict renforce l'identification, utile une fois l'inventaire des flux stabilisé.Options d'échec
fo: 0 par défaut.
Autres valeurs possibles :1générer un rapport si SPF ou DKIM échouedpour DKIM seulementspour SPF seulement
Intervalle
ri: Fréquence des rapports agrégés, en secondes. 86400 équivaut à 24 h.
Cliquez Générer l'enregistrement puis publiez le TXT indiqué sur _dmarc.votre-domaine.
Exemples prêts à l'emploi
Observation complète
_dmarc.exemple.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@exemple.com; adkim=r; aspf=r; ri=86400"
Montée progressive
_dmarc.exemple.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@exemple.com; adkim=r; aspf=r"
Protection stricte (production)
_dmarc.exemple.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@exemple.com; adkim=s; aspf=s; ri=86400"
Publication et vérification
- Publiez un seul enregistrement TXT DMARC sur
_dmarc.votre-domaine. - TTL conseillé 3600 pendant l'ajustement, puis remontez une fois stabilisé.
- Vérifiez la lecture réelle avec vos outils CaptainDNS inspecteur DMARC et contrôle de domaine.
- Suivez les rapports rua quelques jours avant de durcir la politique.
Erreurs fréquentes à éviter
- Deux enregistrements DMARC sur le même nom. Gardez une seule ligne.
- Oublier
mailto:devant les adresses rua/ruf. - Passer directement en
p=rejectsans inventaire des flux légitimes. - Aligner en
strictalors que des sous-domaines ou des services tiers envoient encore avec un autre domaine visible. - Déclarer une adresse de rapport externe sans autorisation
_report._dmarcdu domaine tiers. - Confondre
pctetri. Le premier règle l'application, le second la fréquence des rapports.
Bonnes pratiques de montée en puissance
- Étape 1 :
p=none, rua actif. Cartographiez les sources réelles et corrigez celles qui échouent. - Étape 2 :
p=quarantine, pct 10 puis 50 puis 100. Surveillez les faux positifs. - Étape 3 :
p=reject. Une fois stable, envisagezadkim=setaspf=s. - Posez une politique
spsi vos sous-domaines envoient différemment. - Conservez un journal de changements date, valeur précédente et nouvelle, raison, TTL.
Lecture rapide des rapports
- Rapports agrégés
ruavolumes par source, taux de pass/fail SPF et DKIM, alignements, décision appliquée. - Rapports forensics
rufévénements d'échec unitaires quand pris en charge. À activer avec prudence.
Engagement confidentialité
Les valeurs saisies sont envoyées à l'API CaptainDNS uniquement pour générer la chaîne DMARC. Aucune donnée n'est conservée en clair. Seules des métriques techniques sont journalisées durée de traitement et taille de l'enregistrement pour le suivi de disponibilité.