Safeguard 9.5: Implement DMARC

Email spoofing remains one of the most practical ways attackers impersonate executives, invoice customers, and trick employees into credential entry or fraudulent payments. DMARC (Domain-based Message Authentication, Reporting & Conformance) is the control that lets your organization publish an explicit policy for how receiving mail systems should treat unauthenticated mail claiming to be from your domains. CIS includes this as Safeguard 9.5 because it is a repeatable, high-signal control: you can verify it from DNS, you can monitor it continuously, and you can demonstrate operation through DMARC reports and policy change records. ¹

For a Compliance Officer, CCO, or GRC lead, the work is less about configuring a single DNS record and more about driving cross-functional closure: getting Marketing, HR, Customer Support, IT, and third parties to disclose every email-sending service; aligning authentication across them; then moving from “observe” to “enforce” with documented risk acceptance where exceptions remain. This page gives requirement-level guidance to implement and evidence DMARC in a way that stands up in an assessment against CIS Controls v8 Safeguard 9.5. ²

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 9.5 implementation expectation (Implement DMARC).” ¹

Operator interpretation: You must implement DMARC for organizational domains that send email, meaning:

• DMARC DNS records exist for in-scope domains.
• DMARC policy is intentionally managed (not forgotten in “monitoring” indefinitely).
• SPF and/or DKIM are correctly configured so DMARC can pass with alignment.
• DMARC reporting is configured and reviewed to detect spoofing and misconfigurations.
• You can prove the control operates through repeatable evidence capture. ²

Plain-English interpretation (what an auditor is really testing)

An assessor is effectively asking: “Can someone send an email that looks like it came from your domain, and will recipients accept it?” DMARC reduces that risk by telling recipient systems what to do when authentication fails and by giving you visibility into who is sending mail using your domains (legitimate or not).

A common compliance gap is “DMARC exists” but is set to p=none forever, reports are not reviewed, and the organization still has unauthenticated senders. For CIS Safeguard 9.5, you should be able to show a managed program: defined scope, current DNS state, reporting, and a path to enforcement for business-critical domains. ¹

Who it applies to

Entity scope: Enterprises and technology organizations adopting CIS Controls v8. ²

Operational scope (what systems):

• Primary corporate domains (e.g., company.com) and any subdomains used for outbound mail (e.g., notify.company.com).
• Brand/marketing domains and lookalike domains you control.
• Email infrastructure and services: Microsoft 365/Google Workspace, CRM mailers, ticketing systems, marketing automation, payroll/benefits communications, and any third party that sends email “from” your domain or uses your domain in the visible From: address.

Third-party risk angle: If a third party sends email as your domain, your DMARC posture depends on their ability to support SPF/DKIM alignment. Your due diligence should explicitly ask if they support “DKIM signing with customer domain” and what DNS records are required.

What you actually need to do (step-by-step)

Step 1: Build the authoritative sending-domain inventory

Create one list that includes:

• All domains your organization owns.
• Which domains are used for outbound email (humans and systems).
• Every sending source (mail platform, application, or third party).
• Business owner for each sending source.

Practical method: Pull from DNS registrar exports, certificate management inventories, and marketing domain lists. Then validate with DMARC aggregate reports once you begin receiving them (those reports will reveal unknown senders).

Deliverable: “Email Domain & Sender Inventory” with owners and approved senders.

Step 2: Establish SPF for each sending domain (with restraint)

For each sending domain:

• Publish/validate an SPF record that authorizes all legitimate sending IPs and services.
• Control SPF sprawl. Too many includes and legacy services are a reliability and change-risk problem.

Decision rule: If a sender can sign with DKIM for your domain, favor DKIM alignment for DMARC pass. Keep SPF simple where possible.

Step 3: Establish DKIM signing for each legitimate sender

For each sending system/third party:

• Enable DKIM signing.
• Publish vendor-provided DKIM public keys in DNS for the right selector(s).
• Confirm the d= domain in DKIM aligns with the domain in the visible From: address (alignment is what DMARC evaluates).

Reality check: Some third parties “send on behalf of” you but cannot DKIM-sign with your domain. Treat those as exceptions with a remediation plan (switch provider, change sending domain, or change how From: is constructed).

Step 4: Publish DMARC in monitoring mode and turn on reporting

Publish a DMARC TXT record for each in-scope domain, starting with monitoring:

• v=DMARC1; p=none; rua=mailto:dmarc-aggregate@yourdomain; ruf=mailto:dmarc-forensic@yourdomain (optional); adkim=s; aspf=s; fo=1; pct=100

Operational requirement: Ensure the mailboxes for rua (and ruf if used) are owned, monitored, and can receive large volumes. Many teams route reports to a DMARC analysis service; that is acceptable if you retain access and evidence.

Step 5: Analyze reports, fix alignment failures, and remove unknown senders

Use the aggregate reports to:

• Identify legitimate sources failing SPF/DKIM alignment.
• Identify “shadow” senders (teams using unapproved mail tools).
• Identify malicious spoofing attempts and which receivers are seeing them.

Workflow tip: Treat each sender as a ticket with an owner, target state (DKIM/SPF aligned), and closure evidence (screenshots, test results, DNS change record).

Step 6: Move DMARC to enforcement (quarantine, then reject) based on risk

Once legitimate traffic is consistently passing:

• Move to p=quarantine for the domain(s) that matter most for impersonation (often the primary corporate domain).
• Then move to p=reject.

You may choose staged enforcement by subdomain, business unit, or domain criticality. Document the rationale and any accepted risk for domains that remain at p=none.

Step 7: Set control ownership, change management, and recurring evidence capture

DMARC fails over time when marketing adds a new sender, IT changes email routing, or a third party rotates keys. Make it an operated control:

• Assign control owner (Security or Messaging) and GRC reviewer.
• Route DNS changes through change control with peer review.
• Review DMARC reports on a defined cadence and record outcomes.

CIS-aligned control note: Map Safeguard 9.5 to a documented control operation and recurring evidence capture so you can show ongoing operation, not a one-time project. ¹

Required evidence and artifacts to retain

Keep artifacts that prove scope, configuration, operation, and governance:

Configuration evidence

• DNS screenshots/exports showing current SPF, DKIM, and DMARC records per domain.
• A record of DMARC policy state per domain (none/quarantine/reject) and last change date.
• DKIM selector list and rotation notes (where applicable).

Operational evidence

• DMARC aggregate report access and samples (or exports from your DMARC reporting tool).
• Monthly/quarterly review notes: findings, resolved senders, and open exceptions.
• Incident records tied to spoofing attempts (if observed) and what actions were taken.

Governance evidence

• Email authentication standard (internal policy/procedure) describing SPF/DKIM/DMARC requirements for any system or third party sending email as your domains.
• Change management approvals for DNS and email platform changes.
• Exception register entries for any domains stuck at monitoring mode, including compensating controls and target remediation.

Common exam/audit questions and hangups

Auditors and customers tend to focus on these points:

1. “List all domains and show DMARC for each.” If you miss a marketing domain, your control looks incomplete.
2. “Is DMARC enforced or just monitored?” Be ready to explain why a domain remains at p=none and what the plan is.
3. “How do you know third parties are covered?” Expect questions about SaaS mailers and whether they can DKIM-sign with your domain.
4. “Who reviews DMARC reports, and what do they do with them?” “We receive reports” is weak; show a review record and remediation tickets.
5. “How do you prevent regressions?” Show change control triggers: any new email-sending third party must pass an authentication checklist before go-live.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it hurts	Avoidance
Publishing DMARC only on the primary domain	Attackers spoof secondary domains and subdomains	Inventory domains; publish DMARC on every domain that sends or could be abused
Leaving p=none indefinitely	No blocking effect; weak control posture	Set an enforcement roadmap and document exceptions
Misaligned DKIM (vendor signs with their domain)	DMARC fails even with DKIM present	Require “customer-domain DKIM” in third-party onboarding
Overgrown SPF records	Breaks mail delivery during changes; hard to audit	Prefer DKIM alignment; prune legacy includes
No ownership for reports	Issues persist; “implemented” becomes stale	Assign an operator and a review cadence; retain review outputs

Enforcement context and risk implications

CIS Controls v8 is a framework, not a regulator, so you should not expect CIS-specific “fines.” Your exposure shows up differently:

• Security risk: spoofing enables BEC-style fraud, credential harvesting, and customer trust damage.
• Assurance risk: enterprise customers may treat DMARC enforcement as a gating control in security reviews.
• Operational risk: misconfigured SPF/DKIM/DMARC can break legitimate business mail; staged rollout and change control reduce that risk. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and visibility)

• Assign an owner for email authentication and a GRC point of contact.
• Build the domain + sender inventory and validate it with stakeholders (IT, Marketing, HR, Support).
• Publish DMARC p=none with rua reporting for the highest-risk domains first.
• Stand up an intake process: every email-sending third party must provide SPF/DKIM requirements before approval.

Next 60 days (fix alignment and shrink the unknowns)

• Triage DMARC aggregate reports to identify all legitimate senders.
• Enable DKIM signing and correct alignment for each sender.
• Remove or replace unapproved senders; formalize exceptions where removal is not immediate.
• Document operating procedure and evidence capture steps for Safeguard 9.5. ²

By 90 days (move to enforcement where feasible, lock in operations)

• Move priority domains to p=quarantine, then to p=reject once reports show stability.
• Confirm subdomains and brand domains have an intentional DMARC posture (enforced or documented exception).
• Schedule recurring reviews and integrate checks into third-party onboarding and change management.
• Store evidence packages in your GRC system; Daydream is a practical place to map Safeguard 9.5 to owners, tickets, and recurring evidence requests without rebuilding the workflow each audit cycle. ¹

Frequently Asked Questions

Do we need DMARC on every domain we own, or only the one employees email from?

Scope DMARC to every domain that sends email or could credibly be used to impersonate your organization. In practice, that includes marketing and notification domains, not just the employee mailbox domain.

Is “p=none” considered compliant with safeguard 9.5: implement dmarc requirement?

“p=none” proves publication and reporting, but it does not block spoofing. Treat it as an initial state, then document a path to enforcement or a time-bound exception with risk acceptance. ¹

We use multiple third parties to send email. What do we require from them?

Require the ability to DKIM-sign with your domain (aligned DKIM) or a clearly documented SPF approach that will pass DMARC alignment. Capture their DNS requirements and keep them with the third-party record.

Can DMARC break legitimate emails?

Yes, if you enforce quarantine/reject before legitimate senders are aligned. Start in monitoring, remediate alignment, then enforce in stages with change control and a rollback plan.

Who should own DMARC: Security, IT, or Marketing Ops?

IT or Messaging teams usually own DNS and mail flow changes, while Security owns the control objective and monitoring. Put both in the RACI so changes cannot bypass authentication requirements.

What evidence is strongest for auditors?

DNS record exports plus proof of operation: DMARC report review records, remediation tickets for failing senders, and documented approvals for policy changes and exceptions. ²

Footnotes

1. CIS Controls v8

2. CIS Controls Navigator v8