Your ISMS is certified. Your Statement of Applicability covers the controls. Your auditor arrives and runs a DNS lookup on your domain.

dig _dmarc.yourdomain.com TXT +short

The output shows p=none. The auditor makes a note.

This is not a hypothetical. DMARC policy enforcement has become a standard ISMS audit check since ISO 27001:2022 made Annex A.5.14 — Information Transfer an explicit Annex A control for the first time. If your organization was certified against ISO 27001:2013 and has not reviewed email security controls since the transition to the 2022 standard, there is a material gap in your Statement of Applicability — whether or not the auditor has found it yet.

This guide maps every email and DNS security control to the specific Annex A clauses they satisfy, explains what auditors check and what they accept as evidence, and identifies the three findings that appear most frequently in ISMS email security reviews.

Why 2022 Changed the Picture

ISO 27001:2013 did not include an explicit Annex A control for information transfer security in email. Organizations could and did satisfy information security requirements through general controls on network security and communications without formally addressing SPF, DKIM, DMARC, or MTA-STS in their SoA.

ISO 27001:2022 introduced Annex A.5.14 — Information Transfer as a new, named control. It explicitly requires "rules, procedures and agreements" for information transfer across all channels — including email. MTA-STS and DMARC serve as automated technical enforcement of these rules. The 2022 revision also reorganized and renumbered controls; several email-adjacent controls moved between clauses.

The transition deadline for existing certifications was October 31, 2025. Certifications that have not transitioned to ISO 27001:2022 are no longer valid. If your ISMS was certified under the 2013 standard, the audit against the 2022 standard requires you to explicitly add email security controls to your SoA — they cannot be treated as implicitly covered by older, broader controls.

The Annex A Controls That Cover Email and DNS Security

Four Annex A controls in ISO 27001:2022 map directly to email and DNS security. Each one has a specific scope, a specific technical implementation, and a specific evidence requirement.

Annex A.5.14 — Information Transfer

Scope: Rules, procedures, and agreements ensuring that information transferred via all channels — including email — is protected appropriately.

What it requires for email: Documented policies for email security, backed by technical enforcement controls that automatically apply those policies. The 2022 guidance explicitly notes that automated enforcement (rather than user-dependent procedures) is preferred.

Technical controls that satisfy A.5.14:

DMARC at p=quarantine or p=reject is the primary control. It enforces your email authentication policy automatically — emails that fail SPF and DKIM authentication are either quarantined or rejected, depending on your policy level. The key word is enforces. p=none collects data but enforces nothing. It does not satisfy A.5.14 as an active protection control.

MTA-STS in enforce mode is the complementary control for inbound email transport security. It instructs sending mail servers that they must use TLS when delivering email to your domain, and rejects delivery attempts that cannot establish a secure connection. Without it, downgrade attacks on TLS are possible and undetected.

How to document this in your SoA:

Control: Annex A.5.14 — Information Transfer
Applicable: Yes
Justification: Email is a primary information transfer channel for the organization.
Implementation:
  - DMARC: p=quarantine (or p=reject) enforced at _dmarc.yourdomain.com
  - MTA-STS: enforce mode policy at mta-sts.yourdomain.com
  - SPF: all authorized senders listed at yourdomain.com TXT
  - DKIM: 2048-bit keys configured for all sending services
Control owner: [IT Manager / CTO / named role]
Review schedule: Quarterly DNS audit + annual DKIM key rotation review
Evidence reference: [Link to monitoring dashboard or export]

Annex A.8.16 — Monitoring Activities

Scope: Networks, systems, and applications must be monitored to detect anomalous behavior and potential security events.

What it requires for email: Active monitoring of email authentication and transport encryption — not just having the controls configured, but actively receiving and reviewing the data those controls generate.

The distinction auditors enforce: Having a rua= address in your DMARC record is configuration. Reading the reports that arrive at that address is monitoring. Having TLS-RPT configured is configuration. Reviewing TLS negotiation failure reports is monitoring.

Annex A.8.16 requires monitoring to be active. An organization with DMARC RUA configured but six months of unread XML reports in an inbox has a configuration, not a monitoring program. Auditors distinguish between the two.

Technical controls that satisfy A.8.16:

DMARC RUA reporting — aggregate reports sent daily to your rua= address, showing which services sent email as your domain, which passed authentication, and which failed. These reports must be read and actioned. The most practical approach for most organizations is a DMARC report parser (Postmark DMARC Digests, dmarcian, DMARC Analyzer) that converts the raw XML into readable summaries.

TLS-RPT — daily reports from other mail servers about TLS connection failures when delivering to your domain. Configure via a TXT record at _smtp._tls.yourdomain.com with a rua= address.

Verification:

# DMARC reporting active
dig _dmarc.yourdomain.com TXT +short
# Look for rua=mailto: in the output

# TLS-RPT active
dig _smtp._tls.yourdomain.com TXT +short
# Look for rua=mailto: in the output

What to document: Monthly or quarterly summaries of DMARC report review, showing compliance rates and any anomalies investigated. A log of actions taken when unauthorized senders appeared in reports.

Annex A.8.20 — Networks Security

Scope: Networks and network devices must be managed and controlled to protect information in systems.

DNS security controls that satisfy A.8.20:

DNSSEC — cryptographic signing of DNS records that allows resolvers to verify responses have not been tampered with in transit. A compromised DNS response that redirects your domain's traffic is a network security failure. DNSSEC prevents it.

CAA records — restricting which certificate authorities may issue TLS certificates for your domain. An attacker who obtains a fraudulent certificate for your domain under a permissive CA has bypassed your network security boundary. CAA records constrain this attack surface.

Redundant nameservers — at least two geographically separated nameservers ensure that a regional network outage does not make your domain unreachable. Managed DNS providers (Cloudflare, Route53) satisfy this by default through Anycast.

Verification:

# DNSSEC
dig yourdomain.com DNSKEY +short

# CAA
dig yourdomain.com CAA +short

# Nameserver redundancy
dig yourdomain.com NS +short

Annex A.8.12 — Data Leakage Prevention

Scope: Measures to prevent unauthorized disclosure of sensitive information.

Email controls that contribute to A.8.12:

DMARC at p=reject prevents spoofed emails bearing your domain from reaching recipients. An attacker sending phishing email that appears to come from your domain — and successfully reaches recipients' inboxes — represents unauthorized disclosure of your brand identity and potential exposure of recipient trust. p=reject eliminates the delivery vector for this attack.

BIMI (Brand Indicators for Message Identification) is relevant here as a supporting control: by displaying your verified logo in the inbox, it helps recipients identify legitimate email from your domain and distinguish it from spoofed attempts. It is not a primary A.8.12 control but can be referenced as a user-facing anti-spoofing measure.

The Gap Analysis: Control-by-Control

Use this table to assess your current state against each Annex A control. Each row shows the specific technical check, the pass condition, and what constitutes acceptable ISMS evidence.

The Three Most Common ISO 27001 Email Security Findings

Across ISMS email security reviews, three findings appear with disproportionate frequency. Knowing them in advance lets you close them before the auditor finds them.

Finding 1: DMARC at p=none in the SoA as a "monitoring control"

Organizations document DMARC in their SoA as an implemented A.5.14 control — which is correct in principle. The problem is that the policy is p=none, and the SoA describes it as a "monitoring control for email authentication."

Auditors reject this framing for A.5.14. The clause requires information transfer to be protected, not observed. A p=none policy that delivers spoofed emails to recipients while logging the event is not protecting information transfer. It is watching it fail.

The fix is a policy change (p=quarantine → p=reject) and an SoA update that describes DMARC as an enforcement control, not a monitoring one.

Finding 2: DKIM key rotation not documented or overdue

DKIM key rotation is a standard ISO 27001 cryptographic hygiene finding. Keys that have not been rotated in over 12 months are flagged as a key management weakness under A.8 (Cryptographic Controls in the 2022 standard maps to the broader A.10 category from 2013).

The finding has two components:

No documented rotation procedure. Auditors ask for your DKIM key rotation policy — how often keys rotate, who is responsible, and how the transition is managed. If this is not documented as a procedure in your ISMS, the control is not formally in place regardless of whether you have rotated keys in practice.

No rotation log. Even if a procedure exists, auditors want a log showing when each DKIM selector was last rotated and what key length was applied. A mental note that "we rotated it about a year ago" is not sufficient.

The fix: document a DKIM rotation procedure (minimum annually, new selector deployed before old one removed, key length minimum 2048-bit), and maintain a rotation log with dates and selector names.

Finding 3: Monitoring configured but not active (A.8.16 gap)

This is the most subtle finding because it looks compliant from the outside. The DNS records are correct. DMARC has a rua= address. TLS-RPT has a rua= address. The controls appear to be in place.

The auditor asks: "Can you show me the last three months of DMARC aggregate reports and what actions you took based on them?"

If the answer is "we have them but haven't been reviewing them systematically," the A.8.16 monitoring requirement is not met. Configuration is not monitoring. Receiving reports is not monitoring. Reading them, acting on anomalies, and documenting that process is monitoring.

The fix: establish a monthly DMARC report review cadence, use a parser that makes reports readable (raw XML is not practical to review), and log the review with a brief summary each month. A one-paragraph entry in a security log — "DMARC review [date]: 98.2% pass rate, two unauthorized senders identified, both are legacy services now removed from production" — is sufficient documented evidence.

What to Include in Your ISMS Audit Evidence Package

When your auditor requests evidence for A.5.14, A.8.16, A.8.20, and A.8.12, provide these in a single organized folder:

/ISO27001-Email-DNS-Evidence/

  /A.5.14-Information-Transfer/
    dmarc-record-[date].txt          ← dig output showing p=quarantine or p=reject
    mta-sts-policy-[date].txt        ← curl output of policy file showing enforce mode
    spf-record-[date].txt            ← dig output
    dkim-records-[date].txt          ← dig outputs per selector
    soa-entry-A514.docx              ← SoA entry describing controls and ownership

  /A.8.16-Monitoring/
    dmarc-rua-review-log.xlsx        ← monthly review summary, compliance rates
    tls-rpt-config-[date].txt        ← dig output of _smtp._tls record
    dkim-rotation-log.xlsx           ← selector name, rotation date, key length

  /A.8.20-Network-Security/
    dnssec-dnskey-[date].txt         ← dig DNSKEY output
    dnssec-ds-[date].txt             ← dig DS output from parent zone
    caa-record-[date].txt            ← dig CAA output
    nameservers-[date].txt           ← dig NS output

  /A.8.12-Data-Leakage/
    dmarc-reject-evidence-[date].txt ← same as A.5.14 DMARC, p=reject confirmation

Date every file. Auditors cross-reference timestamps. An evidence file with no date, or dated the week of the audit, signals point-in-time collection rather than continuous monitoring.

Automating Evidence Collection for Annual Audits

The evidence folder above, assembled manually, takes two to four hours per audit cycle if your records are clean and you know where to look. It takes longer if anything is broken, if people have left the team, or if records were not maintained consistently.

The more durable approach is continuous monitoring that generates timestamped evidence automatically throughout the year. When the audit arrives, the evidence package is an export from the monitoring system, not a manual assembly exercise.

For ISMS audits specifically, auditors want to see that monitoring was active throughout the audit period — not just that controls were in place on audit day. A monitoring system with a 365-day audit log answers that question directly. Tools like ZeroHook cover exactly these controls — SPF, DKIM, DMARC, DNSSEC, MTA-STS, CAA, TLS-RPT, blacklist monitoring — and generate compliance-mapped reports for ISO 27001 Annex A alongside NIS2 and SOC2.

TL;DR

• ISO 27001:2022 added Annex A.5.14 — information transfer security is now an explicit named control; organizations transitioning from the 2013 standard must add email security controls (DMARC, MTA-STS) to their SoA explicitly
• Four Annex A controls cover email and DNS security: A.5.14 (information transfer — DMARC, MTA-STS, SPF, DKIM), A.8.16 (monitoring — DMARC RUA, TLS-RPT review), A.8.20 (network security — DNSSEC, CAA, redundant NS), A.8.12 (data leakage — DMARC p=reject)
• p=none does not satisfy A.5.14 — enforcement is required; p=none is a monitoring posture, not a protection control
• DKIM key rotation must be documented as a procedure and logged — auditors ask for the rotation schedule and the rotation history; a mental note is not evidence
• Monitoring configured ≠ monitoring active — receiving DMARC RUA reports satisfies nothing; reading them, acting on anomalies, and logging that review satisfies A.8.16
• Date every evidence file — timestamps on evidence are how auditors verify continuous monitoring vs. point-in-time collection assembled for the audit

*Part of an ongoing series on DNS security and compliance.