Guide · Courriel
DMARC : p=none, quarantine et reject
Ce que chaque politique demande aux destinataires, comment tester un changement sans faire de reject une destination automatique, et les erreurs qui menacent les courriels légitimes.
Réponse courte
Que font réellement p=none, quarantine et reject ?
p=none demande aux serveurs de réception de ne pas modifier leur traitement à cause de DMARC. p=quarantine demande de traiter les échecs avec méfiance, souvent comme indésirables, et p=reject demande le rejet. Ce sont des préférences publiées par le propriétaire du domaine : le serveur destinataire garde sa propre décision.
Un passage vers l’application se décide après avoir validé toutes les sources d’envoi dans les rapports. p=reject n’est pas une destination automatique : la norme actuelle le déconseille aux domaines de messagerie générale dont les utilisateurs participent à des listes de diffusion.
Trois enregistrements, trois rôles
Ils travaillent ensemble, et aucun ne suffit seul.
SPF déclare quels serveurs ont le droit d’envoyer pour votre domaine. C’est une liste d’adresses autorisées, publiée dans votre zone DNS.
DKIM ajoute une signature cryptographique à chaque message. Le serveur qui reçoit vérifie la signature avec une clé publiée dans votre DNS. Si le message a été modifié en route, la signature ne correspond plus.
DMARC relie ces contrôles au domaine visible dans le champ « De », publie une préférence de traitement pour les échecs et peut demander des rapports. Le serveur de réception utilise ce signal avec ses propres règles.
À retenir
SPF et DKIM authentifient des domaines techniques. DMARC vérifie leur alignement avec le domaine visible, exprime une préférence et organise les rapports agrégés.
L’alignement, la partie qui surprend
C’est le point qui fait échouer les configurations en apparence correctes.
DMARC ne se contente pas d’un SPF ou d’un DKIM qui passe. Il exige que le domaine validé corresponde à celui que le destinataire voit dans le champ « De ». Un service d’infolettre peut très bien signer avec son propre domaine : SPF passe, DKIM passe, et DMARC échoue quand même parce que rien ne correspond à votre domaine.
C’est pourquoi la configuration se vérifie avec des rapports plutôt qu’avec un envoi de test réussi.
Détail technique
Deux modes existent, réglés par adkim et aspf : strict, où les domaines doivent être identiques, et relâché, où un sous-domaine suffit. Le mode relâché est la valeur par défaut et convient à la grande majorité des organisations.
Un seul des deux mécanismes doit s’aligner pour que DMARC passe. DKIM résiste souvent mieux qu’SPF à un transfert simple, tant que l’intermédiaire ne modifie pas les parties signées du message.
p=none n’est pas une protection
Beaucoup de domaines s’arrêtent là et se croient couverts. Ils ne le sont pas.
p=none demande aux serveurs de réception de ne pas modifier leur traitement à cause de DMARC. Si l’enregistrement contient une adresse de rapport et qu’un serveur participe aux rapports, il peut envoyer des données agrégées. La politique elle-même ne bloque aucun message usurpé.
Sa valeur est l’observation : les rapports agrégés peuvent révéler des sources légitimes et non autorisées qui utilisent le domaine, sans garantir un inventaire complet.
À retenir
Rester en p=none pendant des années, c’est avoir installé un compteur et cru qu’on avait installé une serrure.
La progression, palier par palier
Chaque palier se franchit quand les rapports le permettent, pas quand le calendrier le dit.
-
Publier p=none avec une adresse de rapport
Le tag rua demande l’envoi de rapports agrégés à l’adresse indiquée. Sans lui, aucun rapport agrégé n’est demandé ; les serveurs ne sont pas obligés de participer.
-
Lire les rapports sur un cycle représentatif
Ils arrivent en XML et sont conçus pour être traités par un outil. La période doit couvrir les envois rares autant que les envois quotidiens.
-
Corriger chaque source légitime
Faire aligner SPF ou DKIM pour chacune. C’est le vrai travail, et il prend l’essentiel du temps.
-
Passer en quarantine
Quand les rapports ne montrent plus d’échec légitime. Les messages douteux partent dans les indésirables plutôt que d’être refusés.
-
Décider si reject convient réellement
Pour un domaine d’envoi bien délimité, les rapports peuvent justifier cette préférence. Pour un domaine utilisé par des personnes et des listes de diffusion,
p=rejectpeut casser des flux légitimes et ne devrait pas être le choix par défaut.
Attention
Avant toute politique d’application, vérifiez que toutes les sources légitimes s’alignent et analysez les flux indirects. Même avec p=reject, le serveur destinataire ne doit pas rejeter un message sur ce seul signal.
Le mode de test actuel : t=y
La norme DMARC actuelle, RFC 9989, a retiré le tag pct : son application variait trop d’un serveur à l’autre. Un nouvel enregistrement ne devrait donc pas proposer pct=25 ou une autre progression par pourcentage.
Le tag t=y signale maintenant un test de la politique annoncée. Avec p=quarantine; t=y, l’attente est un traitement au niveau none. Avec p=reject; t=y, l’attente est un traitement au niveau quarantine. Les rapports continuent d’être produits lorsqu’ils sont demandés.
Détail technique
t=y reste une préférence adressée au serveur destinataire, comme les politiques p, sp et np. Il ne remplace ni les rapports, ni la vérification des flux légitimes, ni la décision explicite de retirer le mode de test.
Le tag n’a aucun effet sur p=none. La valeur par défaut est t=n, qui demande l’application de la politique annoncée.
Les sous-domaines, souvent oubliés
Votre politique DMARC couvre le domaine et, par défaut, ses sous-domaines. Le tag sp permet de leur appliquer une politique différente.
C’est utile dans un cas précis : vous voulez passer le domaine principal en reject tout en laissant un sous-domaine d’envoi en quarantine le temps de le corriger.
C’est aussi un piège : un sous-domaine laissé en sp=none pendant des années redevient une porte ouverte pour l’usurpation, précisément parce que personne ne le regarde.
À retenir
Les sous-domaines qui n’envoient jamais de courriel devraient être verrouillés explicitement, pas laissés sans politique.
Les erreurs qui coûtent le plus cher
Cinq reviennent constamment.
À éviter
- Plusieurs enregistrements SPF la norme interdit qu’une vérification sélectionne plusieurs enregistrements ; cette configuration peut produire une erreur permanente.
- Passer en application sans rapports vous expose à perdre des courriels légitimes sans avoir recensé les sources concernées.
- Publier DMARC sans adresse rua la préférence peut être utilisée, mais aucun rapport agrégé ne sera demandé pour vous montrer les flux concernés.
- Oublier les services tiers facturation, recrutement, réservation, signature électronique. Ils envoient en votre nom et personne ne les a listés.
- Présenter p=none comme une protection c’est un mode d’observation ; il ne demande aucun traitement particulier des échecs.
Si vous n’êtes pas certain de l’état de vos enregistrements, ils sont publics : n’importe qui peut les lire, y compris vous. Un doute sur leur interprétation se lève en quelques minutes avec quelqu’un qui les lit tous les jours.
Questions fréquentes
Combien de temps faut-il pour arriver à reject ?
Il n’existe pas de délai universel, et reject peut ne pas convenir au domaine. La norme indique que l’analyse peut prendre plusieurs mois. Pour un domaine utilisé par des personnes qui participent à des listes de diffusion, elle recommande de ne pas publier p=reject.
DMARC empêche-t-il de recevoir du hameçonnage ?
Non. DMARC protège votre domaine contre l’usurpation par d’autres. Il ne filtre pas ce qui arrive dans votre propre boîte, ce qui relève de votre fournisseur de courriel.
Faut-il DKIM si SPF est en place ?
Oui. Un transfert casse généralement l’alignement SPF. Une signature DKIM valide peut survivre à un transfert simple si le message n’est pas modifié, ce qui fournit une seconde voie pour réussir DMARC.
Les rapports sont illisibles, comment faire ?
Ils sont en XML et destinés à être traités par un outil. Plusieurs services les agrègent en tableaux lisibles, y compris à petit volume. Sans cela, l’étape d’observation n’apporte rien.
Un doute sur votre configuration ?
Écrivez-nous en indiquant votre domaine. Nous lirons vos enregistrements publics avec vous et vous dirons ce qu’ils font réellement, sans engagement.
Nous écrire Ce que vous pouvez vérifier vous-même