The non-quantum surface signals: email auth, headers, DNS takeover.

The Decryption Blast Radius score answers a quantum-specific question. ASM completeness signals answer the other question every visitor asks: "are these guys also checking the obvious stuff?" This page documents the email-auth, security-header, and DNS-takeover checks layered onto every Cipherwake report — what they measure, how they score, what they don't claim.

What this tool measures

Three independent surfaces, each contributing a findings stream — they do not alter the Decryption Blast Radius score itself, to keep the quantum signal isolated. They appear as their own grouped findings on every report.

1. Email authentication (SPF / DMARC / DKIM)

• SPF — DNS TXT lookup for v=spf1 at the apex; checks for missing record, overly permissive (+all), ~all vs. -all posture, and the 10-DNS-lookup limit.
• DMARC — DNS TXT at _dmarc.<domain>; checks for missing record, p=none (monitor-only), p=quarantine, p=reject, and presence of rua/ruf reporting addresses.
• DKIM — opportunistic check at common selectors (default, google, k1, selector1, s1, mandrill, etc.); presence indicates DKIM signing is configured but cannot prove signing for any specific message.

2. Security headers

HTTPS HEAD/GET to the apex + www; we record the presence and basic posture of:

• Strict-Transport-Security (HSTS) — presence, max-age, includeSubDomains, preload.
• Content-Security-Policy — presence (we do not deeply parse).
• X-Content-Type-Options: nosniff.
• Referrer-Policy.
• X-Frame-Options or equivalent frame-ancestors directive in CSP.
• Permissions-Policy (presence only).

3. DNS takeover risk

For each subdomain observed in CT logs we check:

• CNAME targets pointing to known-takeover-prone services (GitHub Pages, Heroku, AWS S3, Azure App Service, Fastly, etc.) where the target endpoint returns a "no such app" / "bucket not found" / 404-with-takeover-marker response.
• Dangling A records pointing to IPs no longer in the listed cloud's allocation.
• NS delegations to providers with terminated accounts.

How we measure it

SPF and DMARC are pure DNS lookups and execute in milliseconds. DKIM is a best-effort selector probe and never fully proves signing — its absence at common selectors is suggestive, not conclusive.

Header checks fetch the apex + www; we honor robots.txt for the surface scan and use a 10-second timeout. We record HTTP status, response time, and the header set; we do not render JavaScript, follow client-side redirects, or fetch any subresources.

Takeover checks query each candidate target, look for the well-known takeover-fingerprint response from the cloud provider, and flag matches. We follow well-published heuristics (Detectify's takeover dictionary as a reference set) and refresh the rules quarterly.

How it scores

Each surface contributes findings (severity-tagged) but does not modify the DBR score. The findings appear in their own grouping with severity:

Signal	Severity if missing/weak
SPF missing or +all	High
DMARC missing	High
DMARC p=none	Medium
HSTS missing	Medium
HSTS < 6 months	Low
CSP missing	Low (informational)
X-Content-Type-Options missing	Low
Subdomain takeover detected	Critical
Dangling DNS suggestive of takeover	High

What this tool does NOT claim

• It does not claim quantum risk. ASM signals are non-quantum; they appear alongside the DBR but do not modify it. A perfect ASM grade plus a failing DBR is a real outcome — and it should be a real outcome, because they measure different things.
• It does not test outbound email signing. DKIM presence at a common selector is necessary but not sufficient; we cannot prove your outbound mail is signed without sampling actual messages.
• It does not parse CSP. A trivially-broken CSP (default-src *) and a hardened CSP both show as "present." Deep CSP analysis is on our roadmap, not shipped today.
• Takeover detection is heuristic. A "takeover-prone" finding is a signal that the CNAME target's response matches a known takeover fingerprint; it does not prove the subdomain is currently takeover-able by an attacker. False positives occur when the cloud provider's fingerprint is also returned for legitimate non-deployed states.
• It does not test mail-server posture. MTA-STS, DANE, and TLS-RPT are not currently scored.
• It does not score compliance. A "C" on email auth is not a HIPAA / PCI / SOX deficiency — that mapping is explicitly out of scope. Cipherwake does not produce audit-ready outputs.

Limitations + edge cases

• Some hosts respond differently to HEAD vs. GET; we attempt HEAD first, fall back to GET. Pathological servers that 5xx on HEAD may show false-missing headers.
• Anycast / CDN edge inconsistency is real — our scan is a single observation. A site with edge-by-edge variance may show different headers on different scans.
• Reverse-DNS / WAF blocking can produce a "site unreachable" outcome that masks underlying configuration. We surface "reachable: false" rather than scoring a configuration we couldn't observe.
• For domains with hundreds of subdomains, takeover checks are sampled across CT-log entries observed in the trailing 90 days; older dormant subdomains may not be checked on every scan.

Try it

• Web: cipherwake.io — every report shows ASM completeness alongside the DBR.
• CLI: npx pqcheck <domain>
• API: /api/scan?domain=<domain> returns the full findings stream including ASM.