p=none, quarantine ou reject : lequel choisir

La politique DMARC est l’instruction que vous publiez à l’intention des serveurs du monde entier. Elle ne s’applique qu’aux messages qui échouent à DMARC, c’est-à-dire à ceux dont ni SPF ni DKIM ne sont à la fois valides et alignés sur le domaine affiché. Un message légitime correctement configuré n’est jamais concerné, quelle que soit la valeur.

C’est le malentendu le plus coûteux de ce sujet. Un domaine en p=none a un enregistrement DMARC valide, apparaît comme « conforme » dans la plupart des vérificateurs en ligne, et coche la case des questionnaires d’assurance. Il ne bloque pourtant pas un seul message usurpé.

p=none existe pour une raison, et une seule : découvrir. Pendant les premières semaines d’une mise en place, il fait arriver les rapports quotidiens qui révèlent les services envoyant légitimement en votre nom, sans risquer de bloquer l’un d’eux par erreur. C’est un échafaudage. Un échafaudage laissé en place trois ans n’est plus un échafaudage, c’est un aveu.

Les exigences de Google, Yahoo et Microsoft pour les expéditeurs à fort volume demandent « au moins p=none ». Cette formulation est souvent lue comme une recommandation ; c’est un plancher d’admissibilité, pas un objectif.

La quarantaine est un palier, pas une destination. Elle a une vertu réelle pendant la montée en charge : si un expéditeur légitime a été oublié, ses messages atterrissent dans les indésirables du destinataire au lieu de disparaître, et quelqu’un finit par s’en apercevoir.

Sa faiblesse est du même ordre : le message reste accessible. Un client qui attend une facture et ne la voit pas arriver va chercher dans ses indésirables, l’y trouve, et la traite. Contre une fraude au faux RIB, la quarantaine ne fait que ralentir.

La balise pct= indique la proportion de messages en échec à laquelle la politique s’applique, de 1 à 100. Sa valeur par défaut est 100. Elle sert à durcir progressivement : p=quarantine; pct=25 met un quart des messages en échec en indésirable, et laisse passer les trois autres quarts.

Le piège est dans le repli. Les messages non retenus par pct= ne sont pas traités comme si la politique était none : ils reçoivent la politique immédiatement inférieure. Avec p=reject; pct=25, un quart des messages est rejeté et les trois autres quarts sont mis en quarantaine, pas livrés. C’est un comportement raisonnable, et ce n’est presque jamais celui auquel on s’attend.

En l’absence de sp=, les sous-domaines héritent de la politique publiée sur le domaine principal. C’est le comportement souhaitable dans presque tous les cas : un fraudeur qui ne peut pas usurper exemple.fr essaiera compta.exemple.fr, qui n’a jamais existé et que personne ne surveille.

sp= sert à l’exception inverse : un sous-domaine qui envoie via un prestataire pas encore aligné, que l’on veut laisser en observation pendant que le domaine principal est déjà en rejet. C’est une mesure temporaire, à documenter et à dater, sans quoi elle devient une porte laissée ouverte.

1. Le domaine n’envoie aucun e-mail (domaine parqué, marque défensive, ancien nom) : publiez p=reject immédiatement, avec un SPF vide. Aucune période d’observation n’est nécessaire, puisqu’il n’y a rien de légitime à casser.
2. Le domaine envoie et vous ne connaissez pas encore tous ses expéditeurs : p=none avec rua, pour deux à quatre semaines. Pas davantage.
3. Les rapports sont propres, tous les expéditeurs légitimes sont alignés : p=quarantine pendant une à deux semaines, en surveillant.
4. Rien n’a bougé du mauvais côté : p=reject, puis adkim=s; aspf=s une fois le rejet stabilisé.

La marche à suivre détaillée, avec ce qu’il faut vérifier à chaque palier, est dans l’article sur le passage en rejet.

La politique ne s’applique qu’aux messages affichant exactement votre domaine. Un message venu d’un domaine sosie n’est pas concerné, quelle que soit la valeur de p= : il n’échoue pas à votre DMARC, il ne le rencontre jamais.

Elle est par ailleurs une instruction, pas une garantie d’exécution. La quasi-totalité du volume mondial est traitée par des serveurs qui l’honorent, mais un serveur d’entreprise mal tenu peut parfaitement l’ignorer.