DMARC as ISO 27001 audit evidence: the control auditors love

DKIM, cryptographic keys and secret management

DKIM, one of DMARC's two alignment pillars, rests on a cryptographic key pair. The private key signs the outgoing mail; the public key, published in DNS, lets recipients verify the signature. That private key is a first-rank secret: if it leaks, an attacker can sign messages in the organisation's name and clear its DMARC defences as if they were the organisation itself.

ISO 27001 explicitly addresses the use of cryptography and key management among its technological controls. Concretely, an auditor expects robust keys (see DKIM 1024 vs 2048 bits for the right sizing), stored under strict access control — and above all not in a versioned config file, a ticket or a chat channel — and rotated regularly. A dedicated secrets vault such as Hucency Vault, from cybersecurity specialist Hucency, answers precisely this requirement: centralising private DKIM keys and API tokens under controlled, logged access, rather than letting them scatter across the organisation. The periodic rotation of those keys is itself a control — its implementation is detailed in DKIM key rotation.

This point is often overlooked because DKIM "works" even with a poorly managed key. But from an audit standpoint, a signing key stored carelessly is a finding: it turns the best anti-spoofing control there is into a single point of failure.

Evidence, not promises

This is where DMARC shines in a certification context. Unlike many internal controls whose evidence requires digging through logs or interviewing teams, the DMARC posture is public and timestampable. An auditor — or anyone — reads the record in seconds and sees directly whether the domain sits at p=none, p=quarantine or p=reject. No contestable screenshot, no sworn statement: the data speaks for itself.

Alongside that sit the archived RUA reports, which are records in the standard's sense: month after month, they document who sends in the organisation's name and how the posture evolves. Kept properly, they prove not only that the control exists, but that it is monitored — the exact distinction between a living control and a box ticked once and forgotten.

From none to reject: what the auditor really wants to see

A mature auditor is not fooled by a p=none. They know an observation-only domain protects nothing: it documents spoofing without blocking it. The evidence that holds is different: a domain at p=reject, a report history showing the gradual ramp-up, a documented procedure describing the move from observation to enforcement, and a periodic review written into the ISMS. The full operational sequence is described in getting to p=reject without breaking email; on the audit side, it is that history that turns "we have DMARC" into a defensible finding.

The same reasoning structures the protection of the most-targeted brands, developed in DMARC for banks: enforcement, not mere publication, is what counts.

Building the evidence file, step by step

An ISO 27001 audit is won on the quality of the file as much as on the reality of the control. For email authentication, a convincing file gathers a few simple pieces, all preparable in advance:

• The statement-of-applicability entry justifying the controls chosen for anti-spoofing protection.
• The matching line in the risk register, where "email domain spoofing" is named, assessed and linked to DMARC as its treatment.
• The posture evidence: the current DMARC record, timestamped, showing p=reject — a simple dated capture suffices, since the data is public and reproducible at will.
• The RUA report archive, which materialises continuous monitoring and the evolution of posture over time.
• The DKIM key-management procedure: where private keys are stored, who has access, how often they rotate, with the rotation log.
• The review cadence written into the ISMS: who checks the posture, how often, and what triggers a corrective action.

Assembled once, this file updates in minutes before each review. It turns a verbal claim into documentary proof — the only currency that really counts in an audit.

The gaps that make an auditor flinch

Conversely, a few classic configurations trigger an immediate remark, or even a non-conformity:

• Presenting p=none as a control in place. The most common gap: observation is not protection, and a seasoned auditor spots the difference at a glance.
• A private DKIM key in a code repository or a ticket. An exposed cryptographic secret nullifies the control's benefit and constitutes a clear key-management gap.
• No rotation and no rotation log. A key that has never turned in years is a dormant point of failure.
• Reports never retained. Without an archive, monitoring cannot be demonstrated: the control may exist, but the proof does not.
• Only the corporate domain covered. If the consumer-facing domain — the one clients and users actually see — stays at p=none, the protection on display is misleading.

None of these gaps is hard to fix; they almost always come from a control installed and then forgotten, for lack of a clear owner. Naming an owner for the authentication posture, even part-time, and giving them an up-to-date dashboard usually makes them all disappear at once — and turns the email audit from a worry into a formality.

Reusable proof across the whole compliance estate

The strategic advantage of doing this work well once: the audit trail travels. The same file — p=reject posture, archived reports, ramp-up procedure, key management — serves directly to demonstrate diligence under NIS2 and to answer the security limb of email authentication under GDPR. That is not three separate files to build; it is one solid control, presented under three regulatory angles.

A control an auditor can verify unaided

One underrated property is worth stressing: DMARC is among the very few controls an auditor can verify independently, without asking the organisation for anything. A DNS query, a read of the policy, and the posture is known — no interview, no evidence request, no room for a flattering interpretation. That independence cuts both ways. It makes a genuine p=reject effortless to substantiate, and it makes a p=none dressed up as protection impossible to hide. It works as an incentive: since the auditor will see the real posture anyway, the only winning move is to make the real posture the one worth finding — which is simply another way of saying that the enforcement work beats the paperwork around it.

Checking the posture before the auditor does

The first step is free and immediate. A domain run through our free DMARC analyzer returns an instant verdict on its current policy, and the DMARC Observatory then places that posture against its sector.

Assembling and maintaining a clean audit file — per-domain posture, identified sending sources, readiness history — is exactly what Thomas, the virtual CISO, automates: he names every source, generates the DNS to publish, assesses per-domain readiness and documents the path to enforcement. Analyze a domain for free · explore the Observatory · get started with Thomas.