Dernière mise à jour : juillet 2026
En bref : après ce guide, ton domaine chez checkdomain publie un enregistrement DMARC qui indique aux serveurs destinataires quoi faire des e-mails non authentifiés — et te montre via des rapports qui envoie en ton nom.
Prérequis
- Un domaine chez checkdomain avec les serveurs de noms checkdomain actifs
- SPF et DKIM doivent être configurés d’abord — checkdomain souligne lui-même qu’« outre DMARC, une entrée SPF valide et une entrée DKIM sont souvent nécessaires aussi »
Qu’est-ce que DMARC ?
DMARC (Domain-based Message Authentication, Reporting & Conformance) combine SPF et DKIM en une politique applicable. C’est un enregistrement TXT sous le sous-domaine _dmarc (par ex. _dmarc.example.com). Tu y définis deux choses : **ce qu’**un destinataire doit faire des e-mails qui échouent à la vérification (la politique p), et où il t’envoie des rapports (l’adresse rua).
Les rapports sont la partie astucieuse : via rua, tu reçois quotidiennement des rapports agrégés sur les serveurs qui envoient en ton nom — légitimes comme falsifiés. C’est précisément ce qui rend possible le chemin vers une application sûre.
Le point de départ chez checkdomain
checkdomain ne crée pas DMARC automatiquement — les entrées DMARC ne sont pas créées par défaut. Tu saisis l’enregistrement toi-même sous forme d’entrée TXT dans les Réglages pro de la gestion des serveurs de noms (au même endroit que l’enregistrement SPF).
Le chemin sûr : none → quarantine → reject
Tu ne passes pas DMARC en mode applicatif d’emblée. Les trois niveaux de politique sont une rampe :
p=none— observer, ne rien bloquer. Tu commences ici et collectes des rapports.p=quarantine— les e-mails suspects finissent dans les spams. Éventuellement avecpct=pour une partie seulement, afin de tester prudemment.p=reject— les e-mails non authentifiés sont rejetés. L’objectif.
Ne passe à l’étape suivante que lorsque les rapports montrent que toutes tes sources d’envoi légitimes passent SPF/DKIM. Sinon, tu bloques tes propres e-mails.
Guide étape par étape
1. Commencer avec p=none
Commence par l’enregistrement d’observation :
v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de
L’adresse rua est la boîte mail (ou le service) qui reçoit les rapports agrégés. Pour l’analyse, un moniteur DMARC comme MARCo vaut la peine — il rend lisibles les rapports XML quotidiens et te montre quelles sources ne sont pas encore proprement authentifiées.
2. Créer l’entrée TXT dans les réglages pro
Ouvre l’espace client, clique sur Domaines, ouvre la Configuration de ton domaine puis la zone Serveur de noms checkdomain. Dans les Réglages pro, crée une entrée TXT :
- Nom :
_dmarc - Type :
TXT - Valeur : ton enregistrement DMARC (sans guillemets, comme d’habitude chez checkdomain)
checkdomain met explicitement en garde : « Ne pas utiliser la valeur d’exemple sans la vérifier. » Utilise la valeur qui correspond à ton domaine et à tes sources d’envoi.
3. Analyser les rapports, puis resserrer
Après une ou deux semaines de p=none, les rapports montrent si toutes les sources sont propres. Passe alors à quarantine — n’hésite pas à échelonner avec pct :
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@beispiel.de
pct=25 applique la politique à 25 % des e-mails — augmente pas à pas jusqu’à 100.
4. Passer à reject
Quand quarantine fonctionne proprement, l’application suit — éventuellement avec un alignement strict et une politique de sous-domaine :
v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de; sp=reject; adkim=s; aspf=s
5. Attendre que la modification soit en ligne
Selon checkdomain, la modification est enregistrée en quelques secondes ; jusqu’à ce qu’elle soit visible dans le monde entier, cela peut prendre jusqu’à 48 heures.
Les balises les plus importantes
| Balise | Signification |
|---|---|
v=DMARC1 | version, doit être au début |
p= | politique : none (observer), quarantine (spam), reject (rejeter) |
rua= | adresse pour les rapports d’état agrégés |
ruf= | adresse pour les rapports d’échec forensiques |
sp= | politique distincte pour les sous-domaines |
adkim= / aspf= | alignement (r relaxed, s strict) pour DKIM et SPF respectivement |
Vérifier le résultat
Vérifie ta configuration avec le scanner MXAudit gratuit — il te montre la politique DMARC, SPF et DKIM d’un coup d’œil.
Erreurs fréquentes
Directement à p=reject. Sans phase none préalable, tu bloques presque à coup sûr des sources légitimes (newsletter, CRM, outil de facturation) qui ne sont pas encore proprement authentifiées. Commence toujours par p=none et lis les rapports.
Aucun rua défini. Sans adresse de rapport, tu voles à l’aveugle — tu ne vois jamais quelles sources échouent. rua doit être présent dès le début.
DMARC sans SPF/DKIM. DMARC vérifie les résultats de SPF et DKIM. Si les deux manquent, aucun e-mail ne passe la vérification. D’abord SPF et DKIM, puis DMARC.
Mauvais nom d’hôte. L’enregistrement doit se trouver à _dmarc — pas à @ ni au domaine nu.
Pour aller plus loin
- Support checkdomain : comment définir une entrée DMARC ? (en allemand) (consulté le 10 juillet 2026)
- RFC 7489 — DMARC
