For the better part of a decade, the case for DMARC rested on a single pillar: it was the right thing to do. Security teams pointed to phishing statistics. Email deliverability consultants warned about reputation damage. Vendors built dashboards to make the path from p=none to p=reject feel manageable.
None of that moved the needle fast enough.
What is moving the needle in 2026 is something organizations respond to far more reliably than best-practice guidance: the threat of fines. DMARC has crossed from recommendation into regulation, and the frameworks now requiring it carry real financial consequences.
If your organization handles payment card data, operates critical infrastructure in the European Union, or falls under the scope of the Digital Operational Resilience Act, you are no longer being asked to implement DMARC. You are being required to.
PCI DSS v4.0: The Clearest Mandate Yet
The Payment Card Industry Data Security Standard version 4.0 became the only version in force on March 31, 2024. Requirement 5.4.1 of PCI DSS v4.0 introduces an explicit obligation for organizations to use anti-phishing technical controls for all email traffic. The PCI Security Standards Council’s supplemental guidance makes the expectation concrete: DMARC, along with SPF and DKIM, is the technical mechanism for satisfying that requirement.
Requirement 10.4.1.1 goes further. It requires that email sent from an organization’s domain be authenticated in a way that is verifiable by receiving systems. A DMARC record at p=quarantine or p=reject, combined with aligned SPF and DKIM authentication, is the mechanism that satisfies this clause.
The enforcement math is straightforward. Non-compliance with PCI DSS can trigger fines from card brands and acquiring banks ranging from $5,000 to $100,000 per month per violation. An acquiring bank that determines a Level 1 merchant is operating without the required anti-phishing controls faces pressure from card brands to escalate those penalties. The fines are not theoretical. They are contractual provisions that acquiring banks have started enforcing as PCI DSS v4.0 assessment cycles mature.
For any organization that processes, stores, or transmits cardholder data, DMARC at enforcement level is not optional under PCI DSS v4.0. Meeting the p=none floor that satisfies Gmail and Outlook’s bulk sender requirements does not satisfy PCI DSS. Enforcement-level policy is the requirement.
NIS2: The European Union Sets the Standard for Critical Infrastructure
The Network and Information Security Directive 2, which EU member states were required to transpose into national law by October 2024, establishes cybersecurity requirements for operators of essential services and important entities across sixteen sectors: energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, postal services, waste management, chemicals, food, and manufacturing.
NIS2 does not name DMARC in its text. What it does is require that covered entities implement “appropriate and proportionate technical and organisational measures” to manage cybersecurity risk, including measures that address “the security of network and information systems” and “the handling and disclosure of vulnerabilities.”
National regulators implementing NIS2 have been explicit about what those measures include. The German Federal Office for Information Security (BSI), whose Technical Directive BSI TR-03108 is the most detailed national implementation guidance in Europe, specifies DMARC at enforcement level as a required control for operators of email infrastructure. The Dutch National Cyber Security Centre and France’s ANSSI have issued similar guidance. European Central Bank supervisory expectations for financial institutions under NIS2 scope identify email authentication as a baseline control.
The NIS2 penalty framework matches the ambition of the directive. Essential entities face fines of up to 10 million euros or 2% of global annual turnover, whichever is higher. Important entities face fines of up to 7 million euros or 1.4% of global annual turnover. These are GDPR-scale consequences for cybersecurity non-compliance.
DORA: Financial Entities Under the Microscope
The Digital Operational Resilience Act, which became directly applicable across EU member states on January 17, 2025, applies to financial entities: banks, investment firms, insurance undertakings, payment institutions, electronic money institutions, crypto-asset service providers, and a range of other financial sector participants.
DORA’s focus is ICT risk management. Article 9 of DORA requires financial entities to implement policies and procedures to protect their ICT systems and data, including controls that address information security at the communication layer. Supplementary regulatory technical standards published by the European Supervisory Authorities specifically identify email authentication protocols as components of required ICT security frameworks.
The practical implication for financial entities under DORA scope: a DMARC policy at p=none is a documented gap in ICT risk management that supervisory authorities can cite as a DORA violation during inspection. Financial institutions that have invested heavily in DORA compliance programs are increasingly discovering that email authentication configuration, specifically DMARC policy level, is a line item in their compliance checklists.
DORA enforcement authority rests with national competent authorities, which in most EU member states are the central bank or financial supervisory authority. Penalties can reach 2% of total annual worldwide turnover for financial entities or 1% for critical ICT third-party service providers.
Why Countries with National DMARC Mandates See Dramatically Lower Phishing Rates
The regulatory frameworks above are the most consequential, but they are not the only ones. Several countries have moved to national-level DMARC mandates that apply to government domains and, in some cases, to broader sets of regulated entities.
The United Kingdom’s National Cyber Security Centre mandated DMARC at p=reject for all central government domains in 2021. Denmark followed with a comparable mandate for government entities. The results are measurable: countries with formal government DMARC mandates have seen phishing success rates targeting government domains fall from 69% to 14%, compared to a 97% vulnerability rate in countries without mandates.
That data point is significant for private-sector compliance officers. The efficacy of DMARC at enforcement level is not theoretical. Countries and sectors that have mandated it have demonstrated the reduction in attack surface it provides. Regulators writing cybersecurity requirements in 2026 are not speculating about whether DMARC works. They are responding to evidence that it does.
The Compliance Gap That Is Now a Liability
Here is the problem that compliance and security teams face in 2026: the industry pushed p=none as the minimum viable DMARC posture for two years, primarily to help organizations satisfy Google and Microsoft’s bulk sender requirements without disrupting their email operations. Tens of thousands of domains published p=none records and stopped there.
p=none does not satisfy PCI DSS v4.0. It does not satisfy BSI TR-03108. It does not satisfy DORA-aligned ICT security frameworks. It does not satisfy the spirit of NIS2. And it does not stop a single phishing email that spoofs your domain.
EasyDMARC’s 2026 report found that of the 937,931 domains with DMARC records, only 411,935 are at quarantine or reject. Fewer than one in four domains that bothered to publish a DMARC record have actually moved to the policy level that regulators now require. For organizations in scope of PCI DSS, NIS2, or DORA, every day that p=none stays in DNS is a day of documented non-compliance.
What Enforcement-Level DMARC Actually Requires
Moving from p=none to p=reject is not a DNS record change. It is an email infrastructure project. The reason organizations stall at p=none is not ignorance of the requirement. It is the risk of breaking legitimate mail streams when no one has catalogued every system that sends mail on the organization’s behalf.
The path is methodical:
Aggregate report collection and analysis. DMARC aggregate reports (RUA) contain a detailed accounting of every server that sent mail claiming to be from your domain during the reporting interval, along with SPF and DKIM pass/fail results for each source. You cannot safely enforce until you have analyzed several weeks of these reports.
Source discovery and authentication. The reports will surface sending sources you did not know existed: a marketing automation platform from a past vendor, a SaaS integration that sends transactional receipts under your domain, a regional office using a local mail relay. Every legitimate source must be authenticated before enforcement.
Subdomain policy consideration. A DMARC policy on your apex domain does not automatically cover subdomains unless you specify sp=reject. Organizations often have complex subdomain structures. Each one needs to be evaluated.
Phased enforcement. The transition from p=none to p=quarantine to p=reject should be staged, with monitoring at each step to catch any legitimate source that was missed in the discovery phase.
Done correctly, this process typically takes four to twelve weeks for a mid-size organization. Done incorrectly, it disrupts legitimate mail flows. The compliance timeline pressure that PCI DSS v4.0 and DORA create has led some organizations to rush enforcement and create the self-inflicted deliverability problems they were trying to avoid.
Documentation as a Compliance Asset
One underappreciated aspect of DMARC compliance under regulatory frameworks is documentation. PCI DSS assessors and NIS2 supervisory auditors do not simply check whether a DMARC record exists at the right policy level. They assess whether the organization has a repeatable, documented process for maintaining that compliance.
That means:
- Records of the monitoring phase and the aggregate report analysis that preceded enforcement
- Documentation of all authenticated sending sources and the process for adding new ones
- Evidence of periodic review of DMARC reports to catch authentication failures from new or changed sources
- A policy governing how DMARC configuration changes are approved and implemented
Organizations that achieve p=reject but cannot demonstrate the process that got them there and the controls that maintain it are only partially compliant with the frameworks that now require DMARC. The record in DNS is the output. The process is the requirement.
The Intersection with Global Email Marketing Law
Regulatory pressure on email authentication is arriving alongside separate and parallel pressure on email marketing practices. Australia’s Spam Act enforcement produced a A$702,900 fine against Lululemon in March 2026. Washington State’s CEMA has triggered roughly 115 class action lawsuits targeting misleading subject lines. The EU’s ePrivacy Regulation enforcement is accelerating.
These are separate legal frameworks from PCI DSS, NIS2, and DORA, but they reinforce the same organizational reality: email infrastructure is under regulatory scrutiny at multiple levels simultaneously. The compliance burden is not additive across independent silos. It is compounding within a single email program that must satisfy authentication requirements, content requirements, consent requirements, and operational resilience requirements all at once.
Organizations that treat these as separate workstreams will find themselves managing separate compliance gaps. Organizations that approach email as an integrated compliance surface – where DMARC, list hygiene, unsubscribe mechanisms, and operational documentation are all part of the same program – are the ones positioned to demonstrate compliance across the full range of applicable frameworks.
Managing DMARC compliance across PCI DSS, NIS2, and DORA scope is not a one-time project. Excello Mail gives your team continuous monitoring, aggregate report analysis, and enforcement guidance that documents itself as you go. Start your free trial at excello.email →