Créer un enregistrement DMARC : DNS, balises et politique

La décision de créer un enregistrement DMARC suit souvent un incident : messages usurpés, avertissements Gmail, changement DNS demandé par un fournisseur ou résultats SPF et DKIM variables. Si vous configurez encore votre système, commencez par notre guide du courrier professionnel pour coordonner le domaine, les boîtes et le DNS dès le départ.

Une mauvaise configuration ne provoque pas toujours de panne immédiate. L’enregistrement peut exister sans être utilisé comme prévu : mauvais nom, politique invalide, rapports non reçus ou authentification sans alignement. L’usurpation peut continuer et les messages légitimes finir dans le spam ; publier DMARC ne garantit pas leur remise.

Ce guide explique comment créer un enregistrement DMARC, quelles balises vérifier, quoi publier sur _dmarc.yourdomain.com et comment envisager le passage de la surveillance aux restrictions.

Ce que vous publiez pour créer un enregistrement DMARC

Publiez un TXT sur _dmarc.yourdomain.com commençant par v=DMARC1 et contenant une politique valide : p=none, p=quarantine ou p=reject. DMARC demande un traitement au destinataire lorsqu’aucun mécanisme ne fournit de résultat valide et aligné sur From. Il suffit que SPF ou DKIM réussisse avec alignement pour réussir DMARC.

Voici un exemple minimal valide :

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;

Il publie une politique sans restrictions DMARC, mais ne demande pas de rapports agrégés faute de destination. Les destinataires peuvent continuer à appliquer leurs filtres locaux.

Voici une autre politique initiale, avec une demande de rapports :

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Si les tests justifient des restrictions, remplacez la politique précédente au lieu d’en ajouter une :

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

RFC 7489 exige que v soit la première balise et que p soit présente. Sans ce format valide, les destinataires ne peuvent pas appliquer l’enregistrement comme une politique DMARC. Consultez RFC 7489 pour les détails.

Où créer l’enregistrement DMARC dans le DNS

Il ne se publie pas à la racine, mais sur _dmarc. Pour example.com, le nom complet de recherche est _dmarc.example.com. Un autre nom ne rend pas la politique disponible à cet emplacement DMARC.

Une erreur fréquente consiste à utiliser @ ou à saisir _dmarc.example.com dans une interface attendant seulement _dmarc et ajoutant automatiquement le domaine. Vérifiez si votre fournisseur demande un nom relatif ou complet.

Après publication, interrogez le DNS depuis l’extérieur de l’interface :

dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.com

Il doit y avoir une seule politique DMARC valide commençant par v=DMARC1. Plusieurs chaînes TXT peuvent constituer un même enregistrement ; d’autres TXT ne sont pas nécessairement des politiques DMARC.

Dans TrekMail, vous pouvez ajouter le domaine, copier les valeurs indiquées et utiliser les contrôles DNS disponibles en les confrontant à des recherches externes. Consultez l’ajout d’un domaine, les enregistrements DNS requis et la vérification de l’état DNS. L’interface ne prouve pas à elle seule l’authentification de tous les flux.

Les balises d’un enregistrement DMARC

Beaucoup de balises sont facultatives. Commencez par v, p et, pour demander des rapports, rua. Ajustez l’alignement pour un besoin précis, après avoir vérifié la configuration de base.

Balise	Obligatoire	Rôle	Conseil pratique
`v`	Oui	Identifiant de version	Doit valoir `DMARC1` et apparaître en premier
`p`	Oui	Politique pour les messages échouant à DMARC	Commencez par `none`, puis évaluez `quarantine` et `reject` selon les tests
`rua`	Non	Destination des rapports agrégés	Utilisez une destination surveillée ; les rapports dépendent des destinataires participants et peuvent demander une autorisation externe
`ruf`	Non	Destination des rapports d’échec	Facultatif, avec une prise en charge limitée et des données potentiellement sensibles ; vérifiez confidentialité et accès
`adkim`	Non	Mode d’alignement DKIM	`r` est la valeur par défaut ; tout changement exige un examen des expéditeurs
`aspf`	Non	Mode d’alignement SPF	Commencez par `r` ; utilisez `s` uniquement pour un besoin d’alignement strict dont les effets ont été testés
`pct`	Non	Pourcentage demandé d’application aux messages en échec	`100` ne garantit pas une couverture universelle ; l’échantillonnage dépend du destinataire et n’impose pas de restrictions avec la surveillance
`sp`	Non	Politique héritée par les sous-domaines	S’applique depuis le domaine organisationnel si le sous-domaine n’a pas son propre enregistrement. Si la balise sp est absente, p s’applique aux sous-domaines sans leur propre politique

Un enregistrement valide avec p=none mais sans rua ne demande pas de rapports agrégés. Vos journaux et autres outils restent utilisables, mais l’observation par les rapports DMARC est limitée.

Comment choisir la politique DMARC

Si tous les expéditeurs ne sont pas validés, commencer par p=none est souvent utile. Évaluez p=quarantine après examen des rapports et correction des services. Envisagez p=reject après avoir confronté les sources inconnues à l’inventaire, aux journaux et aux tests des flux critiques peu fréquents.

Politique	Traitement demandé	Quand l’envisager	Risque principal
`p=none`	Pas de restrictions DMARC ; les filtres locaux restent actifs	Observation initiale	Ne demande pas le blocage des messages usurpés
`p=quarantine`	Traitement restrictif selon la politique locale du destinataire	Après validation des expéditeurs et des flux	Des messages légitimes mal configurés peuvent subir des restrictions sans récupération garantie
`p=reject`	Rejet demandé, avec des exceptions locales possibles	Configuration validée et risques évalués	Les messages légitimes en échec peuvent être refusés

Les consignes de Google citées demandent SPF et DKIM pour les expéditeurs en nombre et la réussite d’au moins un mécanisme aligné sur From pour DMARC. Ne présentez pas de possibles évolutions comme des obligations actuelles ; vérifiez les conditions et leur portée dans la FAQ des consignes d’envoi de Google.

DMARC n’est pas une simple case à cocher. Si votre CRM utilise votre domaine dans From, mais signe et envoie avec des domaines du fournisseur non alignés, DMARC peut échouer même si le fournisseur indique que l’authentification est activée.

Créer un enregistrement DMARC étape par étape

Organisez un déploiement progressif : inventaire, politique de surveillance, puis restrictions après vérification. L’absence de surprises dans les rapports ne prouve pas que tous les expéditeurs fonctionnent.

Recensez les services utilisant votre domaine, dont Google Workspace, Microsoft 365, l’assistance, les CRM, formulaires, applications de facturation et newsletters.
Vérifiez SPF et DKIM pour chaque service, avec au moins un résultat valide et aligné. DMARC ne les remplace ni ne les répare. Publiez un SPF valide par domaine d’enveloppe réel et respectez la limite applicable aux mécanismes ou modificateurs déclenchant des recherches DNS, évaluations imbriquées comprises.
Créez une boîte comme dmarc@yourdomain.com ou utilisez un service de rapports, avec surveillance, accès adapté et autorisation DNS sur le domaine destinataire externe si nécessaire.
Publiez d’abord une politique p=none.
Examinez les rapports agrégés disponibles et comparez-les aux expéditeurs connus et à leurs journaux.
Corrigez les domaines authentifiés et leur alignement sur From ; modifier la politique DMARC ne suffit pas.
Évaluez p=quarantine après avoir testé les flux.
Évaluez p=reject lorsque les tests, y compris des processus rares, justifient le changement.

Cet exemple de surveillance pour un domaine professionnel en 2026 doit être adapté à votre destination de rapports :

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

Si vous utilisez des transferts, consultez le transfert du courrier d’un domaine vers Gmail. Le transfert peut faire échouer SPF. DKIM peut préserver la réussite de DMARC s’il reste valide et aligné et si les données signées sont conservées après canonicalisation. ARC peut éclairer une exception locale du destinataire, mais ne fournit pas à lui seul un résultat d’authentification DMARC réussi.

Les erreurs courantes lors de la création d’un enregistrement DMARC

De nombreux problèmes viennent de la configuration : mauvais nom, plusieurs politiques DMARC, destinations de rapports invalides ou attente que DMARC corrige SPF et DKIM. Publiez une politique valide et vérifiez-la depuis l’extérieur.

Voici les erreurs les plus fréquentes :

1. Publier à la racine plutôt que sur _dmarc.
Un enregistrement sur @ n’apparaît pas dans la recherche DMARC du domaine.

2. Publier plusieurs politiques DMARC dans des TXT.
RFC 7489 indique que plusieurs politiques DMARC empêchent la poursuite du traitement. Conservez une politique par nom de recherche ; les fragments d’un TXT ne sont pas plusieurs politiques.

3. Activer p=reject dès le départ.
Un service oublié peut entraîner le rejet de réinitialisations de mots de passe, de factures ou de réponses légitimes de l’assistance.

4. Faire pointer rua vers une boîte inexistante.
Vous pouvez perdre des rapports effectivement envoyés. Leur absence ne prouve pas non plus que les destinataires en ont généré.

5. Attendre de DMARC qu’il répare les transferts.
DMARC exige SPF ou DKIM valide et aligné. Si SPF échoue lors du transfert, DKIM doit rester valide et aligné pour fournir ce résultat.

Exemple : votre site envoie les confirmations via un fournisseur SMTP, l’assistance via un autre et le marketing via un troisième. Vous publiez p=reject sans vérifier les trois. Un flux réussit, deux échouent ; leurs destinataires peuvent refuser des messages dont vos clients ont besoin. La politique n’a pas corrigé les services restants.

Si vous configurez le domaine de zéro, notre guide pour créer des e-mails avec votre domaine présente le contexte DNS et les boîtes avec SPF, DKIM et DMARC.

Gérer DMARC sur plusieurs domaines : dispersion ou centralisation

Les feuilles de calcul, les connexions à chaque bureau d’enregistrement et les TXT issus d’anciens tickets compliquent la coordination. Une interface centrale et des contrôles DNS peuvent aider à repérer les différences, mais chaque domaine et service d’envoi exige une configuration vérifiée.

Gestion dispersée	Gestion avec TrekMail
Vérifier chaque bureau d’enregistrement pour identifier les valeurs DNS actuelles	Utiliser l’interface multidomaine disponible dans le plan
Comparer manuellement les TXT et supposer la propagation terminée	Interroger le DNS et examiner les différences, sans garantie de propagation complète
Coordonner SPF, DKIM et DMARC dans des outils séparés	Utiliser le processus DNS disponible et vérifier les messages de chaque service réel
Payer par utilisateur même avec peu de boîtes par domaine	Évaluer l’offre multidomaine à partir de $3.50 par mois selon les limites et conditions actuelles

Selon le plan, TrekMail propose plusieurs domaines, du stockage mutualisé, des boîtes IMAP, des outils de migration, un catch-all, le transfert et un SMTP géré ou votre propre SMTP. La copie IMAP ne remplace pas le changement des MX et ne migre pas toutes les applications. L’offre Nano décrite permet jusqu’à 10 domaines sans frais avec votre SMTP ; les plans payants commencent à $3.50 par mois selon leurs conditions. Consultez les fonctionnalités et tarifs actuels sur la page des tarifs TrekMail.

La centralisation peut faciliter les vérifications et la coordination entre cinq fournisseurs et vingt onglets. Elle ne prouve pas automatiquement l’état de tous les flux et ne garantit ni économies ni baisse des incidents.

Dernières vérifications avant les restrictions DMARC

Avant d’appliquer des restrictions, vérifiez SPF et DKIM des expéditeurs autorisés, au moins un résultat valide et aligné par flux, la destination des rapports et une seule politique DMARC valide sur _dmarc. DMARC ne remplace pas une authentification correcte.

Relisez cette liste :

Une seule politique DMARC en TXT.
Nom _dmarc, relatif ou complet selon le fournisseur DNS.
Valeur commençant par v=DMARC1; p=....
rua pointe vers une boîte ou un service valide, surveillé et autorisé si nécessaire.
Un SPF valide par domaine d’enveloppe, avec des autorisations réunies et le respect du plafond DNS applicable, évaluations imbriquées comprises.
DKIM configuré et vérifié sur les plateformes compatibles, avec au moins un mécanisme aligné par flux.
Les recherches externes montrent la politique attendue.
Commencez par none si vous devez encore valider les expéditeurs et les flux peu fréquents.

TrekMail peut centraliser les domaines personnalisés, les boîtes IMAP, les contrôles DNS, le choix SMTP et les outils de migration selon le plan. Cela ne supprime pas le suivi continu et ne garantit pas la remise. Consultez trekmail.net et évaluez les fonctionnalités en fonction de vos besoins opérationnels.