Dernière mise à jour : juillet 2026

En bref : après ce guide, ton domaine 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 serveur Mailcow en fonctionnement
  • SPF et DKIM doivent être configurés d’abord — la documentation de Mailcow qualifie explicitement DMARC de « dernière étape », après SPF et DKIM
  • L’accès à la gestion DNS de ton domaine

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. Tu y définis **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).

En auto-hébergement, DMARC boucle la boucle : SPF autorise ton serveur, DKIM signe le message, et DMARC transforme les deux en une règle que les serveurs destinataires appliquent.

Le point de départ chez Mailcow

Mailcow ne définit pas lui-même l’enregistrement DMARC — ta zone DNS est chez ton fournisseur DNS. Mais la documentation de Mailcow décrit exactement ce qui doit y figurer, et renvoie vers un Assistant DMARC pour le créer. Leur enregistrement d’exemple est déjà en mode applicatif :

_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:mailauth-reports@example.org"

Pour un auto-hébergeur proprement configuré, p=reject est le bon objectif — mais atteins-le par la rampe, pas d’emblée.

Le chemin sûr : none → quarantine → reject

  1. p=none — observer, ne rien bloquer. Tu commences ici et collectes des rapports :
v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de
  1. p=quarantine — les e-mails suspects finissent dans les spams, éventuellement échelonnés avec pct :
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@beispiel.de
  1. p=reject — l’application, é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

Ne passe à l’étape suivante que lorsque les rapports montrent que toutes tes sources d’envoi légitimes passent SPF/DKIM.

Guide étape par étape

1. Définir l’adresse de rapport

L’adresse rua 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’enregistrement TXT _dmarc chez le fournisseur DNS

Crée un enregistrement TXT sur l’hôte _dmarc. L’endroit exact dépend du fournisseur DNS — voir nos guides pour IONOS, Strato, Netcup ou Hetzner DNS (chez Hetzner, la valeur TXT doit être entre guillemets).

3. Lire les rapports et resserrer la politique

Commence par p=none, passe par quarantine jusqu’à reject une fois que les rapports sont propres.

4. Attendre que la modification soit en ligne

Les modifications DNS prennent quelques heures selon la mise en cache.

Les balises les plus importantes

BaliseSignification
v=DMARC1version, 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

Copier l’exemple p=reject de Mailcow tel quel. L’exemple de la documentation est en mode applicatif. Si tu l’adoptes avant que tes sources s’authentifient proprement, tu bloques tes propres e-mails. D’abord p=none, lis les rapports, puis resserre.

Aucun rua défini. Sans adresse de rapport, tu ne vois jamais quelles sources échouent.

DMARC sans SPF/DKIM. DMARC vérifie les résultats de SPF et DKIM. 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