DMARC quarantine ou reject : quelle différence ?
ChatGPT
Claude
Gemini
Perplexity
GrokL’essentiel
DMARC quarantine ou reject : ce que chaque politique demande aux récepteurs, quand reject pose des problèmes d’interopérabilité et comment choisir sans risque.
Avec p=quarantine, DMARC demande aux récepteurs de traiter les messages en échec DMARC comme suspects ; avec p=reject, le propriétaire du domaine juge ces échecs comme un usage invalide du domaine et demande leur rejet. (RFC 9989, valeurs de politique) Le récepteur décide du résultat final, et la bonne politique dépend des chemins d’envoi légitimes et du risque d’interopérabilité, pas d’une règle voulant que tout domaine finisse en reject. (RFC 9989, latitude du récepteur)
| Question | p=quarantine | p=reject |
|---|---|---|
| Que demande le propriétaire ? | Tenir les échecs DMARC pour suspects | Tenir les échecs pour un usage invalide du domaine |
| Que peut le récepteur ? | Classer en indésirables, retenir, marquer ou appliquer une règle locale | Rejeter pendant SMTP, supprimer après acceptation, accepter par dérogation ou appliquer une règle locale |
| Le résultat est-il garanti ? | Non ; la politique du récepteur prime | Non ; la politique du récepteur prime |
| Quand l’envisage-t-on ? | Une fois les expéditeurs légitimes connus, pour un signal plus fort sans demander un rejet pur et simple | Une fois les expéditeurs légitimes connus, pour les domaines dont les flux rendent le rejet acceptable |
| Risque principal | Un vrai e-mail en échec peut être masqué ou retardé | Un vrai e-mail en échec peut être rejeté ou supprimé |
Les deux politiques ne jouent qu’après un échec DMARC. Un message réussit DMARC quand au moins un identifiant SPF ou DKIM authentifié réussit et s’aligne sur le domaine From visible ; réussir DMARC ne garantit pas pour autant la boîte de réception. (RFC 9989, alignement des identifiants et traitement final)
Que fait une politique DMARC quarantine ?
DMARC p=quarantine indique que le propriétaire du domaine juge un échec DMARC suspect. Un récepteur participant peut en tenir compte dans son filtrage, mais DMARC n’oblige aucun fournisseur à placer le message dans un dossier spam récupérable. (RFC 9989, définition de quarantine)
La nuance compte pendant le déploiement. Quarantine peut réduire les chances qu’un message en échec atteigne la boîte de réception, mais un message légitime peut aussi être retardé, masqué ou traité d’une façon que l’expéditeur ne peut annuler. Trouvez les échecs légitimes avec les rapports agrégés et des tests de messages avant de demander quarantine ; ce n’est pas un mode test sans perte.
Que fait une politique DMARC reject ?
DMARC p=reject indique que le propriétaire du domaine juge les échecs DMARC comme un usage invalide du domaine. La RFC 9989 préfère le rejet SMTP quand un récepteur rejette, mais documente aussi la suppression silencieuse et autorise les récepteurs à passer outre la préférence publiée. (RFC 9989, rejet des messages)
Reject est donc le signal le plus fort du propriétaire, pas la garantie que chaque message en échec rebondit ou disparaît. Il ne répare pas non plus l’authentification. Si une plateforme de facturation, un support ou un service de newsletter légitime échoue encore à l’alignement, publier p=reject peut faire rejeter cet e-mail par les récepteurs qui suivent la demande.
DMARC reject est-il plus sûr que quarantine ?
DMARC reject demande un traitement plus fort contre l’usurpation directe du domaine, mais n’est pas forcément le choix le plus sûr pour tout domaine. Le gain : moins de messages en échec atteignent les utilisateurs. Le coût : plus de perturbations quand un e-mail légitime échoue à DMARC ou qu’une liste de diffusion casse l’alignement.
La RFC 9989 ajoute une limite qu’ignorent souvent les anciens conseils : les domaines aux utilisateurs généralistes qui écrivent souvent à des listes de diffusion ne devraient normalement pas publier p=reject, le rejet pouvant créer des problèmes d’interopérabilité. La RFC conseille à ces domaines de collecter des rapports en p=none, puis de passer à p=quarantine, et d’évaluer les échecs restants et l’effet sur les listes avant une demande plus stricte. (RFC 9989, domaines d’e-mail généralistes)
Quelle politique DMARC choisir ?
Réglez DMARC sur p=none tant que le propriétaire découvre encore ses chemins d’envoi légitimes ou ne peut prévoir l’effet de l’application sur l’interopérabilité. Une fois les expéditeurs importants alignés en SPF ou DKIM, choisissez p=quarantine si un traitement suspect colle aux preuves, ou p=reject si rejeter ou supprimer les échecs restants est une demande acceptable. Les domaines généralistes dont les utilisateurs écrivent souvent à des listes devraient normalement rester en quarantine plutôt que publier reject, sauf si leurs preuves rendent le risque acceptable. (RFC 9989, domaines d’e-mail généralistes)
Comment choisir entre quarantine et reject ?
Choisissez entre quarantine et reject à partir des flux réels du domaine :
- Recensez les e-mails du domaine. Les rapports agrégés DMARC révèlent chaque service qui envoie avec le domaine dans l’adresse From visible.
- Validez l’alignement sur de vrais messages. Utilisez l’analyseur d’en-têtes pour lire les résultats d’authentification d’un message type de chaque flux important ; un enregistrement DNS public seul ne prouve pas l’alignement.
- Repérez le risque d’interopérabilité. Vérifiez si des utilisateurs généralistes passent par des listes, des transferts ou d’autres chemins qui modifient les messages ou l’authentification.
- Choisissez la demande de traitement. Prenez quarantine si un traitement suspect colle aux preuves, et reject seulement si l’usage du domaine et les échecs restants rendent le rejet acceptable.
- Surveillez après le changement. Nouveaux fournisseurs ou réglages peuvent créer des échecs légitimes sous chaque politique.
Prenons un domaine qui envoie via son fournisseur de messagerie, sa plateforme de support et son logiciel de facturation. Si les deux premiers ont un DKIM aligné réussi mais que la facturation n’a qu’un SPF réussi non aligné, le domaine ne peut pas durcir sa politique sans risquer ce flux, sauf si le propriétaire l’accepte ou le retire. Surveillez pendant la correction ou le retrait voulu de la facturation. Si le domaine a aussi des utilisateurs qui écrivent à des listes, évaluez l’alerte d’interopérabilité de la RFC 9989 avant de juger reject acceptable.
Le drapeau de test RFC 9989 change-t-il le déploiement ?
Le drapeau t=y de la RFC 9989 demande aux récepteurs de ne pas appliquer la politique publiée pendant que le propriétaire la teste. Le repli prévu d’un niveau va de p=quarantine; t=y à none, ou de p=reject; t=y à quarantine ; les rapports DMARC restent générés et les récepteurs restent libres. (RFC 9989, drapeau de test t)
Le drapeau reprend une partie du rôle de l’ancienne balise pct, mais ce n’est pas un échantillonnage en pourcentage. La RFC 9989 a supprimé pct : ne publiez pas une politique stricte avec pct=10 en supposant que chaque récepteur appliquera ce pourcentage. (RFC 9989, suppression de pct)
Utilisez le générateur DMARC pour la syntaxe actuelle et le test DMARC pour voir ce que publie le DNS. Aucun des deux ne prouve que chaque expéditeur de production s’aligne ni ne prédit le traitement final du récepteur.
Vérifiez le DNS, puis l’e-mail réel
Commencez par le test DMARC gratuit pour confirmer la politique publiée. Comparez ensuite les rapports agrégés aux en-têtes de chaque flux de production important avant de modifier l’enregistrement ; l’enregistrement public seul ne prouve pas que le domaine est prêt pour l’application.
L’agent DMARC de Palisade transforme les rapports agrégés DMARC en flux de travail priorisé pour identifier les expéditeurs, examiner les problèmes d’authentification et d’alignement, et gérer un chemin plus sûr vers l’application. Les récepteurs gardent la décision finale, et Palisade ne garantit pas la livraison ni ne bloque lui-même de messages.
Preuve
Sources et pour aller plus loin
Questions des lecteurs
Questions fréquentes
p=quarantine met-il toujours l’échec en spam ?
Non. DMARC p=quarantine demande de traiter l’e-mail en échec comme suspect, mais le récepteur choisit le traitement final. Le dossier indésirables est une option ; quarantaine administrative, marquage, filtrage ou autre action locale sont aussi possibles. (RFC 9989, politique et traitement du récepteur)
p=reject garantit-il un rejet ?
Non. DMARC p=reject est une préférence du propriétaire, pas un rejet garanti. La RFC 9989 décrit le rejet SMTP et la suppression silencieuse, et permet aux récepteurs d’accepter un message en échec par dérogation locale. (RFC 9989, rejet des messages)
Un transfert peut-il passer DMARC en reject ?
Un e-mail transféré peut réussir DMARC si une signature DKIM alignée survit au transfert. Le transfert casse souvent SPF, et un transfert ou une liste qui modifie le contenu signé peut aussi casser DKIM : testez le vrai chemin au lieu de supposer qu’un transfert réussit ou échoue toujours. (RFC 9989, flux indirects)
Faut-il p=quarantine avant p=reject ?
DMARC ne fait pas de quarantine un prérequis universel de reject. La RFC 9989 recommande toutefois une période de suivi puis de quarantine pour les domaines généralistes dont les utilisateurs écrivent à des listes, et un passage par étapes fondé sur les preuves réduit le risque pour l’e-mail légitime. (RFC 9989, interopérabilité des listes)
Rédigé par
Samuel ChenardCEO et cofondateur, Palisade
Samuel Chenard est CEO et cofondateur de Palisade, logiciel DMARC agentique pour équipes IT et MSP, d’un domaine à des milliers.
Lire Samuel →