Commencez tout déploiement DMARC (Domain-based Message Authentication, Reporting, and Conformance) avec p=none, surveillez les rapports agrégés pendant quelques semaines, puis passez à p=quarantine et enfin à p=reject une fois certain que toutes vos sources d'envoi légitimes réussissent les contrôles. Passer directement à p=reject est de loin la manière la plus courante dont les équipes bloquent par accident leurs propres e-mails transactionnels ou marketing. La balise de politique elle-même est simple ; c'est la rigueur nécessaire pour progresser sans risque qui fait échouer la plupart des déploiements DMARC.
Ce que DMARC vérifie réellement
DMARC, défini dans la RFC 7489, n'authentifie pas un message à lui seul : il s'appuie sur SPF (Sender Policy Framework) et DKIM (DomainKeys Identified Mail) et indique aux serveurs de messagerie destinataires quoi faire lorsque les deux échouent. Un message réussit DMARC lorsqu'au moins l'un des deux, SPF ou DKIM, est validé et aligné avec le domaine affiché dans l'en-tête visible From:. L'alignement compte plus qu'on ne le pense : une validation SPF sur un autre domaine d'envoi, ou une signature DKIM provenant d'un domaine sans rapport, ne compte pas.
Un enregistrement DMARC est un enregistrement TXT publié sur _dmarc.yourdomain.com. Voici un exemple minimal :
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1"
Si vous n'avez pas encore configuré SPF, commencez par là (consultez notre guide comment créer un enregistrement SPF sécurisé), car DMARC sans aucun chemin d'envoi authentifié ne protège rien.
p=none, quarantine ou reject : quelle différence ?
La balise p= définit la politique que les destinataires sont invités à appliquer aux messages qui échouent à l'alignement DMARC. Il existe aussi une balise sp= pour les sous-domaines, qui hérite de p= si vous ne la définissez pas séparément.
| Politique | Ce que font les destinataires des e-mails en échec | Quand l'utiliser |
|---|---|---|
p=none |
Distribution normale, aucune application | Phase de surveillance : collecter les rapports, identifier chaque expéditeur légitime |
p=quarantine |
Placement dans le dossier spam/courrier indésirable | Lorsque les rapports ne montrent que des expéditeurs connus en échec (ou aucun) |
p=reject |
Rejet au niveau SMTP (renvoyé à l'expéditeur) | Application complète, lorsque vous avez entièrement confiance dans la liste des expéditeurs |
p=none sert uniquement à la surveillance : aucune action d'application n'est demandée, il ne peut donc pas nuire à la délivrabilité, mais il n'oppose non plus aucune résistance aux usurpateurs. p=quarantine et p=reject sont les réglages où DMARC commence à lutter réellement contre le phishing ; ce sont aussi ceux qui vous joueront des tours si une plateforme marketing ou un outil de facturation oublié envoie des e-mails depuis votre domaine sans réussir l'alignement SPF/DKIM.
WarningSi vous ne définissez pas
sp=, les sous-domaines héritent de la valeurp=du domaine principal. Unp=rejectsur le domaine racine rejette aussi les e-mails en échec provenant de tous les sous-domaines, sauf si vous le remplacez : auditez vos sous-domaines avant d'appliquer la politique.
Pourquoi les rapports DMARC sont indispensables avant toute application
La balise rua= indique où envoyer les rapports XML agrégés, et ruf= (moins largement prise en charge) où envoyer les rapports forensiques/d'échec. Ce sont les rapports agrégés qui comptent pour le déploiement : ils listent chaque IP source qui envoie des e-mails prétendant provenir de votre domaine, et indiquent si l'alignement SPF/DKIM a réussi ou échoué.
Sans rapports, passer de none à quarantine ou reject revient à deviner. Avec eux, cela devient une simple liste de contrôle :
- Chaque flux d'e-mails légitime (service transactionnel, plateforme marketing, support client, relais interne) apparaît dans les rapports comme réussi.
- Toute source inconnue est soit identifiée et corrigée, soit réellement non autorisée et peut être bloquée sans risque.
- Aucun expéditeur légitime à fort volume n'échoue à l'alignement à cause d'un include SPF mal configuré ou d'une signature DKIM manquante.
La plupart des outils de traitement de rapports sont des tableaux de bord tiers, car le XML brut est pénible à lire à la main ; mais pour les grandes agences ou les fondateurs qui gèrent une poignée de domaines, même un simple coup d'œil sur quelques semaines de rapports peut suffire à repérer un expéditeur illégitime.
Passer de p=none à p=reject sans risque
Un déploiement par étapes, réparti sur plusieurs semaines, est l'approche standard :
- Publiez
p=noneavecrua=renseigné. Laissez les rapports s'accumuler pendant au moins 1 à 2 semaines, plus longtemps si vous envoyez des e-mails par lots mensuels ou via des plateformes peu fréquentes (facturation, systèmes RH). - Corrigez chaque expéditeur légitime en échec. Ajoutez les includes SPF manquants, activez la signature DKIM sur la plateforme, ou assurez-vous que le domaine
From:correspond à ce que SPF/DKIM authentifient réellement. - Passez à
p=quarantineavec unpct=faible. La balisepct=n'applique la politique qu'à un pourcentage des messages en échec (100 par défaut si elle est omise) ; ainsi,p=quarantine; pct=10s'applique à environ un message en échec sur dix, un filet de sécurité le temps de confirmer qu'aucun e-mail légitime n'est intercepté. - Augmentez
pct=progressivement à 25, 50, puis 100 au fil des semaines, en surveillant les rapports à chaque étape. - Répétez le même processus par étapes pour
p=rejectau lieu de passer directement de quarantine à un reject complet. - Définissez
sp=explicitement une fois la politique appliquée au domaine racine, en particulier pour les sous-domaines qui n'envoient jamais d'e-mails : reject est alors le bon choix, puisqu'il n'y a aucun trafic légitime à perturber.
TipUtilisez notre générateur DMARC gratuit pour créer l'enregistrement avec l'ordre des balises et la syntaxe corrects : un seul
v=mal formé ou un point-virgule manquant suffit pour que les destinataires ignorent entièrement l'enregistrement, vous laissant sans aucune protection sans que vous le sachiez.
Mode d'alignement DMARC : relaxed ou strict
Deux autres balises déterminent le niveau d'exigence de la correspondance : adkim= pour l'alignement DKIM et aspf= pour l'alignement SPF. Le mode souple (r, par défaut) accepte une correspondance au niveau du domaine organisationnel : mail.example.com est aligné avec example.com. Le mode strict (s) exige une correspondance exacte. Le mode souple est le choix par défaut le plus sûr pour la plupart des configurations ; le mode strict mérite d'être envisagé une fois en p=reject, si vous souhaitez combler une faille d'usurpation via les sous-domaines.
Les fournisseurs de messagerie exigent-ils p=reject ?
Aucun grand fournisseur de messagerie n'impose p=reject. Les exigences de Google et Yahoo pour les expéditeurs en masse demandent un enregistrement DMARC publié avec au minimum p=none, et les recommandations de Microsoft préconisent elles aussi d'évoluer vers quarantine/reject au fil du temps, sans l'exiger d'emblée. Cela dit, p=none seul n'empêche en rien l'usurpation : c'est un mécanisme de reporting, pas une défense. Considérez-le comme la première étape d'un déploiement, pas comme la destination.
Synchroniser DMARC avec le reste de votre zone DNS
Les enregistrements DMARC, SPF et DKIM se trouvent tous dans le DNS sous forme d'enregistrements TXT, aux côtés de vos entrées MX et CAA ; consultez notre guide complet des types d'enregistrements DNS si vous auditez l'ensemble de la configuration e-mail d'un domaine. La gestion de ces enregistrements est plus simple lorsque les zones de tous vos domaines sont réunies au même endroit plutôt que dispersées entre plusieurs consoles de registrar.
Prêt à renforcer votre politique ? Gérez l'enregistrement avec nos outils de gestion DNS aux côtés du reste de votre zone, et utilisez le générateur DMARC pour rédiger correctement votre prochaine étape p=.
Questions fréquentes
#Que fait réellement p=none dans DMARC ?
Il ne demande aucune action d'application aux destinataires (les e-mails en échec sont distribués normalement), tandis que les rapports agrégés (via rua=) vous permettent de voir chaque source qui envoie au nom de votre domaine avant de durcir la politique.
#Peut-on passer directement à p=reject sans risque ?
Seulement si vous avez déjà confirmé, grâce aux rapports agrégés, que chaque source d'envoi légitime réussit SPF ou DKIM avec alignement ; sinon, les e-mails d'une plateforme oubliée seront purement et simplement rejetés. Un déploiement par étapes avec pct= est donc bien plus sûr.
#Quelle est la différence entre rua et ruf ?
rua= indique où envoyer les rapports XML agrégés de synthèse (utilisés pour surveiller le déploiement), tandis que ruf= indique où envoyer les rapports forensiques d'échec individuels ; la prise en charge de ruf varie toutefois selon les destinataires et est moins universellement implémentée.
#Faut-il définir sp= séparément de p= ?
Si sp= est omis, les sous-domaines héritent de la politique p= du domaine principal ; il est donc judicieux de définir sp= explicitement une fois reject appliqué, en particulier pour les sous-domaines qui n'envoient jamais d'e-mails.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
