Avec p=none, votre enregistrement DMARC ne protège pas votre domaine : il demande aux serveurs de réception de ne rien changer à leur traitement, même quand un message échoue à DMARC. Un usurpateur peut donc toujours envoyer des emails à votre nom. p=none sert à observer, grâce aux rapports rua, avant de passer à p=quarantine puis p=reject. Ce passage se prépare : il faut d'abord recenser tous les services qui envoient des emails pour vous. Voici la méthode, étape par étape, avec un calendrier type.
Ce que dit vraiment p=none
La norme DMARC (RFC 7489, remplacée en mai 2026 par la RFC 9989) définit trois politiques pour le tag p :
| Politique | Ce que vous demandez aux récepteurs | Effet sur un email usurpé |
|---|
p=none | Aucune action particulière, envoi des rapports | Traité comme n'importe quel autre email |
p=quarantine | Traiter l'email comme suspect | Placé le plus souvent dans les spams |
p=reject | Refuser l'email | Rejeté pendant la transaction SMTP, jamais livré |
La RFC 7489 est explicite : une politique p=none ne doit pas modifier le traitement habituel des messages. L'email frauduleux reste soumis aux filtres antispam classiques du destinataire, ni plus ni moins. DMARC ne joue aucun rôle de barrière.
Pourquoi autant de domaines restent-ils en p=none ? Parce que c'est le minimum exigé par Google et Yahoo depuis février 2024, puis par Microsoft depuis mai 2025, pour les expéditeurs de plus de 5 000 emails par jour. Beaucoup de domaines ont publié p=none pour être conformes, puis n'y ont plus touché. Nous détaillons ces règles dans les exigences DMARC de Google, Yahoo et Microsoft.
Pourquoi p=none reste quand même utile
p=none a un vrai rôle : c'est la phase d'observation. Les récepteurs vous envoient des rapports agrégés à l'adresse indiquée dans rua. Vous y voyez, pour chaque adresse IP qui a envoyé des emails avec votre domaine dans le From, le volume et le résultat SPF, DKIM et DMARC.
Sans tag rua, les récepteurs ne génèrent aucun rapport agrégé. Un p=none sans rua n'apporte donc rien du tout. Vérifiez votre enregistrement actuel :
dig +short TXT _dmarc.votre-domaine.fr
Un enregistrement d'observation correct ressemble à ceci :
"v=DMARC1; p=none; rua=mailto:dmarc@votre-domaine.fr"
Pour lire les fichiers XML reçus, suivez notre guide de lecture des rapports DMARC rua.
| Tag | Rôle | Valeur par défaut |
|---|
p | Politique du domaine | Obligatoire |
sp | Politique des sous-domaines | Celle de p |
rua | Adresse des rapports agrégés | Aucune (pas de rapport) |
adkim / aspf | Alignement DKIM / SPF : r (relâché) ou s (strict) | r |
pct | Pourcentage des emails en échec auxquels appliquer la politique (RFC 7489) | 100 |
t | Mode test (RFC 9989) : t=y pour tester, t=n pour appliquer | Absent : politique appliquée |
L'alignement, la cause n°1 d'échec
DMARC ne se contente pas d'un SPF ou d'un DKIM valide. Il faut que le domaine validé corresponde au domaine visible dans le From. En alignement relâché (le défaut), mail.votre-domaine.fr s'aligne avec votre-domaine.fr. En revanche, un outil d'emailing qui signe avec son propre domaine passe DKIM mais échoue à DMARC. C'est le cas le plus fréquent dans les rapports.
pct et t : faire monter la pression progressivement
La RFC 7489 a prévu pct pour un déploiement progressif. Avec p=quarantine; pct=25, la quarantaine s'applique à environ 25 % des emails en échec. Avec p=reject; pct=50, la moitié des emails en échec est rejetée et l'autre moitié est traitée comme en quarantaine.
La RFC 9989, publiée en mai 2026, supprime pct et le remplace par t=y, un simple mode test sans pourcentage. Les deux syntaxes ne sont pas forcément lues de la même façon par tous les récepteurs pendant la transition. En pratique, une montée par paliers de pct reste lisible par les récepteurs qui appliquent encore la RFC 7489. Ne comptez pas sur des pourcentages exacts : faites surtout confiance aux rapports.
sp : ne pas oublier les sous-domaines
Sans sp, les sous-domaines héritent de la politique p. Un attaquant peut utiliser facture.votre-domaine.fr même si ce sous-domaine n'existe pas. Si un sous-domaine envoie des emails légitimes depuis un autre service, il peut avoir son propre enregistrement _dmarc. La RFC 9989 ajoute aussi np, la politique des sous-domaines inexistants.
Le risque principal : le prestataire oublié
Passer en p=reject trop vite bloque vos propres emails. Les rapports DMARC servent justement à repérer tout ce qui envoie au nom de votre domaine. La liste est souvent plus longue qu'on ne le pense :
- la messagerie principale (Google Workspace, Microsoft 365, OVHcloud MX Plan ou Email Pro) ;
- l'outil d'emailing ou de newsletter ;
- le site e-commerce (confirmations de commande PrestaShop, WooCommerce, Shopify) ;
- le CRM, l'outil de support, le logiciel de facturation ;
- le formulaire de contact du site WordPress, qui envoie parfois depuis le serveur d'hébergement ;
- les copieurs-scanners et les applications métier qui envoient des notifications.
Pour chaque source légitime, l'objectif est un DKIM aligné : le service signe avec une clé publiée sur votre domaine. Ajoutez aussi le service dans le SPF quand il le demande, sans dépasser la limite de 10 requêtes DNS. Notre article sur les erreurs SPF neutral, softfail et permerror détaille cette limite.
Restent les cas qui échouent malgré une configuration correcte : transferts automatiques et listes de diffusion qui modifient le message. Ils apparaissent dans les rapports avec un SPF en échec. Un DKIM aligné qui survit au transfert règle la plupart d'entre eux.
Calendrier type : de p=none à p=reject
La RFC 9989 rappelle que le passage à une politique restrictive ne doit intervenir qu'une fois tout le courrier légitime authentifié, ce qui peut prendre plusieurs mois. Le calendrier ci-dessous convient à une PME avec quelques services d'envoi. Allongez chaque étape si les rapports montrent encore des sources légitimes en échec.
| Période | Enregistrement | Ce que vous faites |
|---|
| Semaines 1 à 4 | p=none; rua=… | Collecter les rapports, lister toutes les sources d'envoi |
| Semaines 3 à 8 | p=none; rua=… | Configurer DKIM et SPF pour chaque source légitime |
| Semaines 8 à 10 | p=quarantine; pct=25; rua=… | Vérifier qu'aucune source légitime n'échoue |
| Semaines 10 à 14 | p=quarantine; rua=… | Quarantaine complète, surveiller les retours des utilisateurs |
| Semaines 14 à 18 | p=reject; pct=25; rua=… | Premiers rejets, contrôle des rapports |
| Ensuite | p=reject; rua=… | Protection complète, rapports lus chaque mois |
Le critère pour passer à l'étape suivante est simple : dans les rapports des deux dernières semaines, toutes les sources que vous reconnaissez passent DMARC. Ce qui échoue encore doit être de l'usurpation ou un transfert identifié.
Les étapes concrètes
- Publiez ou corrigez l'enregistrement d'observation avec une adresse
rua que quelqu'un lit vraiment, ou un service d'analyse. Le générateur DMARC produit la ligne à copier dans votre zone DNS.
- Inventoriez les sources à partir des rapports : regroupez les IP par service (Google, Microsoft, outil d'emailing, hébergeur).
- Corrigez chaque source : activation DKIM sur votre domaine, ajout au SPF si nécessaire. Contrôlez le résultat avec l'outil sécurité email.
- Passez en quarantaine par palier, en prévenant l'équipe : un email interne qui finit en spam doit être signalé.
- Passez en rejet quand les rapports sont propres. Gardez le
rua : un nouveau prestataire mal configuré apparaîtra immédiatement.
Exemple d'enregistrement final :
_dmarc.votre-domaine.fr. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@votre-domaine.fr"
Domaine qui n'envoie aucun email : passez directement en reject
Un domaine secondaire, une ancienne marque ou un domaine de redirection n'envoie aucun email. Il n'y a rien à observer. Publiez directement une politique de rejet et un SPF vide :
votre-domaine.fr. IN TXT "v=spf1 -all"
_dmarc.votre-domaine.fr. IN TXT "v=DMARC1; p=reject; sp=reject"
C'est l'une des protections les plus simples contre l'usurpation, et elle est souvent oubliée sur les domaines dormants.
Après le passage en reject : surveiller la dégradation
Une politique p=reject peut disparaître sans que personne ne s'en aperçoive : migration de DNS, changement d'hébergeur, modification manuelle par un prestataire. Domains Defender surveille la configuration email de vos domaines (SPF, DKIM, DMARC) et vous alerte quand elle se dégrade, par exemple un passage de reject à none ou un enregistrement supprimé. Il ne lit pas les rapports rua : pour eux, il faut un outil d'analyse dédié. Vous pouvez tester un domaine gratuitement avec l'audit complet.
Questions fréquentes
Que veut dire p=none dans DMARC ?
p=none signifie que vous ne demandez aucune action aux récepteurs sur les emails qui échouent à DMARC. Ils les traitent normalement. Vous recevez seulement des rapports si un tag rua est présent.
Combien de temps rester en p=none ?
Le temps d'identifier et de corriger toutes vos sources d'envoi légitimes : quelques semaines pour une petite structure, plusieurs mois pour une organisation avec de nombreux outils. Rester en p=none plusieurs années n'a pas d'intérêt.
p=none suffit-il pour Gmail, Yahoo et Outlook ?
Pour la conformité des expéditeurs de plus de 5 000 emails par jour, oui : Google, Yahoo et Microsoft acceptent p=none comme minimum. Pour protéger votre domaine contre l'usurpation, non.
Faut-il passer par quarantine avant reject ?
C'est recommandé. La quarantaine limite les dégâts si une source légitime a été oubliée : l'email arrive en spam au lieu d'être perdu. Un domaine qui n'envoie aucun email peut, lui, passer directement en p=reject.
Le tag pct fonctionne-t-il encore ?
La RFC 9989 de mai 2026 l'a retiré au profit de t=y. Un enregistrement contenant pct reste valide, mais les récepteurs qui appliquent la nouvelle norme peuvent l'ignorer. Utilisez-le comme une sécurité temporaire, pas comme un réglage précis.