--- title: "La politique DMARC expliquée : none vs quarantine vs reject | DMARC Report" description: "La politique DMARC (tag p=) indique aux serveurs de messagerie de réception ce qu" image: "https://dmarcreport.com/images/og-default.png" canonical: "https://dmarcreport.com/fr/politique-dmarc/" --- Politiques DMARC # Choisissez la bonne politique DMARC pour votre domaine **La politique DMARC (tag `p=`) indique aux serveurs de messagerie de réception ce qu'il faut faire des messages qui échouent à l'authentification DMARC.** Il existe trois options - none, quarantine et reject - et chaque domaine devrait suivre le même chemin, de la surveillance à l'application totale. Chaque politique est publiée dans votre [enregistrement DMARC](/fr/enregistrement-dmarc/), et si l'authentification des e-mails est nouvelle pour vous, commencez par [qu'est-ce que DMARC](/fr/qu-est-ce-que-dmarc/). Selon la [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489), la politique ne s'applique que lorsque l'alignement SPF ET l'alignement DKIM échouent tous les deux. Si l'un des deux réussit et s'aligne, le message passe DMARC quelle que soit la politique. [ Vérifiez votre politique DMARC → ](/fr/tools/dmarc-checker/) [Voir la chronologie](#policy-progression) Les trois politiques ## none, quarantine, reject Chaque politique est une étape du parcours vers l'application. Commencez par la visibilité, gagnez en confiance, puis appliquez. `p=none` Surveillance uniquement Tout voir. Ne rien bloquer. Les serveurs de messagerie de réception ne prennent aucune mesure d'application sur les messages qui échouent à DMARC. Ils renvoient tout de même des rapports agrégés au propriétaire du domaine, offrant une visibilité totale sur chaque source qui envoie des e-mails depuis le domaine. Exemple d'enregistrement `v=DMARC1; p=none; rua=mailto:dmarc@example.com` Avantages - Aucun risque pour la distribution des e-mails légitimes - Visibilité totale sur toutes les sources d'envoi via les rapports agrégés - Première étape indispensable - vous devez surveiller avant d'appliquer - Satisfait l'exigence minimale de Google/Yahoo pour les expéditeurs en masse Limites - N'offre aucune protection contre le spoofing ou le phishing - Les attaquants peuvent toujours envoyer des e-mails au nom de votre domaine et ils seront distribués - N'améliore pas la réputation du domaine auprès des récepteurs Quand l'utiliser Commencez toujours ici. Déployez p=none avec la génération de rapports rua= et surveillez pendant au moins 90 jours. Utilisez cette phase pour identifier chaque expéditeur légitime, corriger sa configuration SPF/DKIM et confirmer l'alignement avant de passer à l'application. Ce qui arrive à un e-mail en échec 1 L'e-mail échoue à l'alignement SPF + DKIM 2 Le récepteur vérifie la politique DMARC : p=none 3 L'e-mail est distribué normalement dans la boîte de réception 4 Rapport agrégé envoyé au propriétaire du domaine `p=quarantine` Diriger vers le spam Les e-mails suspects vont dans le spam. Les e-mails légitimes continuent de circuler. Les messages qui échouent à DMARC sont dirigés vers le dossier spam ou indésirable du destinataire. Le message existe toujours - les destinataires peuvent le retrouver s'ils le cherchent - mais il est clairement signalé comme suspect. C'est l'étape d'application qui sert de filet de sécurité. Exemple d'enregistrement `v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com` Avantages - Protection active - les messages usurpés quittent la boîte de réception - Filet de sécurité pour les expéditeurs mal configurés (les messages ne sont pas perdus) - Signale aux récepteurs que vous prenez au sérieux la sécurité des e-mails - Bon compromis pendant la transition vers l'application Limites - Les expéditeurs légitimes dont l'authentification est défaillante atterrissent dans le spam - Les destinataires peuvent ne pas consulter les dossiers spam, entraînant des e-mails manqués - Certains récepteurs traitent en pratique quarantine comme reject Quand l'utiliser Après 90 jours ou plus à p=none avec tous les expéditeurs légitimes identifiés et réussissant l'authentification. Ne passez ici que lorsque vos rapports agrégés montrent un alignement SPF/DKIM constant pour chaque source autorisée. Ce qui arrive à un e-mail en échec 1 L'e-mail échoue à l'alignement SPF + DKIM 2 Le récepteur vérifie la politique DMARC : p=quarantine 3 L'e-mail est dirigé vers le dossier spam/indésirable 4 Rapport agrégé envoyé au propriétaire du domaine `p=reject` Bloquer entièrement Application totale. Les e-mails usurpés n'arrivent jamais. Les messages qui échouent à DMARC sont rejetés au niveau SMTP - le destinataire ne les voit jamais et le serveur d'envoi reçoit un rejet (bounce). C'est la protection la plus forte et l'objectif ultime pour chaque domaine. Exemple d'enregistrement `v=DMARC1; p=reject; rua=mailto:dmarc@example.com` Avantages - Protection maximale contre le spoofing de domaine et le phishing - Les attaquants ne peuvent pas distribuer d'e-mails usurpant votre domaine - Signal de réputation de domaine le plus élevé auprès des serveurs de réception - Éligible à BIMI (Brand Indicators for Message Identification) Limites - Les expéditeurs légitimes mal configurés sont complètement bloqués - pas même le spam - Les chaînes de transfert d'e-mails qui rompent l'alignement échoueront - Nécessite une surveillance approfondie avant le déploiement Quand l'utiliser Après 90 jours ou plus à p=quarantine avec des rapports agrégés propres. Tous les expéditeurs légitimes doivent réussir de manière constante l'alignement SPF ou DKIM. Le parcours complet de p=none à p=reject prend généralement de 9 à 18 mois. Ce qui arrive à un e-mail en échec 1 L'e-mail échoue à l'alignement SPF + DKIM 2 Le récepteur vérifie la politique DMARC : p=reject 3 L'e-mail est rejeté au niveau SMTP - jamais distribué 4 Rapport agrégé envoyé au propriétaire du domaine Le parcours ## Le chemin vers l'application totale Chaque domaine suit la même progression. La chronologie dépend de la complexité - plus il y a d'expéditeurs, plus la configuration prend du temps. Prévoyez **9 à 18 mois** entre le premier enregistrement et le p=reject total. `p=none` ### Phase 1 : Surveiller 90 jours minimum Publiez l'enregistrement DMARC avec p=none et la génération de rapports rua=. Analysez les rapports agrégés pour identifier chaque source qui envoie des e-mails depuis votre domaine. Corrigez SPF et DKIM pour tous les expéditeurs légitimes. `p=quarantine` ### Phase 2 : Quarantaine 90 jours minimum Passez à p=quarantine. Commencez avec pct=10 et augmentez progressivement. Surveillez les rapports pour repérer tout expéditeur nouvellement affecté. Corrigez les problèmes d'authentification restants. `p=reject` ### Phase 3 : Rejeter En continu Passez à p=reject avec la pleine assurance que tous les e-mails légitimes passent. Continuez à surveiller - de nouveaux expéditeurs, des changements d'IP et des mises à jour de fournisseurs peuvent rompre l'authentification à tout moment. ### Chronologie totale : 9-18 mois Les organisations ayant peu d'expéditeurs peuvent atteindre p=reject plus rapidement. Les environnements complexes comptant des dizaines de services tiers prennent plus de temps. L'essentiel, ce sont des décisions fondées sur les données - ne sautez jamais les phases de surveillance. Déploiement progressif ## Le tag `pct=` : l'application avec un filet de sécurité Le tag `pct=` contrôle le pourcentage de messages en échec qui reçoivent l'action d'application. Les messages hors du pourcentage sont traités comme si la politique était `p=none`. Cela vous permet de déployer progressivement l'application tout en surveillant les problèmes. Exemple `v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com` 25 % des messages en échec sont mis en quarantaine. Les 75 % restants sont distribués normalement. `pct=10` Applique l'action sur 10 % des messages en échec. Les 90 % restants sont traités comme p=none. Idéal pour les tests initiaux. 2-4 semaines `pct=25` Augmentez à 25 %. Surveillez les rapports agrégés pour repérer tout expéditeur légitime nouvellement affecté. 2-4 semaines `pct=50` La moitié des messages en échec reçoit désormais l'action d'application. La plupart des problèmes sont révélés à ce stade. 2-4 semaines `pct=100` Application totale. Tous les messages qui échouent à l'alignement DMARC reçoivent l'action de la politique publiée. C'est la valeur par défaut lorsque pct= n'est pas spécifié. Permanent DNS TXT Records \_dmarc.example.com `v=DMARC1; p=reject; sp=quarantine; rua=...` example.com p=reject \*.example.com sp=quarantine Le domaine principal est entièrement appliqué. Les sous-domaines sont mis en quarantaine pendant leur configuration. Politique des sous-domaines ## Le tag `sp=` : le contrôle des sous-domaines Le tag `sp=` définit une politique DMARC distincte pour les sous-domaines. Sans lui, les sous-domaines héritent de la politique `p=` du domaine principal. C'est utile lorsque votre domaine principal est prêt pour l'application mais que les sous-domaines ont besoin de plus de temps. - sp=none - les sous-domaines sont surveillés pendant leur configuration - sp=quarantine - les sous-domaines reçoivent une application intermédiaire - sp=reject - les sous-domaines sont entièrement appliqués (identique à l'absence de sp= lorsque p=reject) - Omettre sp= - les sous-domaines héritent de la politique p= À éviter ## Erreurs courantes de politique DMARC Voici les erreurs que nous observons le plus souvent dans les déploiements DMARC. Chacune d'elles peut être évitée grâce à une surveillance appropriée et une approche progressive. ### Appliquer trop vite Passer à p=reject sans au moins 90 jours à p=none provoque le blocage des e-mails légitimes. Les plateformes marketing, les outils CRM et les systèmes de ticketing échouent souvent à DMARC s'ils ne sont pas correctement configurés. ### Aucune surveillance après l'application DMARC ne se configure pas une fois pour toutes. De nouvelles sources d'envoi, des changements d'IP et des mises à jour de fournisseurs peuvent rompre l'authentification à tout moment. Une surveillance continue détecte les problèmes avant qu'ils n'affectent la distribution. ### Ignorer les expéditeurs tiers Chaque service qui envoie des e-mails en votre nom - Mailchimp, HubSpot, Salesforce, Zendesk - doit avoir des includes SPF ou une signature DKIM configurés. En oublier un seul provoque des échecs lors de l'application. ### Oublier les sous-domaines Sans tag sp=, les sous-domaines héritent de la politique du domaine principal. Mais si vous appliquez p=reject sans vérifier les expéditeurs des sous-domaines, vous risquez de bloquer des e-mails légitimes de sous-domaines. Définissez sp= explicitement. ### Publier sans rua= Un enregistrement DMARC sans génération de rapports rua= revient à voler à l'aveugle. Vous n'avez aucune visibilité sur les résultats d'authentification, aucun moyen de détecter le spoofing et aucune donnée pour prendre des décisions d'application. ### Utiliser l'alignement relaxed quand strict est nécessaire L'alignement relaxed (par défaut) permet à mail.example.com de s'aligner avec example.com. Pour la plupart des organisations, c'est correct, mais les domaines à haute sécurité peuvent nécessiter un alignement strict pour prévenir l'abus de sous-domaines. FAQ ## Questions sur la politique DMARC ### Quelle est la meilleure politique DMARC ? La meilleure politique DMARC est p=reject, qui offre une protection maximale contre le spoofing de domaine. Cependant, vous devez atteindre p=reject par une approche progressive : commencez à p=none (surveillez pendant 90+ jours), passez à p=quarantine (90+ jours), puis appliquez p=reject. Passer directement à reject provoque le blocage des e-mails légitimes. ### Combien de temps dois-je rester à p=none avant d'appliquer ? Restez à p=none pendant un minimum de 90 jours - un trimestre complet. Cela vous donne suffisamment de données de rapports agrégés pour identifier toutes les sources d'envoi légitimes et corriger leur authentification. Certaines organisations ayant de nombreux expéditeurs tiers peuvent avoir besoin de plus de temps. Le parcours complet jusqu'à p=reject prend généralement de 9 à 18 mois. ### p=quarantine offre-t-il une protection suffisante ? Quarantine constitue une amélioration notable par rapport à p=none car les messages usurpés n'atteignent plus la boîte de réception. Ils existent toutefois encore dans le dossier spam. Pour une protection totale, p=reject est l'objectif - il empêche complètement la distribution des messages usurpés. Certains cadres de conformité (comme PCI DSS v4.0) exigent spécifiquement p=reject. ### Que se passe-t-il si je définis p=reject et qu'un expéditeur légitime échoue ? L'e-mail de l'expéditeur légitime sera rejeté - le destinataire ne le recevra pas. C'est pourquoi la surveillance à p=none et p=quarantine est essentielle avant l'application. Utilisez le tag pct= pour déployer progressivement l'application (pct=10 pour commencer) afin de détecter les erreurs de configuration avant qu'elles n'affectent tous les e-mails. ### Puis-je avoir des politiques différentes pour mon domaine et mes sous-domaines ? Oui. Le tag sp= (politique des sous-domaines) vous permet de définir une politique distincte pour les sous-domaines. Par exemple, vous pourriez appliquer p=reject sur votre domaine principal tout en conservant sp=none sur les sous-domaines encore en cours de configuration. Si sp= n'est pas défini, les sous-domaines héritent de la politique du domaine principal. ### Qu'est-ce que le tag pct= et comment devrais-je l'utiliser ? Le tag pct= contrôle le pourcentage de messages en échec qui reçoivent l'action d'application. À pct=10, seuls 10 % des messages en échec sont mis en quarantaine ou rejetés - le reste est traité comme p=none. Augmentez progressivement de 10 à 25, 50 puis 100 sur plusieurs semaines pour passer en toute sécurité à l'application totale. ## Voyez votre politique DMARC actuelle en action Essai gratuit - surveillez les rapports agrégés, identifiez les expéditeurs et planifiez votre parcours vers l'application. [Démarrer l'essai gratuit](https://app.dmarcreport.com/signup?plan=free) ## Les équipes font confiance à DMARC Report pour l'application ![G2 Leader - DMARC](https://media.mailhop.org/dmarcreport/images/g2-badges/DMARC_Leader_Leader.png) Rated 4.8/5 on G2 · 469 verified reviews ![G2 Momentum Leader - DMARC](https://media.mailhop.org/dmarcreport/images/g2-badges/DMARC_MomentumLeader_Leader.png) ZK Zunaid K. Director 5/5 ### "Essential tool for email delivery" This tool helps us to implement DMARC reporting for our domains in an easy to use manner. 8/8/2024Verified on G2 VU Verified User in Information Technology and Services 5/5 ### "Best security tool for your own domains" The weekly reports help me a lot to analyze quickly the emails sent from my domains and that gives me peace of mind. 8/31/2022Verified on G2 LH Larry H. Research & Development Manager 5/5 ### "Good tool to buy" I have used many tools for monitoring DMARC reports. But DMARC Report is a good tool to use. It helps avoid sending emails to spam. 8/30/2022Verified on G2 [Read all 469 reviews on G2 →](https://www.g2.com/products/dmarc-report/reviews) ```json {"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138898167","https://www.linkedin.com/company/duocircle","https://x.com/duocirclellc","https://www.g2.com/products/dmarc-report/reviews","https://github.com/duocircle","https://www.crunchbase.com/organization/duocircle-llc","https://www.trustradius.com/products/duocircle/reviews"],"aggregateRating":{"@type":"AggregateRating","ratingValue":"4.8","reviewCount":"471","bestRating":"5","worstRating":"1","url":"https://www.g2.com/products/dmarc-report/reviews"},"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://dmarcreport.com/support/"},"knowsAbout":["DMARC","DMARC Reporting","DMARC Aggregate Reports","DMARC Forensic Reports","Sender Policy Framework","DKIM","Email Authentication","Email Security","DNS Management","Email Deliverability"]} ``` ```json {"@context":"https://schema.org","@type":"WebSite","name":"DMARC Report","url":"https://dmarcreport.com","description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","publisher":{"@type":"Organization","name":"DMARC Report","url":"https://dmarcreport.com","logo":{"@type":"ImageObject","url":"https://dmarcreport.com/images/dmarcreport-logo.png"},"description":"DMARC reporting and email authentication management. Monitor aggregate and forensic DMARC reports, analyze authentication results, and enforce DMARC policies across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}} ``` ```json [{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Quelle est la meilleure politique DMARC ?","acceptedAnswer":{"@type":"Answer","text":"La meilleure politique DMARC est p=reject, qui offre une protection maximale contre le spoofing de domaine. Cependant, vous devez atteindre p=reject par une approche progressive : commencez à p=none (surveillez pendant 90+ jours), passez à p=quarantine (90+ jours), puis appliquez p=reject. Passer directement à reject provoque le blocage des e-mails légitimes."}},{"@type":"Question","name":"Combien de temps dois-je rester à p=none avant d'appliquer ?","acceptedAnswer":{"@type":"Answer","text":"Restez à p=none pendant un minimum de 90 jours - un trimestre complet. Cela vous donne suffisamment de données de rapports agrégés pour identifier toutes les sources d'envoi légitimes et corriger leur authentification. Certaines organisations ayant de nombreux expéditeurs tiers peuvent avoir besoin de plus de temps. Le parcours complet jusqu'à p=reject prend généralement de 9 à 18 mois."}},{"@type":"Question","name":"p=quarantine offre-t-il une protection suffisante ?","acceptedAnswer":{"@type":"Answer","text":"Quarantine constitue une amélioration notable par rapport à p=none car les messages usurpés n'atteignent plus la boîte de réception. Ils existent toutefois encore dans le dossier spam. Pour une protection totale, p=reject est l'objectif - il empêche complètement la distribution des messages usurpés. Certains cadres de conformité (comme PCI DSS v4.0) exigent spécifiquement p=reject."}},{"@type":"Question","name":"Que se passe-t-il si je définis p=reject et qu'un expéditeur légitime échoue ?","acceptedAnswer":{"@type":"Answer","text":"L'e-mail de l'expéditeur légitime sera rejeté - le destinataire ne le recevra pas. C'est pourquoi la surveillance à p=none et p=quarantine est essentielle avant l'application. Utilisez le tag pct= pour déployer progressivement l'application (pct=10 pour commencer) afin de détecter les erreurs de configuration avant qu'elles n'affectent tous les e-mails."}},{"@type":"Question","name":"Puis-je avoir des politiques différentes pour mon domaine et mes sous-domaines ?","acceptedAnswer":{"@type":"Answer","text":"Oui. Le tag sp= (politique des sous-domaines) vous permet de définir une politique distincte pour les sous-domaines. Par exemple, vous pourriez appliquer p=reject sur votre domaine principal tout en conservant sp=none sur les sous-domaines encore en cours de configuration. Si sp= n'est pas défini, les sous-domaines héritent de la politique du domaine principal."}},{"@type":"Question","name":"Qu'est-ce que le tag pct= et comment devrais-je l'utiliser ?","acceptedAnswer":{"@type":"Answer","text":"Le tag pct= contrôle le pourcentage de messages en échec qui reçoivent l'action d'application. À pct=10, seuls 10 % des messages en échec sont mis en quarantaine ou rejetés - le reste est traité comme p=none. Augmentez progressivement de 10 à 25, 50 puis 100 sur plusieurs semaines pour passer en toute sécurité à l'application totale."}}]}] ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://dmarcreport.com/"},{"@type":"ListItem","position":2,"name":"Apprendre","item":"https://dmarcreport.com/fr/qu-est-ce-que-dmarc/"},{"@type":"ListItem","position":3,"name":"Politique DMARC","item":"https://dmarcreport.com/fr/politique-dmarc/"}]} ```