Prove a Domain
What it is
Prove a domain (/proof/domains) shows CMDash that your organization controls a domain, by
publishing one DNS TXT record. A proven domain is what lets your workspace answer a proof request
sent to an address at that domain (see Relying-Party Desk): a request
is answered only by the workspace that owns the domain it was sent to.
The check reads one record and nothing else: _cmdash-verify.<your domain>, expecting a TXT
value of the form cmdash-verify=<token> that CMDash gives you when you add the domain. Adding a
domain performs no lookup; nothing is resolved until you ask, or until the daily check for a
domain you added.
No DNS access? You can instead confirm the domain with a one-time link mailed to a role mailbox there (see Prove it by a role mailbox below). That is a lighter proof: it only lets your workspace answer proof requests sent to the domain, labelled E-mail-verified (domain not proven by DNS), and only self-assessed and self-attested lines are shared at that level.
This is proof of ownership, not a security scan. It never grades SPF, DKIM, DMARC or anything else about the domain. That is Domain Posture, a separate module on Essentials and above.
When to use it
Before you accept a proof request from a company that asked for one. Do it ahead of time and the request is a single click.
Before you start
- Tier: every tier, Free and up (the
PROOF_RECEIPTSentitlement). - Role: any member can see the list. Adding, checking and removing a domain is OWNER or ADMIN.
- Domain slots: Free and Starter workspaces can prove one domain. Essentials and above use the same slot pool as Domain Posture, at their existing limit. A domain proven on either page counts once and is visible on both.
- DNS access: you must be able to add a TXT record at your DNS host.
How to
- Open Prove a domain (
/proof/domains) and add the domain. It is stored as Pending, with the record to publish. - At your DNS host, create a TXT record with the host name and value shown, using the copy buttons.
- Click Check now. A check can be run once a minute per domain. When the record is found, the domain becomes Verified, shown as proven by DNS TXT record.
- To stop proving a domain, remove it. That frees its slot and stops every check.
Answer levels
What a relying party sees next to your name when you answer its request:
| Level | What you need | What is shared |
|---|---|---|
| DNS-verified | A verified address in the request's domain, in a workspace that proved that domain by DNS TXT record. | Every line the request lists. |
| E-mail-verified (domain not proven by DNS) | The workspace confirmed the domain with a role-mailbox link (below). | Self-assessed and self-attested lines only. |
| Mailbox-verified | You are signed in with the exact, verified address the request was sent to (how a sole proprietor on a personal mail address answers). | Self-assessed and self-attested lines only. |
The two lower levels also need your membership in the workspace to be your own: you signed up, accepted an invitation or a join request, or confirmed a membership your company's single sign-on created. Measured lines (MFA enrolment, backups, e-mail authentication) are shared only at DNS-verified; below it the relying party sees them as not shared. The level is not inside the signed receipt: it describes how you proved who you are, so it is stored on the grant. If you prove the domain by DNS later, the daily check raises your grants to DNS-verified and delivers the measured lines it held back (only when the person who accepted the request is still in the workspace with a verified address at that domain; otherwise the grant keeps its level). Levels also go down, and never to one you have not earned at that moment: if a DNS proof lapses, a grant drops to E-mail-verified only while you hold a live role-mailbox proof of the domain, otherwise to Mailbox-verified; an E-mail-verified grant drops to Mailbox-verified when its role-mailbox proof expires or is removed, or when another workspace proves the domain by DNS. The relying party is alerted each time.
Prove it by a role mailbox
- On Prove a domain, under Or prove it by a role mailbox, pick a mailbox (admin@, administrator@, webmaster@, hostmaster@ or postmaster@), type the domain and choose Send link. security@ is not offered: it often feeds a public bug-bounty or ticket queue that outsiders can read, so a link there would prove little.
- Whoever reads that mailbox passes the link to you. Open it within an hour, signed in to this workspace as yourself, and choose Confirm the domain. The link works once, and only for the person who asked for it: anyone else who opens it, even a colleague in the same workspace, gets "not found".
- The domain is listed as E-mail-verified for 90 days. When it ends (or you remove it), grants you gave at E-mail-verified drop to Mailbox-verified at the next daily check, and the relying party is alerted; to keep them, send a new link before it ends, or publish the DNS record.
CMDash refuses the link, before sending anything, for a personal mail service (gmail.com and the like), a throwaway or shared-subdomain service, a name that is not public, and a domain that receives no mail (no MX record, or a lookup that could not get an answer). Your workspace may send 3 links a day for one domain and 10 in all; separately, any one domain receives at most 6 links a day from all CMDash workspaces together, so if others have been asking for the same domain you may have to wait a day (or publish the DNS record, which has no such limit). The workspace name and your address appear in the mail as plain text only: links, web addresses and markup are removed. Every refused request is recorded in your audit log. A role-mailbox proof never claims the domain for your workspace, is never used for scans, a Trust Center domain or single sign-on, and counts for nothing if another workspace has proven the same domain by DNS.
What keeps a proof alive
CMDash re-checks the record on its own: a pending or lapsed domain daily (so you do not have to come back and press Check now), and a verified one weekly. If a verified domain's record disappears, a 14-day grace period starts; owners and admins get an in-app notice on grace day 1 and day 10, and after the 14 days the domain lapses and stops counting as proven. Republishing the record re-verifies it. A check that could not get an answer (a timeout, a server failure) changes nothing: it never starts the grace period and never verifies a domain.
Common questions
Does a proof of a subdomain answer a request sent to the main domain? No. A request is matched to the exact domain you proved. Proving the main domain does answer requests sent to its subdomains; proving one subdomain does not answer a request sent to the main domain or to a different subdomain.
Is an e-mail address at the domain enough? Your own verified address is enough only for a request sent to exactly that address, and only at Mailbox-verified. For any other address at the domain the workspace needs a domain proof: the DNS TXT record (DNS-verified, every line shared) or a role-mailbox link (E-mail-verified, self-assessed and self-attested lines only). See the levels in Relying-Party Desk.
Why does this exist on Free when Domain Posture does not? The desk lets a Free supplier answer the company that asked, which needs a domain proof. Scanning stays on Essentials and above.