# Configurer DMARC : exemples d’enregistrement, de p=none à reject > Pour configurer DMARC, assurez-vous que SPF et DKIM sont validés pour chaque service qui envoie au nom de votre domaine, publiez un enregistrement TXT sur _dmarc.votredomaine, par exemple v=DMARC1; p=none; rua=mailto:dmarc@votredomaine, lisez les rapports quotidiens pendant quelques semaines, puis durcissez la politique en passant à quarantine et enfin à reject. Canonical: https://tellnod.com/fr/guides/how-to-set-up-dmarc Last updated: 2026-10-22 Author: Tellnod team ## Étapes 1. **Vérifiez d’abord SPF et DKIM.** Listez tous les services qui envoient avec votre domaine dans l’adresse d’expédition et vérifiez que chacun valide [SPF](https://tellnod.com/glossary#spf) ou [DKIM](https://tellnod.com/glossary#dkim) pour votre propre domaine. Google suggère de configurer les deux au moins 48 heures avant DMARC [S3]. 2. **Choisissez une boîte pour les rapports.** Créez une adresse comme dmarc@ninefold.example, ou utilisez un service de rapports. Les rapports arrivent sous forme de fichiers XML compressés [S2]. 3. **Publiez un enregistrement de surveillance.** Ajoutez un enregistrement TXT avec l’hôte `_dmarc` et la valeur `v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example`. Une politique none ne modifie pas le traitement des e-mails [S1]. 4. **Vérifiez l’enregistrement.** Lancez `dig +short TXT _dmarc.ninefold.example` ou utilisez un outil de recherche DNS, et vérifiez qu’un seul enregistrement est renvoyé et qu’il commence par v=DMARC1. 5. **Lisez les rapports.** Examinez les rapports agrégés jusqu’à ce que chaque expéditeur légitime présente un SPF ou un DKIM aligné. Google suggère au moins une semaine ; la RFC 9989 suggère environ un mois avant d’appliquer la politique [S1][S3]. 6. **Passez à quarantine.** Changez la politique en `p=quarantine`, pour que les e-mails en échec aillent en spam. Continuez à lire les rapports. 7. **Passez à reject.** Après une période similaire avec des rapports propres, changez la politique en `p=reject`, pour que les destinataires refusent les e-mails en échec [S1]. ## Ce qu’il vous faut avant de commencer [DMARC](https://tellnod.com/glossary#dmarc) n’authentifie rien à lui seul. Il lit les résultats SPF et DKIM et vérifie qu’au moins l’un des deux a été validé pour un domaine aligné sur l’adresse d’expédition visible [S1]. Si votre outil d’e-mailing signe avec son propre domaine au lieu du vôtre, DMARC échoue alors même que DKIM est validé. Corrigez cela d’abord, sinon les rapports seront remplis de vos propres e-mails. Pour une petite marque de vêtements comme Ninefold, la liste des expéditeurs comprend généralement la messagerie de l’équipe, les e-mails de commande et d’expédition de la plateforme e-commerce, le service client et l’outil d’e-mailing. Chacun doit avoir SPF ou DKIM configuré sur ninefold.example. Le guide [SPF, DKIM et DMARC expliqués](https://tellnod.com/fr/guides/spf-dkim-dmarc-explained) détaille le fonctionnement de chaque enregistrement. > Gmail exige un enregistrement DMARC des expéditeurs de plus de 5 000 messages par jour vers des comptes Gmail personnels, et une politique none est acceptée [S4]. Yahoo demande lui aussi au moins p=none aux expéditeurs en volume [S5]. L’enregistrement se publie en quelques minutes : il vaut la peine de l’ajouter quel que soit votre volume. ## Syntaxe de l’enregistrement DMARC Un enregistrement DMARC est un enregistrement TXT publié sur `_dmarc` dans votre domaine. Il se compose d’une liste de balises séparées par des points-virgules. La balise `v=DMARC1` doit venir en premier, sinon les destinataires ignorent tout l’enregistrement [S1]. Voici les balises dont une boutique a besoin : | Balise | Exemple | Rôle | | --- | --- | --- | | v | v=DMARC1 | Version ; doit précéder toutes les autres balises | | p | p=none | Politique pour votre domaine : none, quarantine ou reject | | rua | rua=mailto:dmarc@ninefold.example | Adresse de destination des rapports agrégés quotidiens | | sp | sp=reject | Politique pour les sous-domaines existants, si elle diffère de p | | np | np=reject | Politique pour les sous-domaines qui n’existent pas | | adkim / aspf | adkim=r | Alignement DKIM et SPF : souple (par défaut) ou strict | | t | t=y | Test : demande aux destinataires d’appliquer un niveau en dessous de la politique indiquée | Omettez `adkim` et `aspf` sauf raison particulière. L’alignement souple, appliqué par défaut, permet à un e-mail signé par un sous-domaine comme mail.ninefold.example d’être aligné sur une adresse d’expédition en ninefold.example [S1], et Yahoo accepte l’alignement souple [S5]. ## Exemples d’enregistrement DMARC pour chaque étape Ces exemples utilisent ninefold.example. Remplacez le domaine et l’adresse de rapport par les vôtres, et publiez chacun sous l’hôte `_dmarc`. ### Surveillance `v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example` ### Quarantaine `v=DMARC1; p=quarantine; rua=mailto:dmarc@ninefold.example` ### Rejet `v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@ninefold.example` > Des guides plus anciens, dont la page de déploiement de Google, utilisent `pct=` pour appliquer la politique à un pourcentage des e-mails [S3]. La RFC 9989 a supprimé cette balise, car les destinataires ne l’appliquaient de façon fiable qu’à 0 ou 100, et a ajouté `t=y` pour une période de test [S1]. Les destinataires doivent ignorer les balises qu’ils ne connaissent pas : un destinataire qui ne prend pas encore en charge `np` ou `t` les ignore simplement [S1]. ## Ce que vous apprennent les rapports rua Les fournisseurs de messagerie qui envoient des rapports agrégés en envoient généralement un par jour et par domaine, sous forme de fichier XML compressé [S2]. Chaque rapport liste les adresses IP qui ont envoyé des e-mails avec votre domaine, le nombre de messages provenant de chacune, les résultats SPF et DKIM, leur alignement et ce que le destinataire a fait des e-mails [S2]. - **Une source que vous connaissez et qui échoue à l’alignement** est un expéditeur que vous avez oublié de configurer. Activez DKIM pour votre domaine dans ce service, ou ajoutez-le à SPF. - **Une source que vous ne connaissez pas** est soit un service auquel quelqu’un de votre équipe s’est inscrit, soit une usurpation de votre domaine. Renseignez-vous avant d’appliquer la politique. - **Les e-mails transférés** échouent souvent à SPF et passent DKIM [S1]. C’est normal, et c’est l’une des raisons pour lesquelles un DKIM aligné compte le plus. Le XML brut est difficile à lire à la main : beaucoup de boutiques envoient donc `rua` vers un service de rapports qui le transforme en graphiques. Si ce service utilise un autre domaine, celui-ci doit publier un enregistrement d’autorisation, sinon les destinataires ignorent l’adresse [S2]. Les services de rapports s’en chargent de leur côté. ## Passer de p=none à quarantine, puis à reject L’ordre est toujours le même : surveillance, puis quarantaine, puis rejet. Ce qui varie, c’est la durée de chaque étape. Google suggère au moins une semaine en none [S3]. La RFC 9989 suggère au moins un mois en none et une période similaire en quarantine avant reject [S1]. Une boutique avec quelques expéditeurs et des rapports propres peut avancer plus vite qu’une boutique qui utilise une douzaine d’outils. | Politique | E-mails en échec | Quand l’utiliser | | --- | --- | --- | | p=none | Délivrés normalement ; rapports uniquement | Le temps d’identifier tous les expéditeurs | | p=quarantine | Traités comme suspects, généralement placés en spam | Une fois que les rapports montrent tous vos expéditeurs alignés | | p=reject | Refusés par le destinataire | Après une période propre en quarantine | Avant chaque changement, vérifiez la dernière semaine de rapports pour repérer des sources connues en échec. Si l’équipe publie sur des listes de diffusion depuis le domaine de la boutique, la RFC 9989 déconseille `p=reject` : les e-mails de liste rejetés par les destinataires posent des problèmes à la liste et peuvent entraîner la désinscription d’abonnés [S1]. Dans ce cas, quarantine est un point d’arrêt raisonnable. ## DMARC pour les sous-domaines Sans enregistrement propre, un sous-domaine comme news.ninefold.example applique la politique de ninefold.example. Utilisez `sp` pour donner une politique différente aux sous-domaines existants, et `np` pour les noms qui n’existent pas, souvent utilisés pour usurper une marque [S1]. Certaines boutiques envoient leurs e-mails marketing depuis un sous-domaine pour les séparer de la messagerie de l’équipe. Ce sous-domaine peut avoir son propre enregistrement `_dmarc`. La RFC 9989 décrit le test d’un sous-domaine avec `p=quarantine; t=y`, puis le passage à `p=reject` et le retrait de l’indicateur de test [S1]. ## Configurer DMARC avec Tellnod dans Claude ou ChatGPT Tellnod est un [connecteur MCP](https://tellnod.com/glossary#mcp-connector) qui permet de rédiger, prévisualiser et envoyer des e-mails marketing depuis Claude ou ChatGPT. Vous pouvez envoyer immédiatement depuis une adresse sur le domaine partagé de Tellnod, comme hello@yourshop.tellnodmail.com, dans la limite de 500 destinataires par campagne et de 1 000 e-mails par mois. Vérifier votre propre domaine lève ces limites. Demandez dans la conversation : « Configure ninefold.example comme domaine d’envoi. » Tellnod vous fournit les enregistrements SPF, DKIM et DMARC et les vérifie pour vous. Si quelqu’un d’autre gère votre DNS, demandez un lien de configuration à lui transmettre : cette personne peut ajouter les enregistrements en un clic chez les fournisseurs compatibles, ou les copier, sans créer de compte. Vous êtes prévenu dans la conversation et par e-mail lorsque le domaine est vérifié. Si vous avez déjà un enregistrement DMARC, n’en gardez qu’un seul et assurez-vous que vos e-mails Tellnod sont alignés avant de durcir la politique. Chaque campagne passe toujours par un aperçu ordinateur et mobile et par une carte de confirmation sur laquelle vous seul pouvez appuyer. [Connectez Tellnod](https://tellnod.com/fr/connect) pour commencer avec l’offre gratuite, ou comparez les offres sur la [page Tarifs](https://tellnod.com/fr/pricing). Pour le reste des exigences de Gmail et Yahoo, consultez [les bases de la délivrabilité](https://tellnod.com/guides/email-deliverability-basics). ## FAQ ### Quel enregistrement DMARC choisir pour commencer ? Commencez par v=DMARC1; p=none; rua=mailto: suivi d’une adresse que vous consultez. Il ne change rien à la délivrance et déclenche l’envoi des rapports quotidiens [S1]. ### p=none suffit-il pour Gmail et Yahoo ? Oui, pour les exigences visant les expéditeurs en volume. Les deux acceptent une politique none, à condition que le domaine d’expédition soit aligné avec SPF ou DKIM [S4][S5]. Appliquer une politique plus stricte ensuite renforce la protection contre l’usurpation. ### Combien de temps rester en p=none ? Jusqu’à ce que les rapports montrent tous les expéditeurs légitimes alignés. Google suggère au moins une semaine, et la RFC 9989 environ un mois avant d’appliquer la politique [S1][S3]. ### Peut-on avoir deux enregistrements DMARC ? Non. Publiez un seul enregistrement TXT sur _dmarc. Si une recherche renvoie plus d’un enregistrement DMARC, les destinataires les ignorent tous : fusionnez-les en un seul [S1]. ### L’enregistrement DMARC se place-t-il sur le domaine racine ou sur un sous-domaine ? Sur l’hôte _dmarc du domaine de votre adresse d’expédition. Un enregistrement sur le domaine principal couvre aussi les sous-domaines qui n’ont pas le leur, grâce à sa balise p, sp ou np [S1]. ## Sources - [S1] RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC): (checked 2026-10-22) - [S2] RFC 9990: DMARC aggregate reporting: (checked 2026-10-22) - [S3] Google Workspace Admin Help: Recommended DMARC rollout: (checked 2026-10-22) - [S4] Google Workspace Admin Help: Email sender guidelines: (checked 2026-10-22) - [S5] Yahoo Sender Hub: Sender best practices: (checked 2026-10-22)