Un message qui échoue à DMARC sur votre domaine d’expéditeur et qui tombe sous une politique p=quarantine finit en dossier spam chez Gmail et en dossier Junk Email ou en quarantaine chez Microsoft. Le passage depuis p=none vers la politique DMARC quarantine se décide sur un seuil de travail courant. Visez au moins 95 % de vos envois légitimes alignés en SPF ou en DKIM, mesurés sur vos rapports RUA pendant un mois complet. La RFC 9989 publiée en mai 2026 a changé la manière de monter en charge : le tag pct= est retiré de la spécification et un tag t= prend sa place.
Ce guide donne le seuil d’alignement, la durée de la phase de quarantine et le contenu exact de l’enregistrement TXT _dmarc. Il détaille aussi ce que Gmail et Outlook font du message et comment revenir à p=none si une source légitime se retrouve en spam. Pour la mise en place complète des enregistrements SPF et DKIM, l’article voisin Configurer DMARC étape par étape : de p=none à p=reject couvre l’amont.
Quand passer de p=none à p=quarantine
Passez en quarantine lorsque 95 % au moins de votre volume légitime aligne SPF ou DKIM sur le domaine du From: et que ce taux tient quatre semaines de suite. Pour les domaines dont les utilisateurs écrivent sur des mailing lists, la RFC 9989 (section 7.4) recommande un mois minimum de p=none, puis une période équivalente en p=quarantine avant d’envisager reject.
Le texte ne fixe aucun pourcentage. Les 95 % sont une règle de travail courante. Certaines équipes postmaster exigent 98 % avant p=reject. Sous 95 % la cause la plus fréquente est une plateforme tierce (un CRM ou un outil de ticketing) qui signe avec son propre domaine. La section 5.1.6 de la RFC est formelle sur ce point : les flux légitimes qui échouent doivent être corrigés avant toute politique d’enforcement.
Google propose un rythme plus court dans sa page Recommended DMARC rollout : une semaine de surveillance en p=none suffit en général selon lui quand les rapports couvrent tous les flux. Dès que vous avez des expéditeurs saisonniers (relances de fin de mois ou campagnes trimestrielles) le mois de la RFC reste la base prudente.
Quarantine ou reject : le traitement chez le récepteur
Avec quarantine le domaine déclare le message suspect mais possiblement légitime. Avec reject il le déclare invalide. La RFC 9989 (section 4.7) emploie ces deux formulations et, à la section 5.4, laisse le traitement final au récepteur.
| Critère | p=quarantine | p=reject |
|---|---|---|
| Définition RFC 9989 (§4.7) | Échec jugé suspect, message peut-être valide | Échec jugé comme un usage invalide du domaine |
| Gmail (documentation Google) | Message marqué spam et envoyé dans le dossier indésirables du destinataire | Message refusé ; un message de rejet est généralement renvoyé (documentation Google) |
| Microsoft 365 (documentation Microsoft) | Dossier Junk Email ou quarantaine selon la configuration du tenant | Refus SMTP en 550 5.7.1 |
| Risque pour le courrier légitime | Récupérable dans les indésirables (Gmail) ou dans la quarantaine (Microsoft, selon la politique du tenant) | Refusé à l’entrée par la plupart des récepteurs, alias et mailing lists compris (RFC 9989, §7.4). Le RFC demande de ne pas rejeter sur cette seule base, sans garantie |
| Effet sur le spoofing | Écarte le message de la boîte de réception. Il reste accessible au destinataire | Bloque à l’entrée quand le récepteur applique la politique |
Le comportement décrit vient de la page « Set up DMARC » de Google, qui parle du serveur récepteur en général et que nous appliquons à Gmail. Le comportement Outlook et Microsoft 365 est décrit dans la documentation Microsoft Defender for Office 365, qui précise que ce traitement s’applique quand le réglage « Honor DMARC record policy » est actif. Yahoo exige de son côté un enregistrement DMARC valide avec au moins p=none pour les expéditeurs en volume (Yahoo Sender Hub, bonnes pratiques) et n’y prescrit ni quarantine ni pourcentage.
Un récepteur reste libre de ne pas suivre votre politique. La section 5.4 de la RFC 9989 l’écrit noir sur blanc : le traitement final relève de la politique locale du récepteur, qui peut même mettre en spam un message qui passe DMARC. Une politique reject sans autre analyse doit d’ailleurs être traitée comme quarantine (section 7.4), parce que les mailing lists cassent l’alignement.
pct= et t= : ce que devient le déploiement progressif
La RFC 9989 supprime pct= et ajoute t=. Avec t=y vous demandez au récepteur d’appliquer un cran en dessous de votre politique : quarantine devient none et reject devient quarantine. Avec t=n, valeur par défaut, la politique s’applique en entier.
Trois points changent la manière de s’en servir. Le tag n’affecte pas la génération des rapports : vos RUA continuent d’arriver pendant la phase de test. Il n’a aucun effet sur un p=none. Et il se règle une fois pour tous les messages du domaine : il n’existe pas d’échelle de pourcentages.
La raison de ce retrait figure à l’annexe A.6 :
« the « pct » tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default) » (RFC 9989, annexe A.6)
Autrement dit les valeurs intermédiaires comme pct=10 étaient appliquées avec des écarts d’un récepteur à l’autre. Seuls 0 et 100 se comportaient de manière prévisible. Le tag t=y reprend le rôle de pct=0 et t=n celui de pct=100, comme l’indique la même annexe. Le registre IANA de la section 9.3 classe désormais pct comme « historic ».
Reste la question du terrain. Microsoft documente encore pct= dans sa page DMARC mise à jour en juillet 2026 et affiche dans Authentication-Results les valeurs action=pct.quarantine ou action=pct.reject pour les messages échantillonnés. Google recommande toujours pct pendant un déploiement. Aucune des deux pages ne mentionne t=. Nous n’avons trouvé aucune documentation de ces deux récepteurs sur la lecture de t=, donc nous ne pouvons pas affirmer qu’ils l’appliquent.
La section 4.8 de la RFC impose d’ignorer les tags inconnus. Un récepteur qui ne connaît plus pct l’ignore et applique la politique à 100 %. Un récepteur resté sur la RFC 7489 ignore t=. Publier les deux tags dans le même enregistrement pendant la transition est donc valide pour chacun des deux : le premier lit t=y et le second lit le pourcentage. Cette lecture est une déduction tirée de la règle des tags inconnus ; la RFC ne la formule nulle part.
Le piège de l’ancienne méthode subsiste. À pct=10 les 90 % de messages frauduleux restants sont livrés normalement et à t=y tous le sont. Ces tags limitent les dégâts d’une source légitime oubliée. Le phishing sur votre domaine n’est traité qu’à t=n avec une politique pleine.
Publier l’enregistrement TXT _dmarc et le valider
L’enregistrement se publie en TXT sur le nom _dmarc.votre-domaine.com. Le tag v=DMARC1 doit venir en premier sinon le récepteur ignore tout l’enregistrement (RFC 9989, section 4.7). Pour une première phase de quarantine :
v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-rua@votre-domaine.com
Une fois les rapports sains, la version complète devient v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@votre-domaine.com, puisque t=n est la valeur par défaut. Vérifiez ensuite le résultat avec dig +short TXT _dmarc.votre-domaine.com ou nslookup -type=TXT _dmarc.votre-domaine.com. Deux contrôles évitent la plupart des échecs silencieux. D’abord, un seul enregistrement _dmarc doit exister : face à dmarc=permerror, Microsoft recommande de le vérifier. Ensuite, la chaîne doit bien commencer par v=DMARC1. Si votre éditeur DNS découpe la valeur en plusieurs chaînes entre guillemets la RFC prévoit qu’elles soient concaténées avant lecture (section 4.5).
sp= et np= pour les sous-domaines
Sans tag complémentaire p=quarantine s’applique aussi à tous les sous-domaines. Le tag sp= fixe une politique pour les sous-domaines existants et ne vise jamais le domaine principal. Le tag np=, repris de la RFC 9091 par la RFC 9989, vise les sous-domaines inexistants. Si np est absent le récepteur se rabat sur sp puis sur p (section 4.7).
Un attaquant qui usurpe facture-urgente.votre-domaine.com utilise un sous-domaine qui n’existe pas dans votre DNS. Aucun expéditeur légitime n’en émet, donc np=reject peut être publié tôt avec un risque faible, si aucun de vos systèmes n’envoie depuis un sous-domaine absent du DNS, ce que vos rapports RUA confirment :
v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:dmarc-rua@votre-domaine.com
Un récepteur qui n’implémente pas encore np l’ignore et applique sp.
Lire Authentication-Results et les rapports RUA avant de monter
Un message mis en quarantine laisse une trace dans l’en-tête Authentication-Results. La RFC 9989 (section 5.4) demande aux récepteurs qui s’écartent de la politique publiée d’ajouter au minimum cet en-tête. Chez Microsoft 365 un échec sous quarantine s’affiche ainsi :
dmarc=fail action=quarantine header.from=votre-domaine.com
Un message aligné affiche dmarc=pass. Cet en-tête sert au diagnostic message par message ; la décision de monter en politique se prend sur les agrégats RUA. Chaque ligne d’un rapport donne l’IP source et le nombre de messages. Elle indique aussi la disposition appliquée par le récepteur et les résultats SPF et DKIM alignés. Pour apprendre à les trier et à repérer les expéditeurs inconnus, voir l’article sur l’analyse des rapports DMARC agrégés.
Trois lectures décident du passage. Le taux d’alignement global sur le volume légitime doit rester au-dessus de 95 %. Aucune IP de vos propres systèmes ne doit échouer de façon répétée. Et l’essentiel des échecs doit venir d’IP que vous ne reconnaissez pas, ce qui prouve que p=none a déjà rempli sa mission. Les échecs du transfert d’emails se retirent du calcul : un forwarder casse SPF et un corps modifié casse DKIM. Les rapports RUF ajoutent du détail mais beaucoup de récepteurs les expurgent ou n’en envoient pas (RFC 9989, section 5.3.9) ; ils ne fondent donc jamais la décision.
Une fois l’alignement stable, gardez la quarantine à politique pleine pendant un mois avant p=reject. La RFC 9989 (section 7.4) déconseille d’ailleurs reject aux domaines dont les utilisateurs écrivent sur des mailing lists.
Les alignements qui échouent le plus souvent
SPF « pass » ne suffit pas à passer DMARC. L’alignement exige que le domaine du Return-Path ou celui de la signature DKIM corresponde au domaine du From:. Une plateforme qui envoie en From: @votre-domaine.com avec son propre Return-Path et sans DKIM signé sur votre domaine échoue à chaque envoi, même avec un SPF vert. Microsoft illustre exactement ce cas : bounce.adatum.com en MAIL FROM, SPF pass, DMARC fail. La correction passe par la signature DKIM avec votre domaine, détaillée dans la checklist de diagnostic SPF pour la partie Return-Path.
Le mode d’alignement compte aussi : en relaxed, valeur par défaut des tags adkim et aspf, un sous-domaine du From: suffit ; en strict, les domaines doivent être identiques.
Le transfert d’emails est la seconde source d’échecs artificiels. La section 7.4 de la RFC 9989 constate que la plupart des mailing lists contournent la ligne From:. Elle ajoute que la méthode ARC, malgré 10 ans de travaux, n’est pas devenue courante à la date de publication. DKIM survit au transfert quand le corps n’est pas modifié. La RFC impose donc aux domaines en reject de ne pas s’appuyer sur SPF seul.
Rollback : revenir à p=none sans perdre la collecte
Si une source légitime part en spam publiez p=none et conservez le tag rua. La RFC 9989 (section 5.4) interdit aux récepteurs de modifier le traitement du courrier sous p=none. Le retour arrière met donc fin à l’application de DMARC aux nouveaux envois une fois le TTL écoulé. Les autres filtres du récepteur restent actifs.
- Réduisez le TTL de l’enregistrement
_dmarcà 300 secondes avant de monter en politique, pour que la correction se propage vite. - Remplacez
p=quarantineparp=noneet retirez t=, qui n’a aucun effet à ce niveau. - Identifiez dans les prochains agrégats RUA l’IP et le domaine de la source en échec.
- Corrigez la signature DKIM ou le
Return-Pathde cette source puis attendez de nouveaux rapports alignés. - Republiez p=quarantine; t=y et reprenez la phase de test.
Le retour arrière n’extrait pas les messages déjà déposés en spam : ceux-ci restent chez le destinataire. Le TTL de 300 secondes est une pratique DNS courante et non une exigence de la RFC.
Questions fréquentes
Faut-il encore écrire pct= dans un enregistrement DMARC ?
La RFC 9989 ne le définit plus. Google et Microsoft le documentent encore. Pendant la transition, publiez pct= et t=y ensemble : chaque récepteur ignore le tag qu’il ne connaît pas.
Combien de temps rester en p=quarantine ?
Un mois minimum d’après la RFC 9989 (section 7.4) quand vos utilisateurs écrivent sur des mailing lists. Sinon, tout dépend de vos cycles d’envoi : un expéditeur trimestriel doit voir un cycle complet dans ses rapports.
Un message en quarantine est-il perdu ?
Non. Le destinataire peut le retrouver en spam chez Gmail. Chez Microsoft 365 il se trouve en Junk Email ou en quarantaine. Sous reject, le message est refusé pendant la session SMTP et personne ne peut le récupérer.
