Start with authority, version and jurisdiction
An EU email-security discussion can involve a directive, a directly applicable regulation, national implementation, supervisory guidance, contracts and technical standards. Those sources do not have identical scope or legal effect. Before recommending an authentication change as a compliance measure, identify the exact authority and the organization or processing activity to which it may apply.
This article retains the official EUR-Lex original published texts of Directive (EU) 2022/2555, commonly called NIS2, and Regulation (EU) 2016/679, the GDPR. Their original-publication URLs are not presented as a completed verification of every subsequent amendment, implementing act, national transposition or regulator interpretation. A current jurisdiction-specific review remains necessary before making an organizational compliance claim.
The purpose here is technical and evidentiary: show how to avoid turning broad security duties into unsupported assertions about one protocol. This is not legal advice, a determination of an entity’s regulatory status or a certification that any domain is compliant.
Determine NIS2 applicability before selecting evidence
Article 2 of the retained NIS2 text defines scope by entity types, size and additional conditions, including categories that can fall within scope regardless of size. Annexes identify relevant sectors and entity types. A company’s website location or possession of an EU domain suffix is not a substitute for this analysis. The entity, activities, service types and relevant jurisdiction must be identified.
Article 41 addresses Member State transposition and states dates for adopting and applying measures. Those dates do not establish that every Member State’s actual implementation is identical or that a particular organization’s obligations can be concluded from the directive alone. Obtain the applicable national text and qualified review rather than extrapolating from a general EU summary.
The applicability worksheet should preserve the entity class, country, activities, source version, national implementation reference and unresolved questions. Do not mark an organization exempt merely because it describes itself as small, or covered merely because a supplier uses the phrase critical infrastructure. NIS2, Articles 2 and 41 and Annexes I–II
Read risk-management duties without inventing a protocol command
Article 21 of the retained directive requires appropriate and proportionate technical, operational and organizational measures for the covered entities, with a risk-based and all-hazards approach. Article 20 addresses management approval and oversight of the measures. These provisions support an accountable security program, not a shortcut in which publishing one DNS policy closes every obligation.
Email authentication can be proposed as part of a documented response to relevant impersonation risks. The justification should explain the threat, the domain and sender scope, the control’s limitations, complementary safeguards and the evidence of operation. Do not rewrite the cited general provisions as a universal instruction that every EU organization must publish a particular DMARC policy value.
A narrower sector-specific or national rule could require additional measures. That possibility is a reason to check the actual applicable source, not permission to invent it. Keep the legal requirement text and the technical control mapping in separate fields so a reviewer can see the reasoning. NIS2, Articles 20 and 21
Assess privacy in the reporting workflow
GDPR applicability concerns processing of personal data under its material and territorial scope, not simply whether a company publishes DMARC. Where relevant personal data is processed in authentication logs, support samples or reports, the review must address the processing purpose, roles and applicable requirements. The retained Article 3 text provides territorial-scope conditions; the actual organizational determination still requires qualified review.
Article 5 includes purpose limitation, data minimization and storage limitation. Article 32 requires appropriate technical and organizational security measures in light of the processing and risks. These principles support asking which fields are necessary, who can access them, how long they are retained and how their security is evaluated. They do not create one universal report-retention period or establish that every aggregate field is personal data in every context.
Do not assume that security monitoring automatically permits unlimited collection or sharing. A vendor evidence package should have a defined recipient, purpose and minimized scope, with the relevant lawful-processing and contractual questions assessed separately. No actual report or personal information was collected or transferred for this manuscript. GDPR, Articles 3, 5 and 32
Keep protocol evidence within its protective scope
DMARC evaluates aligned authentication in relation to the message’s From domain. It can support a particular anti-spoofing control, but it does not prove that an authenticated message’s business request is safe, that all lookalike attacks are prevented or that every organizational security duty has been met. A technical assessment should describe those limits explicitly.
Reporting also needs its own privacy and security review. Aggregate and failure reporting differ, and neither should be treated as a complete view of all messages or as inherently trustworthy input. The standards evidence helps explain the mechanism; it cannot substitute for an entity-specific legal applicability analysis or a full control-effectiveness assessment. RFC 9989, section 2.4 and 4.4; RFC 9990, section 7 and 8
Control-to-evidence worksheet and fictional example
Create a worksheet with separate columns for authority and version, applicability rationale, exact requirement, risk addressed, proposed technical control, affected domains and routes, evidence, owner, review date and residual limitations. Include national implementation and privacy-review references where relevant. A row should remain unresolved when the applicable legal source or actual operational evidence is missing.
Imagine a fictional organization considering DMARC enforcement while assessing its NIS2 position and report-processing practices. Its security team can prepare a sender inventory and a proposed authentication evidence plan. Its legal reviewer must separately determine entity scope and applicable national obligations. Its privacy owner must review report fields, recipients and retention. No one can close the complete compliance assessment merely because a public DNS lookup shows p=reject.
If the fictional organization later obtains aligned-message evidence, that can support the technical control row within its defined scope. It still does not settle management governance, incident handling, supply-chain requirements or privacy questions. The example is a proposed division of evidence responsibilities, not an executed assessment or an allegation about a real organization.
Unresolved review and release status
The catalogue requires authoritative current text and appropriate jurisdiction-specific compliance review before making a compliance claim. Retained original EU publications support the narrow explanations above, but current amendments, implementing measures, national law and organizational applicability have not been fully adjudicated here. The original-evidence requirement therefore remains open.
All six release gates remain open. No DNS changes, regulatory submission, legal commitment, tenant access or compliance certification occurred. Before publishing a completed organizational assessment, retain the current applicable authorities, qualified review and actual control evidence. State the scope and unresolved questions plainly instead of presenting email authentication as a complete legal-compliance solution.