Domain Posture (DNS & E-mail Security)

What it is

Domain Posture checks the DNS and e-mail-authentication records of the domains you have proven you own — SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, DNSSEC, CAA, nameserver diversity, and dangling CNAMEs a third party could take over. Nothing is scanned until a domain is verified: adding a domain performs no lookup at all — only the ownership proof is checked first. Once verified, CMDash re-scans daily, grades the domain A–F, tracks the grade over time, and attaches evidence to the compliance controls those checks already exist for — so DMARC stops being a self-attested checkbox and becomes a control with real evidence.

This is scoped to domains you control — not a scanner you can point at anyone else's domain, and not (yet) an outside-in rating like the Vendors (TPRM) monitoring adapters, which rate a vendor's domain from published signals, not DNS. Its result feeds the Reputation Score on the Exposure overview, /exposure.

When to use it

Add your primary domain the first time you visit /exposure/domains — it is usually offered automatically. Add any other domain (subsidiaries, product brands, marketing or parked domains) whenever you want its posture tracked and graded. Check back after any DNS change to mail, SPF, or DMARC records — a scan runs the next day, or rescan on demand. Use a check's copy-ready recommendation to hand your zone's manager the exact fix.

Before you start

How to

Add your primary domain

If your account's e-mail is verified and its domain isn't a free-mail provider (Gmail, Outlook.com), CMDash offers it on the Domain Posture page: "Claim yourcompany.com as your primary domain?" Claim verifies it instantly, no DNS change needed — your verified e-mail address is itself the proof.

This instant proof is scan-only: the free-mail list fails open by design, so an e-mail-proven domain never grants SSO JIT provisioning, Trust Center routing, or any other authority — only these checks. Publish the same TXT record described below to upgrade it to the stronger, DNS-proven method.

A second tenant that shares your e-mail domain (a subsidiary, say) gets its own primary-domain row and results — nothing about one tenant's row is visible to another's.

Prove another domain

1. Click Add domain and enter the domain name. Nothing is looked up yet — this reserves a Pending row and a fresh, one-time proof token.
2. CMDash shows the TXT record to publish: host/name _cmdash-verify.<yourdomain> and value cmdash-verify=<token>, each with a copy button.
3. Registrar host-field notes. Some DNS hosts want the full name above in the host field; others want only the first label (_cmdash-verify) and append the domain themselves — try the short form if the full name is rejected.
4. Publish the record, then click Check now (rate-limited to once a minute per domain). It always reports what was actually seen — "found 1 TXT record, token did not match," not a bare "not verified." A lookup that got no answer at all (timeout, refused query) is reported as such and changes nothing about the domain's status — it is never read as "record missing."
5. Once the record matches, the domain moves to Verified and its first scan runs.

A daily sweep checks every Pending domain; Check now is optional.

Re-proof and lapsing

A Verified domain is re-checked at least weekly. A missing TXT record gets an in-app notice on day 1 and day 10 of a 14-day grace period, and scans continue through it. If the record still hasn't reappeared after 14 days, the domain moves to Lapsed and scanning stops until it's restored. Removing a domain yourself sets it to Removed, frees its slot immediately, and keeps its history for the standard retention window before it's purged.

Read the results

Each domain's detail page groups every check by category (Mail, Zone, Takeover), filterable by status, plus a grade history sparkline. Each result carries:

• Status — PASS, WARN, FAIL, INFO (informational, never graded), NOT_APPLICABLE (doesn't apply to this domain's shape, e.g. a mail check with no MX), or UNKNOWN.
• Evidence — the actual DNS records CMDash read.
• Finding and recommendation — plain-language, plus a copy-ready corrected DNS record where one can be computed (a DMARC p=none line rewritten to p=quarantine, keeping your rua).
• References — the relevant RFC section and the compliance controls it evidences.

UNKNOWN and "insufficient data" are not failures

UNKNOWN means the resolver could not get an answer — a timeout, a SERVFAIL, a refused query, or (for DKIM) an unprobed selector. It is never scored as a pass or fail and never counts toward a grade — shown separately so "needs attention" stays distinct from "couldn't check."

Insufficient data, shown instead of a letter grade, means fewer than 60% of the checks that applied actually produced a PASS/WARN/FAIL — usually a run of resolver timeouts, not a real finding. NOT_APPLICABLE and INFO are excluded from that denominator entirely; UNKNOWN counts as "applicable but unanswered." A grade is only shown once enough of the picture is in — never built on the two or three checks that happened to answer.

The full check list

Mail checks apply when the domain has MX records; a no-MX domain instead gets the parked-domain checks (null MX, hard-fail SPF, reject DMARC) — a no-mail domain must say so, not go silently exempt.

Mail (SPF/DMARC/DKIM/MTA-STS/TLS-RPT/BIMI):

Zone:

Takeover:

How results become control evidence

A scan's results attach as machine evidence to the controls they speak to — CIS Controls 9.5 ("Implement DMARC"), NIST 800-53 SC-20/SC-21, ISO/IEC 27001:2022 A.8.20, A.8.21 and A.5.14, and CMMC Level 2 SC.L2-3.13.1 and SC.L2-3.13.8. Where these relied on a typed attestation, a scan gives real, dated evidence instead — visible on the control's own evidence tab.

Common questions

Why is my domain graded "insufficient data" instead of a letter? Fewer than 60% of applied checks produced a real PASS/WARN/FAIL, most often from lookups timing out mid-scan. It isn't a failing grade — wait for the next scan or rescan on demand.

I don't see a DKIM result at all — is that a failure? No DKIM record under any probed selector reads as UNKNOWN, not FAIL — selectors can't be enumerated from DNS the way SPF and DMARC records can. Add your provider's selector if it isn't in the default list, then rescan.

Can I add a domain someone else already verified? Yes, but it stays Pending for you — only a TXT record carrying your row's own token proves your row. An MSP and its client can each independently prove the same domain; neither inherits or sees the other's verification.

What happens if I remove (revoke) a domain? Scanning stops immediately and its slot frees right away. History is kept for the retention window, then purged.

Related

• IP Reputation
• Reputation Score
• Vendors (TPRM) & Questionnaires
• Compliance Frameworks
• Evidence Collection
• Prove a domain