--- service: "Publicasta" schema_version: "1.0" article_id: 231 title: "DMARC p=none surveille, mais ne protège pas" language: "fr" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=fr" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=fr" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=fr" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-07-30T13:42:19+00:00" updated_at: "2026-07-30T13:42:19+00:00" translations: - language: "ar" html_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ar" markdown_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=ar" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=ar" - language: "de" html_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=de" markdown_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=de" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=en" markdown_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=en" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=es" markdown_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=es" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=zh" markdown_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.md?lang=zh" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=zh" --- # DMARC p=none surveille, mais ne protège pas > CipherCue estime que 68.4% des company domains vérifiés n’enforce pas DMARC. La réponse n’est pas la panique ni une ligne DNS, mais inventaire, alignment et passage progressif à quarantine ou reject. Un enregistrement DMARC peut donner l’impression que l’email security progresse, tout en ne bloquant presque rien. C’est le point gênant des chiffres de CipherCue: sur 67,336 company domains vérifiés entre le 14 avril et le 28 juillet 2026, 68.4% n’avaient pas de DMARC ou restaient en `p=none`. ![Politique DMARC passant de monitoring à quarantine et reject gates](https://publicasta.com/storage/projects/9/pages/231/2026/07/bb85c602-86e5-4f63-ab7e-017230fb9583.webp) Ce n’est pas une nouvelle faille. C’est un contrôle inachevé. DMARC existe publiquement depuis 2012 et, en mai 2026, l’IETF a remplacé RFC 7489 par RFC 9989, RFC 9990 et RFC 9991. Le protocole central est maintenant Standards Track Proposed Standard. Le blocage se situe ailleurs: passer de “nous collectons des rapports” à “nous demandons aux destinataires de rejeter l’usurpation de notre domaine”. DMARC est utile, mais ce n’est pas une solution magique contre le phishing. Il traite surtout l’exact-domain spoofing dans le From visible. Il ne bloque pas les domaines ressemblants, le display-name spoofing, les comptes légitimes compromis, ni les campagnes envoyées depuis de grandes plateformes avec une authentification valide. DMARC s’appuie sur SPF et DKIM. SPF indique quels serveurs peuvent envoyer pour le domaine. DKIM signe les messages avec une clé de domaine. DMARC vérifie si l’identité authentifiée s’aligne avec le visible From domain et indique quoi faire en cas d’échec. Les trois politiques courantes sont simples. `p=none` surveille et produit des reports. `p=quarantine` demande de traiter les messages échoués comme suspects. `p=reject` demande de les rejeter. Les récepteurs gardent une marge de décision, mais `p=none` reste une alarme qui écrit des logs, pas une porte fermée. Dans le snapshot de CipherCue, 30,362 domains, soit 45.1%, n’avaient aucun DMARC record. Parmi ceux qui en avaient un, 15,709 étaient en `p=none`, 10,258 en `p=quarantine` et 10,963 en `p=reject`. CipherCue définit enforcement comme `p=quarantine` ou `p=reject`; 46,071 domains du sample étaient donc non-enforcing. La prudence s’impose. CipherCue parle de son tracked entity set, pas d’un échantillon représentatif de toutes les entreprises. Des commentaires Hacker News ont aussi posé une question valable: combien de domaines étaient parked, inactive, send-only ou sans MX normal? Cela ne supprime pas le problème, mais évite une conclusion trop large. Si l’écart persiste, c’est parce que `p=reject` n’est pas une simple ligne DNS. C’est un inventaire. Il faut connaître tous les services qui envoient au nom du domaine: Microsoft 365 ou Google Workspace, CRM, marketing automation, billing, helpdesk, HR tools, ticketing, anciens serveurs, scanners, prestataires et applications oubliées. Chaque flux doit avoir SPF ou DKIM alignment. Les unknown senders doivent être corrigés, déplacés vers un subdomain ou arrêtés. Les rapports sont eux aussi un obstacle. Les aggregate reports DMARC, décrits séparément dans RFC 9990, sont du XML lisible par machine. Pour une petite organisation qui a copié un exemple de DNS record, cela ressemble vite à une pile de fichiers sans décision claire. La peur de casser du courrier légitime est fondée. Si le système de facturation échoue DKIM alignment, `p=reject` peut faire disparaître des factures. Si une plateforme support envoie par une route mal configurée, enforcement peut déclencher des plaintes clients. Personne ne veut améliorer la sécurité et casser les password resets. Microsoft a décrit en janvier 2026 des attaques de phishing exploitant complex routing et des spoof protections mal configurées. C’est un rappel utile: routing, connectors, forwarding et gateways modifient la façon dont authentication apparaît côté destinataire. La bonne migration est progressive. Commencez par l’inventaire des domaines: primary sending domains, marketing subdomains, transactional subdomains, parked domains et domaines qui ne doivent jamais envoyer d’email. Pour les no-send domains, SPF `v=spf1 -all` et DMARC `p=reject; sp=reject` ferment souvent une voie simple d’abus. Pour les active domains, `p=none` doit rester une phase temporaire. Utilisez une adresse de reporting réellement suivie et un outil qui transforme le XML en décisions. Corrigez ensuite alignment, surtout DKIM pour les services tiers et le mail transféré. Avancez par étapes: `p=none`, puis `p=quarantine`, puis `p=reject`. Surveillez helpdesk tickets, bounce logs, deliverability dashboards et DMARC reports. Documentez l’owner, la platform, le domain/subdomain, la méthode d’authentification et le rollback contact pour chaque sender. DMARC ne fait pas disparaître le phishing. Mais enforcement supprime une astuce bon marché: envoyer un message qui semble venir directement de votre domaine alors que authentication échoue. `p=none` est utile pour apprendre qui envoie pour vous; comme état final, c’est un contrôle qui observe au lieu de protéger.