SOC2 CC6.6 DNS Monitoring Evidence
Type II auditors do not want a DMARC screenshot from Tuesday. They want proof your DNS email controls stayed enforced for the entire audit window.

Your SOC2 auditor opens the evidence folder. You hand them a PDF of a dig command you ran last month. A 41-person HR SaaS in Austin started a Type II window in January 2026 with DMARC at p=none. Marketing flipped an ESP in March. Nobody updated SPF. DMARC alignment failed on 18% of outbound mail for six weeks. The security lead fixed DNS in April, exported fresh screenshots, and assumed the gap was closed. The auditor mapped the failure to CC6.6 logical access and CC7.1 monitoring: controls were not operating consistently during the period under review. Remediation became a qualified opinion conversation, not a checkbox. SOC2 CC6.6 DNS monitoring is not about owning a fancy DNS panel. It is about proving boundary and access controls for email infrastructure held steady while the auditor's clock was running. Type II reviews every day in the window, not the day you remembered to run dig.
What CC6.6 Means for DNS (Not Just Firewalls)
AICPA Trust Services Criteria
SOC 2 CC6.6 sits under Logical and Physical Access Controls. Auditors interpret it as restricting access to systems and data at your boundaries. For most SaaS companies in 2026, public DNS is a boundary. If someone can spoof mail from your domain or downgrade TLS on inbound SMTP, that is an external access path you failed to close.
Where DNS records map
Auditors commonly tie email DNS to multiple criteria in the same evidence request:
| Criteria | DNS/email control auditors cite |
|---|---|
| CC6.1 | DMARC at p=quarantine or p=reject stops unauthorized sending |
| CC6.6 | MTA-STS enforce mode protects SMTP TLS at the domain boundary |
| CC7.1 | DMARC RUA/RUF reporting proves you detect authentication anomalies |
You will hear "CC6.6" in the meeting. The evidence packet still needs DMARC enforcement, transport security, and proof you reviewed reports. Treat them as one operational program, not three unrelated TXT records.
Why SMBs get surprised
According to Vanta's 2025 Trust Maturity Report, 71% of organizations in the earliest maturity tier already hold SOC 2 attestation. Most already had SPF and DKIM. Far fewer had enforced DMARC across the full audit window or documented who could edit DNS at Cloudflare, Route53, or GoDaddy. Authentication existed. Operating effectiveness did not.
Why Screenshots and Spreadsheets Fail Audits
The Tuesday problem
A TXT record screenshot proves state at capture time. Type II asks whether the control operated consistently. If p=none was live for the first 90 days of a 12-month window, those 90 days count as a gap even if you moved to p=quarantine on day 91.
Excel change logs
Teams export "before and after" DNS in spreadsheets. Auditors ask who edited the file last. Without hash verification or immutable timestamps, Excel fails the integrity test fast. We've seen compliance leads rebuild the same sheet three times because version history was not defensible.
Manual dig habits
Running dig _dmarc.example.com TXT +short before the audit is rehearsal, not monitoring. It does not show alerting fired when marketing added a second SPF include, or that someone reviewed DMARC aggregate XML when volume spiked.
Honestly, if your evidence strategy is "we'll scrape DNS the week before the auditor arrives," you're documenting panic, not a control.
“SOC2 Type II is a movie of your controls, not a photograph of the day you cleaned up for visitors.”
Evidence Auditors Actually Accept
Minimum defensible package
Prepare these artifacts before the audit window opens, then keep them current weekly:
- Baseline record set: SPF, DKIM selectors, DMARC, MTA-STS, TLS-RPT, DNSSEC status with timestamps at window start.
- Enforcement proof: DMARC policy showing p=quarantine or p=reject (p=none is monitor-only; auditors treat it as incomplete for CC6.1/CC6.6 email boundaries).
- Transport security: MTA-STS policy in enforce mode plus TLS-RPT address receiving reports.
- Change detection: alerts or logs when any auth record changes, with ticket IDs for remediation.
- Report review: sampled DMARC aggregate weeks with analyst notes ("aligned pass rate 99.2%, investigated 14 failures from legacy ESP").
- Access control narrative: MFA on DNS/registrar accounts, named owners, quarterly access review (ties CC6.6 logical access to infrastructure reality).
Cross-framework overlap
If you also face NIS2 or ISO 27001 questions, reuse the same evidence spine. Our NIS2 email checklist covers parallel DNS controls: zerohook.org/blog/nis2-email-security-requirements-checklist-2026. ISO 27001 Annex A email records map to the same TXT objects with different control IDs: zerohook.org/blog/iso-27001-annex-a-email-dns-controls.
Frequency
Weekly automated scans plus monthly human review of DMARC XML beats quarterly manual audits. Auditors want to see the review happened, not that you own a tool.
Build the Monitoring Baseline (Step by Step)
Freeze the sending inventory
List every system that sends as your domain: Microsoft 365, Google Workspace, HubSpot, SendGrid, transactional pipes. Unknown senders become audit findings when SPF permerror hits.
Enforce DMARC before day one
Move to p=quarantine minimum. p=reject when alignment is stable two weeks straight. Verify with:
dig _dmarc.example.com TXT +shortPublish MTA-STS and TLS-RPT
Host policy at https://mta-sts.example.com/.well-known/mta-sts.txt with mode: enforce. Publish TLS-RPT at:
_smtp._tls.example.com TXT v=TLSRPTv1; rua=mailto:[email protected]
Lock DNS administrative access
Enable MFA on Cloudflare, AWS Route53, GoDaddy, or wherever your zone lives. Document which roles can edit TXT records. Remove departed employees from registrar accounts the same day.
Turn on continuous monitoring
Daily or weekly automated checks on all auth records. Alert on any change to SPF, DKIM, DMARC, MTA-STS. Store results with timestamps you can export by audit week.
Run a pre-window dry audit
Four weeks before the official start, run a full 35-check DNS audit (SPF lookup limits, blacklist, subdomain takeover, compliance mapping). Fix warnings while you still have runway. Free scan: zerohook.org/dns-visualizer.
Operating Effectiveness: What "Continuous" Means
Detection without review is theater
CC7.1 expects anomalies to be identified and acted on. Pointing rua= at an inbox nobody reads is a finding. Assign an owner. Review aggregate reports at least monthly. Escalate spikes above your baseline (we usually flag when failure rate jumps 2x week over week).
Tamper-proof logs
For teams on Compliance Evidence Pack tier workflows, hash-verified audit logs satisfy integrity questions Excel cannot. The point is immutability: an auditor can trace a DNS change event to a timestamp and response ticket without trusting a editable workbook.
Cost context
Manual pre-audit consulting for DNS/email controls often runs $5,000-$15,000 per cycle (market range cited on zerohook.org/pricing). Continuous monitoring plus exportable evidence costs less than repeating emergency remediation every year. That math matters when the board asks why SOC2 prep keeps slipping a quarter.
SaaS buyer pressure
Enterprise procurement increasingly asks for SOC 2 Type II before production data flows. DNS evidence is the unglamorous section that delays sign-off when DMARC was "planned for Q3" since two audit cycles ago. Details for SaaS founders: zerohook.org/for-saas.
Frequently Asked Questions
Does p=none satisfy CC6.6?
No. Monitor-only DMARC does not demonstrate an enforced boundary control. Move to p=quarantine or p=reject before the window.
How often should we collect DNS evidence?
Weekly automated snapshots are a practical minimum for Type II. Daily is better during migration periods. Monthly manual dig is not enough.
Is MTA-STS required for SOC2?
Not every auditor lists it on day one, but 2026 Type II questionnaires increasingly ask about SMTP TLS enforcement. MTA-STS in enforce mode plus TLS-RPT is the clearest proof. Validate at zerohook.org/mta-sts-validator.
Can we reuse NIS2 DNS work for SOC2?
Yes. The records overlap. Map the same evidence to different control IDs in your matrix. NIS2 Article 21 DNS asks mirror much of this stack.
What is the most common CC6.6 DNS failure?
DMARC at p=none for part of the audit window, plus no documented review of authentication reports. Fix policy first, then prove you watched it.
Key takeaways
Type II tests the whole window. A last-minute DNS cleanup does not erase earlier gaps.
CC6.6 DNS evidence bundles DMARC enforcement, MTA-STS, change detection, and report review.
Screenshots and Excel fail integrity and continuity questions. Use timestamped, exportable monitoring.
Lock MFA on DNS panels and run a 35-check dry audit four weeks before the window opens.
Align NIS2 and ISO 27001 evidence to the same DNS baseline to avoid duplicate fire drills.
Compare plans with automated SOC2 CC6.6 evidence collection at zerohook.org/pricing if manual exports keep missing your audit calendar.
Share this analysis
Help others discover this content
About the author

The ZeroHook Team tracks NIS2, ISO 27001, SOC2, and GDPR evidence requirements for EU SMBs. We write what auditors actually ask for, not what vendor decks claim.


