--- service: "Publicasta" schema_version: "1.0" article_id: 231 title: "DMARC p=none is monitoring, not protection" language: "en" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=en" json_url: "https://publicasta.com/cybersecurity/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30.json?lang=en" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/dmarc_p_none_enforcement_gap_email_spoofing_2026_07_30?lang=en" 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:18+00:00" updated_at: "2026-07-30T13:42:18+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 is monitoring, not protection > CipherCue found that 68.4% of checked company domains still do not enforce DMARC. The fix is not panic or one DNS line, but sender inventory, alignment and a staged move to quarantine or reject. A DMARC record can look like email security progress while doing almost nothing to block spoofed mail. That is the uncomfortable part of the latest numbers from CipherCue: in a dataset of 67,336 company domains checked between April 14 and July 28, 2026, 68.4% either had no DMARC record or had one set to `p=none`. ![DMARC email policy moving from monitoring to quarantine and reject gates](https://publicasta.com/storage/projects/9/pages/231/2026/07/bb85c602-86e5-4f63-ab7e-017230fb9583.webp) This is not a new zero-day. It is a half-finished control. DMARC has been public since 2012, and in May 2026 the IETF replaced the original RFC 7489 with the newer RFC 9989, RFC 9990 and RFC 9991 family. The core protocol is now on the Standards Track as a Proposed Standard. The problem is not that nobody has heard of it. The problem is the last mile between "we collect reports" and "we ask receivers to reject fraudulent use of our domain". The calm version is this: DMARC is useful plumbing, not magic. It helps stop one specific class of abuse, exact-domain spoofing in the visible From address. It does not stop lookalike domains, display-name tricks, compromised real accounts, or phishing sent from a major platform with valid authentication. But if your company domain can still be spoofed directly, attackers have an unnecessary shortcut. DMARC sits on top of SPF and DKIM. SPF says which mail servers may send for a domain. DKIM lets mail be signed with a domain key. DMARC asks whether either authenticated identity aligns with the visible From domain, then tells receiving mail systems what the domain owner wants done when alignment fails. That policy has three common states. `p=none` means monitor and report. The receiver can still deliver the message. `p=quarantine` asks the receiver to treat failing messages suspiciously, often by putting them in spam. `p=reject` asks the receiver to reject failing messages. Receivers keep discretion, but the difference matters. `p=none` is an alarm that writes logs. It is not a locked door. CipherCue's snapshot makes the gap visible. Of 67,336 checked domains, 30,362, or 45.1%, had no DMARC record. Among domains that did publish a record, 15,709 were at `p=none`, 10,258 at `p=quarantine`, and 10,963 at `p=reject`. CipherCue counts enforcement as `p=quarantine` or `p=reject`, so 46,071 domains in the sample were non-enforcing. There are caveats. CipherCue says this is its tracked entity set, not a statistically representative sample of every company in the world. Hacker News commenters also raised a fair methodological question: how many domains in such datasets are parked, inactive, send-only, or otherwise not normal mail domains with MX records? That does not erase the issue, but it should keep the claim precise. This is a large vendor dataset showing a large enforcement gap, not a census of the internet. The gap persists because `p=reject` is not just a DNS edit. It is an inventory project. To move safely, an organization has to know every legitimate service that sends as its domain: Microsoft 365 or Google Workspace, CRM, marketing automation, billing, helpdesk, HR tools, ticketing systems, legacy servers, outsourced mailers, scanners, monitoring tools, and the strange little app someone configured three years ago. Each stream needs SPF or DKIM alignment. Unknown senders have to be fixed, moved to subdomains, or retired. Someone has to read the aggregate reports. Those reports are their own pain point. DMARC aggregate reports, now specified separately in RFC 9990, are machine-readable XML. That is good for automation and miserable for a small organization that only copied a sample DNS record and has no tool to turn reports into decisions. CipherCue also found fragmented reporting destinations: thousands of distinct domains receiving reports, many appearing only once in its extracted `rua=` data. That matches the practical mess admins describe. The fear of breaking mail is real. If a legitimate invoice system fails DKIM alignment, `p=reject` can make invoices disappear. If a customer support platform sends as the company domain through a poorly configured route, strict enforcement can create tickets from angry customers. If a newsletter vendor uses the wrong From domain, marketing notices bounce. Nobody wants to be the person who "improved security" and broke password resets. Microsoft's January 2026 write-up on phishing through complex routing and misconfigured spoof protections is a useful reminder that this is not theoretical. Routing, connectors, forwarding and security gateways can all change what authentication looks like at the receiver. Microsoft also points out that enforced authentication can reject or quarantine spoofed mail when configured correctly. The phrase "configured correctly" is doing a lot of work. Google and Yahoo's recent sender requirements have pushed more organizations toward proper SPF, DKIM and DMARC. Google Workspace guidance tells bulk senders to set up SPF or DKIM and DMARC for sending domains, and Google has raised requirements for high-volume senders. That helps. It does not automatically mean every domain should jump from no record to `p=reject` in one afternoon. The better path is staged and boring. Start with a domain inventory. Separate primary sending domains, marketing subdomains, transactional subdomains, parked domains and domains that should never send mail. For no-send domains, publish strict records such as SPF `v=spf1 -all` and DMARC `p=reject; sp=reject` where appropriate. That removes easy spoofing paths without touching production mail streams. For active domains, publish DMARC at `p=none` only as a temporary monitoring phase. Set a reporting address that someone or some service actually reads. Use a DMARC reporting tool, commercial or open source, to parse aggregate reports. The raw XML should not be the control interface. Then fix alignment. DKIM is usually the more durable path for third-party services and forwarded mail. SPF still matters, but it has forwarding and lookup-limit traps. For every legitimate sender, document the owner, the platform, the domain or subdomain it uses, the authentication method, and the rollback contact. If nobody owns a sender, that sender is already a risk. Move in stages: `p=none`, then `p=quarantine`, then `p=reject`. Use percentage rollout if your receivers and policy design support it. Watch helpdesk tickets, bounce logs, deliverability dashboards and DMARC reports during each step. Do not treat a quiet week as proof if nobody is reading failures. Use subdomains deliberately. A domain used for invoices should not have to carry the same risk as a throwaway campaign domain. The `sp=` tag can define a subdomain policy, but only if the organization understands which subdomains send mail. Better still, move risky senders to dedicated subdomains and enforce the organizational domain more strictly. Ask your MSP or mail provider blunt questions. Who reads DMARC reports? How often? What is the list of authorized senders? Which domains never send mail? What will you do if enforcement blocks a real sender? What evidence shows that `p=none` is still a temporary phase rather than a permanent state? If the answer is "we published the record," the work is not done. For users and executives, the takeaway should stay modest. DMARC will not make phishing disappear. A fake domain can still look convincing. A compromised supplier can still send bad mail with valid authentication. A large platform can still host abusive senders. But DMARC enforcement removes the cheap trick where an attacker sends mail that appears to come directly from your domain and fails authentication. That is why `p=none` is a bad stopping point. It is useful while learning who sends mail for you. Left alone, it becomes security theater: a control that reports violations but does not ask receivers to act on them. The right posture is neither panic nor neglect. Treat DMARC enforcement as routine hygiene with a real migration plan. Inventory the senders, fix the broken ones, protect domains that never send, move carefully to quarantine and reject, and keep reading the reports after the switch. The last mile is tedious, but it is where the protection begins.