SOC2 CC6.6 Made Easy: Automating Logical Access Evidence

Your SOC2 audit window opens in three months. Your DMARC policy is p=none. Your auditor is going to flag it.

Not because p=none is wrong as a starting point — it's the standard way to begin DMARC rollout. But p=none at the start of a SOC2 audit period means that for the entire months it was in place, you had zero enforcement on a logical access control that CC6.6 explicitly requires. You cannot retroactively fix those months. You can only fix what comes next.

This is the most common CC6.6 failure mode: organizations that have technically correct configurations but arrive at the audit with the wrong policy value, at the wrong time, with no continuous evidence to show it was ever in the right state.

This guide covers exactly what CC6.6 requires for DNS and email security, what evidence auditors look for, and how to build a configuration that generates audit evidence automatically — rather than manually assembling it the week before the audit.

What CC6.6 Actually Covers

SOC2 is organized around Trust Services Criteria (TSC). CC6.6 sits inside the CC6 — Logical and Physical Access Controls category and specifically addresses:

"The entity implements logical access security measures to protect against threats from sources outside its system boundaries."

In practice, CC6.6 covers controls that prevent unauthorized external access to your systems. For most SaaS companies, the auditor's DNS and email security review under CC6.6 focuses on three threat vectors:

Email domain spoofing — an attacker sending email that appears to come from your domain. If your domain can be spoofed, phishing attacks can impersonate your company to your own customers. This is an external threat to your system boundary that email authentication controls address directly.

DNS record tampering — an attacker modifying your DNS records to redirect traffic. An unprotected DNS zone is an attack surface on your system boundary. DNSSEC and registrar-level controls address this.

Certificate issuance abuse — an attacker obtaining a valid TLS certificate for your domain through a compromised or rogue certificate authority. CAA records restrict which CAs can issue certificates for your domain.

CC6.6 also connects to CC6.1 — Security Communications, which covers transmission security. MTA-STS in enforce mode — requiring TLS for all inbound email delivery — is the CC6.1 email control that auditors verify alongside CC6.6.

The Five Controls SOC2 Auditors Check

When your auditor reviews DNS and email security as part of CC6.6, these are the specific controls they test. Each has a pass condition, a failure mode, and an evidence requirement.

Control 1: DMARC at p=quarantine or p=reject

What auditors check: The value of p= in your DMARC record at _dmarc.yourdomain.com.

Pass condition: p=quarantine or p=reject

Why p=none fails: p=none is a monitoring-only policy. It generates reports about authentication failures but takes no action — emails that fail SPF and DKIM are still delivered normally. SOC2 auditors treat p=none the same as no DMARC record from a CC6.6 enforcement perspective. You have visibility into the problem, but no control preventing it.

The timing trap: SOC2 auditors test controls at the start of the audit period, not the end. If your 12-month audit window begins January 1 and you are at p=none until March 15, you fail CC6.6 for those 10.5 weeks — even if you are at p=reject by the time the auditor arrives. The audit looks back across the entire period.

Check your current policy:

dig _dmarc.yourdomain.com TXT +short

If you see p=none, change it to p=quarantine immediately. Do not wait. Monitor DMARC reports for two to four weeks to confirm no legitimate email is failing, then advance to p=reject.

Evidence requirement: A screenshot or exported record showing p=quarantine or p=reject, timestamped at the start of the audit period. DMARC RUA reports received and reviewed during the audit period — auditors want to see that you are actively consuming the reporting data, not just publishing the record.

Control 2: All sending services in SPF, all with DKIM keys

What auditors check: Your SPF record for completeness, and DKIM key configuration for every active email sender.

The third-party sender problem: DMARC reports reveal every service sending email that claims to be from your domain. If your CRM, your marketing platform, your HR system, and your transactional email provider are all sending as your domain — and any of them are not in your SPF record or don't have DKIM configured — they appear in your DMARC reports as unauthorized senders.

SOC2 auditors review DMARC reports during the audit. Unauthorized senders in your own reports are a red flag. They indicate a gap in your logical access controls: something is sending email from your domain that is outside your control boundary.

DKIM key strength: 1024-bit DKIM keys are considered cryptographically weak and should be rotated to 2048-bit. SOC2 auditors increasingly flag 1024-bit keys as a cryptographic control weakness under CC6.6.

Check:

# SPF
dig yourdomain.com TXT +short | grep spf

# DKIM (for each active sending service selector)
dig google._domainkey.yourdomain.com TXT +short
dig selector1._domainkey.yourdomain.com TXT +short

Evidence requirement: SPF record export showing all authorized senders. DKIM TXT records for each active sending service. DMARC RUA report excerpts showing alignment pass rates above 95% for the audit period.

Control 3: MTA-STS in enforce mode (CC6.1)

What auditors check: Whether your MTA-STS policy file exists, is served over HTTPS, and specifies mode: enforce.

MTA-STS prevents downgrade attacks on inbound email delivery. Without it, a network attacker on the path between a remote mail server and yours can strip the TLS negotiation and transmit email in plaintext — bypassing your encryption entirely. mode: testing collects data but does not prevent this. mode: enforce rejects delivery attempts that cannot establish a secure TLS connection.

Check:

# DNS record
dig _mta-sts.yourdomain.com TXT +short

# Policy file
curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Pass condition: the DNS record exists, the policy file is reachable over HTTPS, and the file contains mode: enforce.

Evidence requirement: A curl output or screenshot of the policy file showing mode: enforce, with a timestamp. The DNS record screenshot showing the _mta-sts TXT record.

Control 4: DNSSEC enabled and validated

What auditors check: Whether your DNS zone has DNSSEC signing active and whether the chain of trust is complete from your zone to the TLD.

DNSSEC prevents cache poisoning attacks where a resolver is fed forged DNS responses. Without DNSSEC, an attacker who can inject forged DNS responses can redirect your domain's traffic to their server — capturing credentials, intercepting email, or serving malicious content under your brand.

Check:

# Confirm DNSKEY records exist
dig yourdomain.com DNSKEY +short

# Confirm DS record in parent zone
dig DS yourdomain.com @8.8.8.8 +short

For a visual chain-of-trust verification, dnsviz.net generates a diagram showing the full DNSSEC validation path. This is useful audit evidence — it shows the complete chain, not just the presence of individual records.

Evidence requirement: DNSKEY record output, DS record in the parent zone, or a DNSViz screenshot showing a green validation chain. Timestamped at audit start and periodically through the audit period.

Control 5: CAA records restricting certificate issuance

What auditors check: Whether CAA records exist at your domain that specify which certificate authorities are permitted to issue TLS certificates for your domain.

Without CAA records, any publicly trusted CA can issue a certificate for your domain. CAA records constrain this to your approved CA(s) — so even if an attacker successfully completes a DV validation challenge through a rogue CA, that CA cannot issue the certificate if it is not listed in your CAA record.

Check:

dig yourdomain.com CAA +short

Pass condition: at least one 0 issue "your-ca.com" record exists authorizing your current CA.

Evidence requirement: CAA record export showing authorized CAs. If you use Let's Encrypt, the record should authorize letsencrypt.org. If DigiCert, digicert.com.

The Evidence Assembly Problem

Most SaaS companies that fail CC6.6 reviews are not failing because their controls are wrong. They are failing because their evidence is wrong.

Evidence problems fall into three patterns:

Pattern 1: Point-in-time snapshots. You export your DNS records the week before the audit and submit them as evidence. The auditor asks: "How do we know these controls were in place on January 1 when the audit period started?" You have no answer.

Pattern 2: Manually assembled packages. Your team spends 20+ hours before each audit cycle hunting down screenshots, pulling DMARC report exports, collecting DNS record outputs, and organizing them into an evidence folder. This is expensive, error-prone, and produces inconsistent output across audit cycles.

Pattern 3: Missing RUA data. Your DMARC record has a rua= address, but no one has been reading the reports. The auditor asks to see DMARC aggregate reports for the audit period and you have six months of unread XML files in an inbox. The data exists but is not actionable — which is functionally the same as not having DMARC reporting at all from an audit perspective.

What Automated Evidence Collection Looks Like

The alternative to manual evidence assembly is a continuous monitoring system that generates timestamped audit evidence as a byproduct of its normal operation.

For SOC2 CC6.6, the evidence package an auditor wants covers five things:

1. DMARC record showing p=quarantine or p=reject — with history showing it was in this state throughout the audit period
2. MTA-STS policy file in enforce mode — with history
3. DNSSEC validation active — with history
4. CAA records authorizing approved CAs — with history
5. DMARC RUA reports showing compliance rates — actively received and reviewed

The word "history" is doing most of the work here. A single clean screenshot is not history. A timestamped log of automated scans run daily or weekly across the audit period is history. It shows continuity, not just current state.

ZeroHook runs continuous DNS and email security scans and maintains a tamper-proof, hash-verified audit log — the kind of timestamped, continuous evidence record that answers the auditor's "how do we know this was in place on day one?" question directly. The Compliance Pro tier includes automated evidence collection mapped specifically to SOC2 CC6.6, NIS2, and ISO 27001 Annex A.

The audit evidence package is generated from the monitoring history, not assembled manually before the audit. The difference in preparation time is the difference between two hours and two days.

The CC6.6 Audit Preparation Checklist

Run through this at least 90 days before your audit period starts — not 90 days before the auditor arrives.

Technical controls:

- [ ] DMARC at _dmarc.yourdomain.com with p=quarantine or p=reject
      dig _dmarc.yourdomain.com TXT +short

- [ ] SPF includes all active sending services (CRM, marketing, transactional)
      dig yourdomain.com TXT +short | grep spf

- [ ] DKIM configured for every sending service, all keys 2048-bit
      dig [selector]._domainkey.yourdomain.com TXT +short

- [ ] MTA-STS policy file exists at mta-sts.yourdomain.com with mode: enforce
      curl https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

- [ ] DNSSEC enabled — DNSKEY records present, DS in parent zone
      dig yourdomain.com DNSKEY +short

- [ ] CAA records specify authorized CAs
      dig yourdomain.com CAA +short

- [ ] MFA enforced on all accounts with DNS or email configuration access
      (registrar account, DNS provider, email provider admin panel)

Evidence:

- [ ] Continuous monitoring active — not just point-in-time scans
- [ ] DMARC RUA reports being received and reviewed (not just published)
- [ ] Timestamped history of all controls for the full audit period
- [ ] DMARC compliance rate above 95% in aggregate reports
- [ ] No unauthorized senders appearing in DMARC RUA reports

The MFA Requirement Under CC6.6

CC6.6 is specifically about logical access controls — and that extends beyond DNS records to the accounts that can modify them.

Every account with write access to your DNS records, your email provider configuration, or your domain registrar must have MFA enforced. This includes:

• The Cloudflare, Route53, or Google Cloud DNS dashboard account
• The domain registrar account (GoDaddy, Namecheap, etc.)
• The email provider admin panel (Google Workspace Admin, Microsoft 365 Admin Center)
• Any CI/CD service accounts that can push DNS configuration changes

For SOC2, MFA must be enforced — not optional. If a user can disable or bypass MFA on an admin account, the control is not in place. Document which accounts have admin access and confirm MFA enforcement for each.

What the Audit Evidence Package Should Contain

When your auditor requests CC6.6 evidence for DNS and email security, hand them this:

The column "start of audit period + current" is the key. Auditors want to see that the control was in place when the clock started, not just that it is in place now.

TL;DR

• CC6.6 covers external threat controls — email authentication (SPF, DKIM, DMARC), DNS integrity (DNSSEC, CAA), and transport security (MTA-STS in enforce mode) all map directly to CC6.6 and CC6.1
• p=none DMARC fails CC6.6 — enforcement is the requirement; monitoring is not. Move to p=quarantine or p=reject before your audit window opens, not before the auditor arrives
• SOC2 auditors look back, not just at current state — if p=none was in place for any portion of the audit period, those months fail the control regardless of what you fix afterward
• Unauthorized senders in DMARC reports are a red flag — audit every service sending email as your domain and ensure SPF and DKIM cover all of them
• Evidence must show continuity, not a point in time — timestamped automated monitoring history is what satisfies "how do we know this was in place on day one?"
• MFA on all DNS and email admin accounts is part of CC6.6 — document which accounts have access and confirm enforcement, not just availability

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