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, et si l'authentification des e-mails est nouvelle pour vous, commencez par qu'est-ce que DMARC.
Selon la RFC 7489, 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.
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.
v=DMARC1; p=none; rua=mailto:dmarc@example.com - 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
- 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
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.
L'e-mail échoue à l'alignement SPF + DKIM
Le récepteur vérifie la politique DMARC : p=none
L'e-mail est distribué normalement dans la boîte de réception
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é.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com - 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
- 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
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.
L'e-mail échoue à l'alignement SPF + DKIM
Le récepteur vérifie la politique DMARC : p=quarantine
L'e-mail est dirigé vers le dossier spam/indésirable
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.
v=DMARC1; p=reject; rua=mailto:dmarc@example.com - 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)
- 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
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.
L'e-mail échoue à l'alignement SPF + DKIM
Le récepteur vérifie la politique DMARC : p=reject
L'e-mail est rejeté au niveau SMTP - jamais distribué
Rapport agrégé envoyé au propriétaire du domaine
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 minimumPubliez 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 minimumPassez à 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 continuPassez à 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.
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.
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 semainespct=25 Augmentez à 25 %. Surveillez les rapports agrégés pour repérer tout expéditeur légitime nouvellement affecté.
2-4 semainespct=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 semainespct=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é.
Permanentv=DMARC1; p=reject; sp=quarantine; rua=... Le domaine principal est entièrement appliqué. Les sous-domaines sont mis en quarantaine pendant leur configuration.
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=
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.
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 gratuitLes équipes font confiance à DMARC Report pour l'application
Rated 4.8/5 on G2 · 469 verified reviews
Zunaid K.
Director
"Essential tool for email delivery"
This tool helps us to implement DMARC reporting for our domains in an easy to use manner.
Verified User in Information Technology and Services
"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.
Larry H.
Research & Development Manager
"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.