DMARC Evidence for ISO 27001, NIS2, DORA and GDPR

It starts with a finance director forwarding an email to the CISO at 07:42.

“Did we send this?”

The message looks perfect. Same logo, same footer, same tone as the billing team. It claims that bank details have changed. The sender display name is correct. The domain is not a lookalike typo. The attacker is spoofing the real domain.

By 08:15, the security team confirms the uncomfortable truth: SPF exists but is too broad, DKIM is enabled only for the main email platform, several marketing tools send unsigned mail, DMARC is still in monitoring mode, and nobody can find the last review of the domain’s MTA-STS policy. The organization has “email security” in a slide deck, but the evidence is scattered across DNS screenshots, vendor portals, old Jira tickets and a spreadsheet owned by someone who left last year.

By 10:30, legal asks whether customer personal data may be involved. Compliance asks whether this is relevant to NIS2 reporting. A financial-services customer asks whether the company can demonstrate DORA-aligned ICT risk controls. Internal audit asks how this maps to ISO/IEC 27001:2022. The board asks a simpler question: “Why could someone impersonate us?”

That question is why email authentication in 2026 is no longer a niche DNS topic. DMARC, SPF, DKIM, MTA-STS and TLS-RPT are evidence-producing controls. They reduce phishing and domain spoofing risk, but they also create the artefacts auditors expect: policy decisions, ownership, technical baselines, supplier accountability, logs, monitoring records, exceptions, change approvals and incident response triggers.

The compliance problem is not, “Do we have DMARC?” It is, “Can we prove that email authentication is governed, monitored, reviewed and linked to risk?”

The evidence gap auditors keep finding

A second scenario is just as common. The external audit is underway at a fast-growing fintech company. The auditor moves from business continuity to incident management and asks the CISO about business email compromise.

The CISO explains that the company has anti-phishing filters and quarterly security awareness training.

The auditor nods, then asks for something more specific: “Show me the governance around DMARC, SPF and DKIM. I need to see ownership, change records, risk assessment, monitoring evidence and how this ties into NIS2 cyber hygiene and the DORA ICT risk framework.”

The room goes quiet.

The technical team implemented DMARC months ago, but the ISMS has no policy reference, no central evidence pack, no link to the risk register and no approved enforcement roadmap. The control may exist technically, but it is invisible to governance.

That is the evidence gap.

A mature email authentication program answers six audit questions:

1. Which domains and subdomains are in scope?
2. Who owns each domain, DNS zone, mail flow and sending service?
3. Which systems are allowed to send on behalf of the organization?
4. Which authentication mechanisms are enforced, monitored and reviewed?
5. How are exceptions approved, risk accepted and retired?
6. What evidence proves the control operated over time?

ISO/IEC 27001:2022 makes this a management system issue. Clauses 4.1 to 4.4 require the organization to understand context, interested-party requirements, scope boundaries, interfaces and dependencies. Email authentication touches all of them. Your domain registrar may be a supplier. DNS may be hosted in cloud infrastructure. Your CRM, payroll platform, invoice tool, marketing automation provider and customer support system may all send email using your brand.

Clauses 5.1 to 5.3 make this a leadership issue. Top management must assign responsibilities and integrate information security into business processes. A DMARC decision from p=none to p=quarantine or p=reject can affect customer communications, finance notifications, HR onboarding, sales campaigns and outsourced providers.

Clauses 6.1.1 to 6.1.3 require risk assessment, risk treatment, control selection and a Statement of Applicability. Domain spoofing should be treated as a risk scenario, with SPF, DKIM, DMARC, MTA-STS and TLS-RPT selected as part of the treatment where appropriate. Clause 8.1 then requires operational planning and control, including control over externally provided processes, products and services relevant to the ISMS.

What each email authentication control proves

SPF, DKIM, DMARC, MTA-STS and TLS-RPT work together, but they prove different things.

SPF and DKIM are identity and integrity signals. DMARC is the policy layer that turns those signals into receiver action. MTA-STS and TLS-RPT support secure email transport by helping prevent downgrade and misconfiguration risks.

For auditors, the deeper value is repeatable evidence. DMARC aggregate reports show who is sending as your domain. TLS reports show whether encrypted delivery is failing. Change tickets show whether governance exists. Vendor records show whether supply-chain dependencies are known.

Put domains into the asset register first

Email authentication cannot be governed if domains are not treated as assets.

The SME Asset Management Policy-sme Asset Management Policy - SME explicitly brings domains and email-related identities into scope:

“Digital credentials and services: domain names, digital certificates, API keys, email accounts, cloud logins”

From section “Scope”, policy clause 2.2.4.

For larger organizations, the enterprise Asset Management Policy Asset Management Policy applies the same logic:

“Logical assets: domain names, licenses, user accounts, configuration baselines”

From section “Scope”, policy clause 2.2.5.

If domains are assets, they can have owners, criticality ratings, review cycles, supplier dependencies, change controls and evidence locations. If they are just DNS entries, they are usually unmanaged until something breaks.

An audit-ready domain and email sending register should include:

This register supports ISO/IEC 27001:2022 Annex A control A.5.9 Inventory of information and other associated assets, A.8.9 Configuration management, A.5.19 Information security in supplier relationships and A.5.23 Information security for use of cloud services. It also supports NIST CSF 2.0 inventory outcomes for assets, services, suppliers and criticality.

Use change management for DNS and mail-flow decisions

Email authentication breaks when change management is weak. A sales team adds an outreach platform. HR adopts a candidate tracking tool. Finance changes invoice software. Marketing moves to a new email service provider. Each business decision creates a new sender.

The enterprise Change Management Policy Change Management Policy makes the evidence requirement explicit:

“All change requests, reviews, approvals, and supporting evidence must be recorded in the centralized Change Management System.”

From section “Policy Implementation Requirements”, policy clause 6.1.1.

A strong email authentication change ticket should include:

• Business justification for the new sender.
• Domain or subdomain affected.
• SPF include or sending IP impact.
• DKIM selector and key ownership.
• DMARC alignment test result.
• MTA-STS or MX impact, if any.
• Data classification of messages sent.
• Supplier security review reference.
• Rollback plan.
• Approval by domain owner and security.
• Post-implementation test evidence.
• Review date or expiry for temporary settings.

This is the difference between “a DNS admin changed a record” and “the ISMS controlled a risk-relevant change.”

A practical 30-day plan for DMARC, SPF, DKIM and MTA-STS evidence

A CISO does not need a six-month transformation project to improve evidence maturity. A focused 30-day sprint can produce a defensible baseline.

Week 1: Discover domains, senders and ownership

Export all domains from the registrar and DNS provider. Pull mail-flow data from the email gateway, CRM, helpdesk, marketing platform, billing system and cloud notification services. Build the domain and sending register.

Also include parked domains and defensive registrations. Parked domains are often ignored, but they can still be abused if DMARC is absent or weak.

Week 2: Fix SPF and DKIM alignment

Review SPF for over-permissive mechanisms, stale includes, duplicate providers and lookup-limit risks. For DKIM, identify every sender that does not sign mail or signs with a domain that will not align with DMARC.

Do not approve a SaaS sender just because mail is working. Approve it because:

• The supplier is listed in the sending register.
• SPF and DKIM configuration are documented.
• DKIM selectors are inventoried.
• Key ownership and review expectations are clear.
• Supplier security documentation supports secure mail handling.
• The business owner accepts any temporary exception.

This is where NIS2 and DORA become practical. NIS2 Article 21 requires appropriate and proportionate technical, operational and organizational measures, including risk analysis, incident handling, business continuity, supply-chain security, secure acquisition and maintenance, effectiveness assessment, cyber hygiene, cryptography, access control and secure communications. DORA Article 28 requires financial entities to manage ICT third-party risk as part of the ICT risk management framework, including due diligence, contractual expectations, monitoring and exit planning.

If a marketing provider sends unauthenticated email using your domain, that is not only a marketing issue. It is supplier risk, brand impersonation risk and potentially customer harm.

Week 3: Move DMARC toward enforcement

Monitoring mode is useful, but permanent p=none without an approved roadmap is weak evidence.

A defensible DMARC enforcement plan should include:

• Baseline aggregate report review.
• Identification of legitimate and illegitimate sources.
• Remediation of legitimate failing sources.
• Business validation of critical mail streams.
• Gradual policy increase to pct=25, pct=50, pct=100.
• Transition from p=none to p=quarantine.
• Transition to p=reject when risk and business readiness allow.
• Separate handling for subdomains with sp=.
• Exception register with expiry dates.
• Management approval for residual risk.

This supports ISO/IEC 27001:2022 Clause 6.1.3 risk treatment and Clause 8.1 operational planning and control. It also gives internal audit a clear trail: decision, implementation, monitoring, exception, approval and review.

Week 4: Validate MTA-STS, TLS-RPT and monitoring

MTA-STS is often missed because it does not stop outbound brand spoofing in the same way DMARC does. But it is highly relevant to secure communications and protection of information in transit. It tells compatible sending servers that mail to your domain should be delivered over TLS and validates the MX identity.

The enterprise Cryptographic Controls Policy Cryptographic Controls Policy sets a clear transport security baseline:

“Transport Security: TLS 1.2 or higher (preferably TLS 1.3)”

From section “Policy Implementation Requirements”, policy clause 6.1.1.5.

For SMEs, the Cryptographic Controls Policy-sme Cryptographic Controls Policy - SME explicitly includes email transmission:

“Data transmitted via email, corporate VPNs, and web portals”

From section “Policy Implementation Requirements”, policy clause 6.1.1.4.

Testing should include MX TLS validation, MTA-STS policy file availability, HTTPS certificate health, TLS-RPT report review and triage records for failures.

Map email authentication to ISO/IEC 27001:2022 Annex A

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls helps connect technical evidence to audit expectations across frameworks. It is not a separate control set. It is a mapping and audit guide for ISO/IEC 27001:2022 controls and related standards.

For ISO/IEC 27001:2022 Annex A control A.5.14 Information transfer, Zenith Controls explains the relationship to cryptography:

“Secure information transfer relies on cryptographic controls as detailed in 8.24.”

That is the relationship between business email, DKIM, MTA-STS and TLS. Email is an information transfer channel. DKIM supports message authenticity and integrity. MTA-STS and TLS support transport protection.

For Annex A control A.8.24 Use of cryptography, Zenith Controls ties cryptography to information transfer, privacy, protection of PII, classification and vulnerability management. For Annex A controls A.8.15 Logging and A.8.16 Monitoring activities, the guide connects logs and monitoring to event management, evidence collection, review, analysis and auditability.

The SME Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME states:

“Logging must be enabled and configured where available”

From section “Governance Requirements”, policy clause 5.5.1.1.

The enterprise Logging and Monitoring Policy Logging and Monitoring Policy includes:

“External communications and firewall rule triggers”

From section “Policy Implementation Requirements”, policy clause 6.1.1.6.

For email authentication, external communications should include mail gateway events, DMARC aggregate report processing, DKIM failure trends, suspicious source infrastructure, TLS-RPT failures and spoofing attempts that trigger incident triage.

The Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint places this into practical control validation. In the Controls in Action phase, Step 20, it tells teams to validate network service security:

“List out all internal and external network services (DNS, VPN, SMTP, DHCP, API gateways, etc.).

✓ For each, confirm that they use secure protocols (e.g., DNSSEC, TLS 1.2+, SSH instead of Telnet).
✓ Review how access to each service is controlled (e.g., IP whitelists, authentication, certificates).
✓ If managed by third parties (e.g., DNS, SD-WAN, hosted VPN), review the security clauses in the SLA or vendor contract. Update your Service Registry and note where security responsibilities lie, internal or external.”

Applied to email, this becomes a workplan for DNS, SMTP, TLS, hosted mail gateways, vendor senders and responsibility boundaries.

Cross-compliance mapping: one evidence pack, many obligations

The same evidence pack can support ISO/IEC 27001:2022, NIS2, DORA, GDPR and NIST CSF 2.0 if it is structured properly.

NIS2 is especially relevant for essential and important entities, and for certain digital infrastructure and digital provider categories. Article 20 makes cybersecurity governance a management-body responsibility, while Article 21 establishes the risk-management baseline. Email authentication evidence helps show that secure communications, supplier relationships, incident handling, effectiveness assessment and cyber hygiene are operational, not theoretical.

For financial entities, DORA has applied from 17 January 2025. Articles 5 and 6 require management-body accountability and a documented ICT risk management framework. Article 17 requires processes to detect, manage, record, classify, escalate and remediate ICT-related incidents. Article 28 makes ICT third-party risk management a formal responsibility. Email providers, marketing platforms, payment notification systems and customer communication tools can all become part of that ICT dependency chain.

For GDPR, the key question is whether email is used to process personal data. Article 5 includes integrity, confidentiality and accountability. Article 32 requires appropriate technical and organizational measures. If invoices, HR messages, account notices, support tickets or onboarding emails contain personal data, email authentication and transport security become part of the security-of-processing evidence.

Incident response: when reports become early warning

DMARC aggregate reports are not only compliance evidence. They are early warning data. A spike in failed authentication from unfamiliar infrastructure may indicate active spoofing, shadow IT, supplier misconfiguration or a compromised sender.

Under NIS2 Article 23, essential and important entities must notify significant incidents without undue delay, using staged reporting that includes early warning, incident notification and final reporting. Not every spoofing attempt is reportable, but the organization must be able to assess severity, operational disruption, financial loss, cross-border impact and harm to recipients.

Under DORA Article 17, financial entities must define and implement an ICT-related incident management process, record incidents and significant cyber threats, identify root causes, use early warning indicators, classify by severity and service criticality, assign roles, define communications and escalate major incidents. DORA Article 19 then addresses reporting of major ICT-related incidents.

For GDPR, the question is whether the event caused accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. A spoofed email that tricks customers into submitting personal data to an attacker may trigger a personal data breach assessment, even if internal systems were not compromised.

The enterprise Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy explains why disciplined evidence matters:

“To generate defensible evidence and an audit trail in support of regulatory inquiries, legal proceedings, or customer assurance requests.”

From section “Objectives”, policy clause 3.4.

The SME Audit and Compliance Monitoring Policy-sme Audit and Compliance Monitoring Policy - SME adds an evidence-quality requirement:

“Metadata (e.g., who collected it, when, and from which system) must be documented.”

From section “Policy Implementation Requirements”, policy clause 6.2.3.

A DMARC investigation file should therefore document report source, collection time, analyst, affected domains, suspected sender IPs, authentication results, business impact assessment, decisions made and closure approval.

What auditors will ask for

Different auditors use different language, but the evidence overlaps.

Expect practical questions:

• Show the DMARC reports for the last quarter.
• Show how they were reviewed.
• Show the exception for this failing sender.
• Show who approved this SPF change.
• Show whether DKIM selectors are inventoried and reviewed.
• Show how MTA-STS is tested after mail gateway changes.
• Show how spoofing events enter incident triage.
• Show how supplier senders are removed at contract termination.

A concise 2026 internal audit checklist

Use this checklist as a starting point for internal audit, control testing or an Email Authentication Evidence Review.

• All domains and subdomains are listed in the asset register.
• Parked and defensive domains have DMARC coverage.
• Every authorized sender has a business owner and technical owner.
• SPF records are reviewed for stale includes and excessive scope.
• DKIM is enabled for legitimate senders where supported.
• DKIM selectors are inventoried and reviewed.
• DMARC is deployed for root domains and relevant subdomains.
• DMARC has an enforcement roadmap, not indefinite monitoring.
• DMARC aggregate reports are reviewed on a defined cadence.
• MTA-STS is configured for inbound mail domains where applicable.
• TLS-RPT reports are collected and triaged.
• Email authentication changes follow change management.
• Supplier onboarding includes email sending requirements.
• Supplier offboarding removes SPF includes, DKIM selectors and sending permissions.
• Exceptions have risk owners, expiry dates and compensating controls.
• Spoofing spikes and authentication failures feed incident response.
• Evidence includes metadata, source, date, collector and system.
• Management receives periodic metrics and risk updates.

The Zenith Blueprint, Risk Management phase, Step 14, recommends creating regulatory mapping tables for applicable obligations:

“For each regulation, if applicable, you may create a simple mapping table (could be an appendix in a report) that lists the regulation’s key security requirements and the corresponding controls/policies in your ISMS. This isn’t mandatory in ISO 27001, but it’s a useful internal exercise to ensure nothing fell through the cracks. It also impresses auditors/assessors that you’re not managing security in a vacuum but aware of legal context.”

For email authentication, that table becomes the bridge between technical DNS reality and board-level assurance.

Turn email authentication into audit-ready evidence

Your customers may never ask whether your SPF record has perfect syntax. They will ask whether you can protect your brand, reduce phishing risk, secure communications, manage suppliers and prove that your controls work.

Clarysec helps organizations turn email authentication from fragile technical settings into an audit-ready control system. The practical next step is a focused Email Authentication Evidence Review:

1. Build the domain and sending register.
2. Map SPF, DKIM, DMARC, MTA-STS and TLS-RPT status.
3. Identify suppliers, shadow senders and exceptions.
4. Create a DMARC enforcement roadmap.
5. Validate change management, logging and incident response evidence.
6. Link evidence to ISO/IEC 27001:2022, NIS2, DORA, GDPR and NIST CSF 2.0.
7. Prepare an auditor-ready evidence pack using Zenith Blueprint, Zenith Controls and the relevant Clarysec policies.

If your organization is preparing for ISO/IEC 27001:2022 certification, NIS2 readiness, DORA assurance, GDPR accountability reviews or customer security questionnaires, start with the controls attackers abuse most visibly: your domains, your senders and your email trust chain.

Download the Zenith Blueprint, use Zenith Controls for cross-compliance mapping, and run a 30-day Email Authentication Evidence Review before the next spoofing incident or audit request forces the conversation.