# DMARC : passer de p=none à p=reject en 30 jours URL canonique : https://brew.new/fr/blog/dmarc-p-none-to-reject-in-30-days Rédigé par Thomas Park Publication : 2026-10-04 Mise à jour : 2026-10-04 DMARC est un enregistrement TXT publié sur `_dmarc.`. Il indique aux serveurs de réception que faire des e-mails qui utilisent votre domaine dans l’en-tête From mais échouent à la fois à SPF et à DKIM alignés, et où envoyer les rapports. `p=none` demande seulement des rapports, `p=quarantine` demande aux serveurs de réception de traiter les e-mails en échec comme suspects, et `p=reject` leur demande de les refuser. Gmail, Yahoo et Microsoft acceptent `p=none` de la part des expéditeurs en masse : beaucoup de domaines publient donc cette politique et s’arrêtent là, avec des rapports sur les usurpateurs mais sans les bloquer. L’analyse de 73,3 millions de domaines par Red Sift, citée en [avril 2026](https://redsift.com/blog/email-authentication-bespinlabs-redsift), montre que 14,9 % avaient une politique DMARC, quelle qu’elle soit, et que 2,5 % appliquaient `p=reject`. EasyDMARC, un autre éditeur de solutions DMARC, [indiquait en 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) que 62,7 % des entreprises du Fortune 500 dotées de DMARC utilisaient `p=reject`, contre 15,2 % des entreprises de l’Inc. 5000. Voici un plan de 30 jours pour atteindre `p=reject`, enregistrement par enregistrement, pour un domaine qui envoie depuis une messagerie professionnelle, un ou deux ESP, un outil de support et un outil de facturation. Trente jours conviennent à un sous-domaine d’envoi. Un domaine que vos équipes utilisent pour leurs e-mails du quotidien demande plus de temps. ## À retenir - Publiez `v=DMARC1; p=none; rua=mailto:...` le jour 1. Sans `rua`, les serveurs de réception ne doivent pas envoyer de rapports agrégés. - Chaque expéditeur légitime doit réussir SPF ou DKIM avec un alignement sur votre domaine From. Pour la plupart des outils, cela veut dire signer en DKIM avec votre domaine. - Ne dépassez pas 10 termes SPF générant une requête DNS, include imbriqués compris, sinon tous vos e-mails obtiennent `permerror`. - Passez à `p=quarantine` le jour 15 et à `p=reject` le jour 22, à chaque fois après une semaine de rapports sans anomalie. Pour un domaine que vos équipes utilisent au quotidien, la RFC 9989 demande un mois pour chacune des deux premières étapes. - La RFC 9989 (mai 2026) classe `pct` comme historique. Oubliez la montée progressive `pct=10`, `pct=50`. - BIMI exige `p=quarantine` ou `p=reject` sur le domaine organisationnel, pas de `sp=none`, un logo SVG Tiny PS et, pour Gmail, un VMC ou un CMC. ## Ce qui a changé dans DMARC en 2026 En mai 2026, l’IETF a remplacé la RFC 7489, un document informatif (Informational) de 2015, par DMARCbis : la [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), une proposition de norme (Proposed Standard) qui rend aussi obsolète la RFC 9091, complétée par la [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) pour les rapports agrégés. Trois changements comptent ici : - **`pct` devient historique.** L’annexe A.6 indique qu’il « n’était généralement pas appliqué avec précision, sauf si la valeur indiquée était 0 ou 100 ». - **`t=y` remplace `pct=0`.** Les serveurs de réception appliquent le niveau inférieur à votre politique : `p=reject; t=y` équivaut donc à quarantine. C’est un indicateur de test. - **`np` fait son apparition.** Il couvre les sous-domaines qui n’existent pas dans le DNS, et les anciens serveurs de réception doivent l’ignorer. Pour trouver le domaine organisationnel, un parcours de l’arborescence DNS (DNS tree walk) remplace par ailleurs la liste des suffixes publics (Public Suffix List). ## Les trois enregistrements dont dépend DMARC DMARC réussit quand SPF ou DKIM réussit **et** que le domaine validé est aligné sur le domaine From. Une seule réussite alignée suffit. ### SPF et la limite de 10 requêtes DNS SPF autorise des serveurs pour le domaine d’enveloppe (`MAIL FROM` ou Return-Path), la seule identité que DMARC prend en compte pour SPF, à l’exclusion de HELO. La [RFC 7208, section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) plafonne à 10 les termes générant une requête DNS : `include`, `a`, `mx`, `ptr`, `exists` et `redirect`, comptés à travers chaque include imbriqué. `ip4`, `ip6` et `all` ne comptent pas. Au-delà, le résultat est `permerror`. La même section autorise aussi au maximum deux « void lookups » (requêtes sans résultat), le plus souvent un include qui vise un nom d’hôte qui n’existe plus. ```dns example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all" ``` Cet enregistrement consomme déjà 4 requêtes avant même de compter ce que chaque éditeur imbrique : résolvez donc chaque include avec `dig +short TXT `, en descendant toute la chaîne. Pour ne pas dépasser 10, supprimez les outils abandonnés ou donnez à chaque ESP son propre sous-domaine de Return-Path, comme `bounce.example.com`, qui dispose de son propre budget de 10. Le [guide de configuration SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) de Microsoft recommande de terminer par `-all` sur les domaines qui utilisent aussi DKIM et DMARC. Par défaut, beaucoup d’ESP utilisent leur propre domaine de Return-Path, qui n’est pas aligné sur le vôtre. Configurez un Return-Path personnalisé ou appuyez-vous sur DKIM. ### DKIM : clés de 2048 bits, sélecteurs et rotation DKIM signe chaque message avec un domaine `d=` et un sélecteur `s=` ; le serveur de réception récupère la clé sur `._domainkey.`. Un outil qui signe avec `d=vendor-mail.example` réussit DKIM mais échoue à DMARC. Selon la [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html), les signataires doivent utiliser des clés RSA d’au moins 1024 bits et devraient utiliser 2048 bits. Les [consignes de Google pour les expéditeurs](https://support.google.com/mail/answer/81126) disent la même chose pour les envois vers des comptes Gmail personnels. Une clé de 2048 bits dépasse la limite de 255 caractères d’une chaîne TXT : elle est donc saisie sous forme de plusieurs chaînes entre guillemets dans un seul enregistrement, un découpage que la plupart des hébergeurs DNS font pour vous. ```dns s202610._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..." "...remainder-of-the-2048-bit-key...IDAQAB" ) ``` Donnez à chaque système d’envoi son propre sélecteur et ne réutilisez jamais un nom. Une date, comme `s202610`, garde l’historique lisible. Les [bonnes pratiques de rotation des clés](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) du M3AAWG recommandent une rotation au moins tous les six mois : 1. Publiez le nouveau sélecteur et laissez-le se propager. 2. Basculez la signature sur la nouvelle clé. 3. Laissez l’ancienne clé publique dans le DNS pendant 7 à 30 jours, pour que les e-mails en transit puissent être vérifiés. 4. Révoquez l’ancien sélecteur en publiant un `p=` vide. Ne le supprimez pas. ### Alignement : souple ou strict La RFC 9989 définit deux modes : | Mode | Balise | Domaine validé par SPF/DKIM | Domaine From | Aligné ? | |---|---|---|---|---| | Souple (relaxed, par défaut) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Oui, même domaine organisationnel | | Strict | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Non, les noms doivent être identiques | | L’un ou l’autre | | `vendor.example.net` | `example.com` | Non | La RFC 9989 note que « presque tous les propriétaires de domaines ont jugé l’alignement souple suffisant ». N’indiquez ni `aspf` ni `adkim`. L’alignement SPF strict est incompatible avec le Return-Path habituel sur un sous-domaine. ## Le plan sur 30 jours ![Calendrier DMARC sur 30 jours en quatre étapes : jours 1 à 7 en p=none avec rapports rua, jours 8 à 14 consacrés à la correction des expéditeurs, jour 15 en p=quarantine, jour 22 en p=reject, puis BIMI à partir du jour 30, avec l’enregistrement TXT exact de chaque étape.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *L’enregistrement de chaque étape. Ne passez à la suivante qu’après une semaine de rapports sans anomalie.* | Jours | Politique | Ce que vous faites | Condition pour passer à la suite | |---|---|---|---| | 1 à 7 | `p=none` | Publier avec `rua`, recenser chaque source | 7 jours de rapports de Google, Yahoo et Microsoft | | 8 à 14 | `p=none` | Corriger DKIM et SPF, retirer les expéditeurs inutilisés | Chaque source légitime réussit SPF ou DKIM aligné | | 15 à 21 | `p=quarantine` | Surveiller les e-mails légitimes mis en quarantaine | 7 jours sans échec d’une source légitime | | 22 à 30 | `p=reject` | Continuer à lire les rapports, ajouter `np=reject` | Stable pendant une semaine | | 30+ | `p=reject` | Lancer BIMI | Certificat délivré | Si la deuxième semaine révèle une source que personne ne peut corriger, restez en `p=none`. Rejeter vos propres factures est pire qu’appliquer la politique en retard. ### Jours 1 à 7 : publier p=none avec les rapports ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com" ``` Les rapports sont des fichiers XML compressés en gzip, envoyés au moins une fois par jour par chaque serveur de réception : faites donc pointer `rua` vers un service de traitement des rapports, pas vers une personne. Si l’adresse appartient à un autre domaine organisationnel, la RFC 9990 demande aux serveurs de réception de l’ignorer, sauf si `example.com._report._dmarc.` l’autorise. Les services de traitement publient cet enregistrement ; pour vos propres domaines, ajoutez-le vous-même. Publiez un seul et unique enregistrement DMARC. Si des assistants de configuration laissent deux enregistrements `v=DMARC1` sur `_dmarc.example.com`, les serveurs de réception les ignorent tous les deux. Laissez `ruf` de côté. La RFC 9989 note que les serveurs de réception soucieux de la confidentialité expurgent fortement les rapports d’échec, voire ne les envoient pas, et la FAQ de l’[annonce de Microsoft consacrée aux expéditeurs à fort volume](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) précise que Microsoft envoie les rapports `rua` et ne prévoit pas d’envoyer de rapports `ruf`. ### Comment lire un rapport agrégé La RFC 9990 décrit des rapports XML « quotidiens (ou plus fréquents) », un par domaine de politique. Voici un enregistrement, adapté de son exemple : ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` Dans `policy_evaluated`, `dkim` et `spf` sont des résultats d’**alignement**, et `disposition` indique ce que le serveur de réception a fait. `auth_results` contient les résultats bruts et leurs domaines. Ici, les deux réussissent pour `vendor.example`, et les deux échouent donc à l’alignement : c’est le signe d’un éditeur qui envoie sous votre nom sans signer avec votre domaine. Activez son DKIM personnalisé ou son authentification de domaine. ### Jours 1 à 7 : identifier les expéditeurs inconnus Regroupez par `source_ip`, `envelope_from` et par couple `domain` + `selector` DKIM, triez par `count`, puis classez les résultats : | Ce que montre le rapport | Cause probable | Action | |---|---|---| | DKIM ou SPF aligné réussi | Configuration correcte | Aucune | | DKIM et SPF réussis pour des domaines d’éditeurs | Outil SaaS qui utilise sa propre identité | Activer le DKIM personnalisé | | DKIM aligné réussi, SPF en échec, IP d’un fournisseur de messagerie ou d’une liste de diffusion | Transfert ou liste de diffusion | En général aucune. Le DKIM aligné résiste au transfert | | Pas de DKIM, SPF en échec, IP non identifiables | Usurpation | Aucune. C’est précisément ce que `p=reject` bloque | Pour identifier une IP, lancez `dig -x 192.0.2.123 +short` et regardez le sélecteur, qui porte souvent le nom de l’éditeur. Demandez ensuite à la finance, au support et aux ventes ce qui envoie des e-mails au nom de l’entreprise : facturation, outil de support, invitations d’agenda, scanners de bureau. Les e-mails transférés et ceux des listes de diffusion échoueront d’une manière que vous ne pouvez pas corriger, et la [FAQ de Google pour les expéditeurs](https://support.google.com/mail/answer/14229414) n’exige pas d’alignement pour eux : ne les attendez donc pas pour avancer. ### Jours 8 à 14 : corriger chaque source légitime Partez du `count` le plus élevé et descendez : 1. **Messagerie professionnelle** (Google Workspace, Microsoft 365). Activez DKIM dans la console d’administration, en 2048 bits si c’est proposé, et vérifiez que l’include du fournisseur figure dans SPF. 2. **ESP et outils marketing.** Configurez l’authentification de domaine pour qu’ils signent avec votre `d=`, ainsi qu’un Return-Path personnalisé si c’est proposé. 3. **Support, facturation, CRM.** Même chose que pour les ESP. Si l’un d’eux ne peut pas signer avec votre domaine, utilisez un sous-domaine pour lequel il peut signer, ou son propre domaine. 4. **Outils abandonnés.** Supprimez leurs include et leurs sélecteurs. Recomptez ensuite les requêtes DNS de SPF. ### Jour 15 : p=quarantine ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com" ``` En pratique, la quarantaine se traduit le plus souvent par un classement en spam. Surveillez les sources légitimes dont la disposition est `quarantine`. Pour un essai à blanc, `p=quarantine; t=y` demande aux serveurs de réception conformes à la RFC 9989 d’appliquer `none`, mais la RFC n’a que quelques mois et tous les serveurs de réception ne respectent pas encore `t`. ### Jour 22 : p=reject ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com" ``` Les serveurs de réception qui respectent `p=reject` refusent les e-mails en échec pendant la session SMTP, mais la RFC 9989 leur demande de les mettre en quarantaine quand la politique est leur seul élément pour trancher : une partie atterrit donc en spam. La même RFC précise qu’un domaine en `p=reject` « ne doit pas (MUST NOT) s’appuyer uniquement sur SPF » et doit signer avec DKIM, car le transfert casse SPF mais pas DKIM. Vérifiez d’abord le DKIM aligné sur chaque source. Gardez `rua` pour toujours. Le nouvel outil adopté le trimestre prochain apparaîtra dans vos rapports avant de remonter dans la file de votre support. ### Quand allonger le plan Selon la section 7.4 de la RFC 9989, les domaines dont les utilisateurs envoient des messages à des listes de diffusion « ne devraient pas (SHOULD NOT) » publier `p=reject`, et ceux qui le font devraient d’abord passer « au moins un mois » en `p=none` et « une période tout aussi longue » en `p=quarantine`. C’est le cas de la plupart des domaines racines d’entreprise : accordez-y donc un mois à chacune des deux premières étapes. Un sous-domaine utilisé uniquement par votre ESP ne génère aucun trafic de liste de diffusion et peut garder le rythme de 30 jours. ### Politique des sous-domaines : sp= et np= `p` couvre le domaine et ses sous-domaines. `sp` remplace `p` pour les sous-domaines existants, et `np` pour les sous-domaines inexistants. Un sous-domaine qui a son propre enregistrement utilise celui-ci, et la RFC 9989 y ignore `sp`. Un sous-domaine d’envoi dédié comme `mail.example.com`, utilisé par un seul ESP avec SPF et DKIM vérifiés, peut publier `p=reject` dès le premier jour. `p=none; sp=reject` sur le domaine racine protège les sous-domaines pendant que vous terminez le domaine principal, mais bloque BIMI. Les domaines parkés devraient publier `v=spf1 -all`, selon le guide SPF de Microsoft, ainsi que `v=DMARC1; p=reject;` sur `_dmarc`. ## Jour 30 et au-delà : BIMI BIMI affiche votre logo à côté des e-mails authentifiés dans les boîtes de réception compatibles : | Exigence | Détail | Source | |---|---|---| | Politique DMARC | `p=quarantine` ou `p=reject` sur le domaine organisationnel et sur le domaine From | Draft BIMI | | Politique des sous-domaines | Si `sp` est publié, pas `none` | Draft BIMI | | Pourcentage | Avec quarantine, `pct` ne doit pas être inférieur à 100 | Draft BIMI | | Logo | SVG Tiny PS : `baseProfile="tiny-ps"`, `version="1.2"`, un ``, ni scripts ni références externes, ni `x=` ni `y=` sur l’élément racine | BIMI Group | | Certificat | Gmail exige un VMC (marque déposée, coche) ou un CMC (sans marque déposée, sans coche) | Google | Le [draft BIMI](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) en est à sa révision 14 (mai 2026). C’est toujours un Internet-Draft rédigé sur la base de la RFC 7489, d’où la présence de `pct`. N’indiquez pas `pct` et ne définissez pas `t=y`. La règle du domaine organisationnel piège les expéditeurs qui envoient depuis un sous-domaine : avec `mail.example.com` en `p=reject` et `example.com` en `p=none`, les serveurs de réception ne doivent pas afficher le logo. Le domaine racine doit donc lui aussi aller au bout du plan. Les [recommandations SVG du BIMI Group](https://bimigroup.org/creating-bimi-svg-logo-files/) préconisent un logo carré, centré, sur un fond uni, de moins de 32 Ko. Google a [ajouté la prise en charge des CMC en septembre 2024](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). L’enregistrement, selon le [guide de mise en œuvre du BIMI Group](https://bimigroup.org/implementation-guide/) : ```dns default._bimi.example.com. 3600 IN TXT "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem" ``` L’enregistrement d’une marque prend des mois : si vous visez un VMC, lancez les démarches dès maintenant. ## Ce qu’exigent Gmail, Yahoo et Microsoft Aucun des trois n’exige une politique appliquée : seulement un enregistrement DMARC et l’alignement. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Seuil | Près de 5 000 par jour vers des comptes Gmail personnels, par domaine principal, définitif une fois atteint | Expéditeurs en masse, sans chiffre précis | Plus de 5 000 par jour vers outlook.com, hotmail.com et live.com, par domaine From | | SPF et DKIM | Les deux | Les deux | Les deux doivent réussir | | DMARC | Enregistrement obligatoire, `p=none` accepté | Au moins `p=none`, `rua` fortement recommandé | Au moins `p=none` | | Alignement | SPF ou DKIM | SPF ou DKIM, le mode souple suffit | SPF ou DKIM | | En cas d’échec | Rejets temporaires et définitifs depuis novembre 2025 | Non précisé | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Sources : les [consignes de Google pour les expéditeurs](https://support.google.com/mail/answer/81126) et leur [FAQ](https://support.google.com/mail/answer/14229414), les [bonnes pratiques de Yahoo pour les expéditeurs](https://senders.yahooinc.com/best-practices/), ainsi que l’[annonce d’avril 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) et la [page d’assistance sur l’erreur 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) de Microsoft. Microsoft a commencé à appliquer ces règles le 5 mai 2025, après une mise à jour du 29 avril qui a remplacé le classement en courrier indésirable par le rejet. La FAQ de Google indique que l’alignement à la fois de SPF et de DKIM « deviendra à terme une exigence pour les expéditeurs » : alignez donc les deux dès la deuxième semaine. Pour les taux de désabonnement et de spam, consultez [ce qui s’applique toujours quand un agent envoie vos e-mails](/fr/blog/agent-email-deliverability) et notre [guide de la délivrabilité](/fr/blog/email-deliverability). ## DMARC sur un domaine d’envoi Brew La [configuration de domaine](https://docs.brew.new/get-started/verify-your-sending-domain) de Brew demande : - **DKIM** : un enregistrement TXT sur un sélecteur `._domainkey` de votre domaine d’envoi. Obligatoire. - **SPF** : un enregistrement MX et un enregistrement TXT sur `send.<your sending domain>`, le Return-Path de Brew. Obligatoire. - **DMARC** : un enregistrement TXT sur `_dmarc.<your sending domain>`. Facultatif, mais recommandé. - Un **CNAME** pour le suivi des clics, uniquement avec un sous-domaine de suivi personnalisé. Le domaine peut envoyer dès que SPF et DKIM sont vérifiés, et Brew propose une valeur DMARC adaptée : ```dns ; dedicated sending subdomain, e.g. mail.example.com _dmarc.mail.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com" ; apex domain, or a domain Brew can't prove is dedicated _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" ``` Un sous-domaine dédié reçoit `p=reject`, car rien n’envoie depuis ce sous-domaine avant la vérification du SPF et du DKIM de Brew. Un domaine racine reçoit `p=none`, car vos autres outils envoient probablement aussi en son nom : suivez donc le plan ci-dessus. L’alignement reste souple, car le Return-Path `send.<domain>` n’est aligné qu’en mode souple. Brew lit l’enregistrement `_dmarc.<sending domain>` en vigueur à l’ajout du domaine, à sa vérification et à chaque nouvelle vérification. La page **Domaines** affiche le résultat, tout comme `get_domain_health` via MCP et `GET /v1/domains/{domainId}/health` : - **`dmarc_missing`** : un avertissement, avec l’enregistrement exact à ajouter. - **`dmarc_invalid`** : deux enregistrements DMARC sur ce nom, une version ou une politique incorrecte, ou des balises en double. Le message indique l’enregistrement à supprimer. - **Vérifié** : dès qu’un seul et unique enregistrement valide est trouvé. La configuration DNS automatique n’écrit l’enregistrement DMARC que s’il n’en existe aucun : elle ne crée donc jamais de doublon. La vérification porte sur le domaine d’envoi, pas sur son domaine parent : donnez donc à chaque sous-domaine d’envoi son propre enregistrement, y compris à celui des [e-mails transactionnels](/fr/blog/transactional-emails) si vous séparez les deux comme le conseille la documentation. C’est dans votre outil de traitement `rua` que vous lisez les rapports et décidez quand passer à reject. ## Questions fréquentes ### Combien de temps rester en p=none avant de passer à quarantine ? Jusqu’à ce qu’une semaine complète de rapports montre que chaque source légitime réussit SPF ou DKIM aligné, ce qui prend en général une à deux semaines pour un sous-domaine d’envoi. Pour un domaine que vos équipes utilisent au quotidien, la RFC 9989 demande au moins un mois. Deux ans en `p=none` sans que personne lise les rapports ne valent rien. ### La balise DMARC pct est-elle obsolète ? Oui. La RFC 9989 classe `pct` comme « historique » et remplace ses seules valeurs fiables par `t` : `t=y` se comporte comme `pct=0`, et `t=n` comme `pct=100`. Les anciens serveurs de réception peuvent encore lire `pct`, mais n’ont jamais appliqué les valeurs intermédiaires de façon cohérente : avancez donc par étapes entières. ### p=reject va-t-il bloquer mes e-mails transférés ? Un simple transfert casse généralement SPF, mais pas DKIM : le DKIM aligné réussit donc toujours. Les listes de diffusion qui modifient l’objet ou le pied de page cassent DKIM, et certaines réécrivent l’en-tête From pour compenser. Un DKIM aligné partout reste votre meilleure protection. ### Gmail et Yahoo exigent-ils p=reject ? Non. Tous deux exigent des expéditeurs en masse qu’ils publient DMARC, et acceptent `p=none`, tout comme Microsoft au-delà de 5 000 messages par jour vers Outlook.com. Une politique appliquée bloque l’usurpation et elle est indispensable pour BIMI, mais aucun des trois ne l’exige. ### Faut-il un VMC pour BIMI ? Pour Gmail, il vous faut un VMC, qui exige une marque déposée et affiche une coche, ou un CMC, qui affiche le logo sans coche. Selon le [BIMI Group](https://bimigroup.org/understanding-bimi-certificate-types/), quelques fournisseurs, dont Yahoo et Fastmail, affichent aussi des logos auto-déclarés, sans certificat.