DMARC `p=reject` is measurable at the DNS layer. Whether the organization fully manages authenticated email is a much broader, mostly unobservable question.
Define the exact unit of measurement
The DMARC record published at _dmarc.example.com gives a receiver policy for a particular organizational domain and relevant subdomain handling. A measurement report must decide how it treats domains with no valid record, syntactically invalid records, temporary lookup errors, subdomain-specific policy and multiple invalid competing TXT entries.
Research status: no real SecuTest adoption percentages or population sizes are claimed. The goal is to specify a sound calculation before any chart or comparison is published.
Separate observed policy values
A basic analysis might group valid domain records by p=none, p=quarantine and p=reject. A fourth group captures no valid record after reliable lookup. Other tags such as pct, sp, rua and alignment settings add important nuance.
dig +short TXT _dmarc.example.com
Do not treat a DNS timeout as absence. Retry according to a documented protocol, preserve the error and remove failed lookups from denominators only when your methodology explicitly says so.
Do not confuse enforcement with effectiveness
A p=reject tag is a stronger published request to receivers than p=none. It does not establish that all sending sources align, that reports are monitored or that a vendor operates the deployment. A p=none record may be appropriate during legitimate inventory and rollout phases. Avoid ranking companies from "secure" to "insecure" based on the policy string alone.
| Public observation | Narrow conclusion |
|---|---|
Valid p=none |
Monitoring-mode policy is published |
Valid p=quarantine |
Quarantine is the published receiver policy |
Valid p=reject |
Reject is the published receiver policy |
| No valid DMARC detected | No valid record observed during the defined lookup process |
Report denominators and sampling bias
Define whether the population contains active mail domains only or all sampled company domains, including domains not intended to send mail. Explain how you selected the companies and how regional or industry coverage could distort the result. Provide collection dates and DNS parser versions.
Turn aggregates into responsible MSP guidance
A strong report can identify segments where authentication implementation services may be worth researching. It cannot identify individual buyers' budgets or implementation priorities. For account-level qualification, use Scan Prospects, and for available domain segments explore Find Leads. Any published statistics should be accompanied by a reproducible extract and explicit limitations.
Example denominator definitions
Two valid studies can produce different results from the same raw DNS collection. One may calculate "domains publishing p=reject as a share of all active corporate domains sampled." Another may calculate "domains publishing p=reject as a share of domains with syntactically valid DMARC records." They measure different things, and neither fraction should be presented without its denominator.
When reporting progress over time, keep the domain population stable or clearly document additions and removals. Otherwise an apparent change in enforcement rate can be caused by importing a new domain source. Review DNS errors and record-validity rules before attributing a trend to company behavior. These methodological details are necessary before the data can responsibly guide MSP territory selection.
Turn infrastructure signals into a qualified prospect list.
Analyze domains you already know, or find new companies that match the technologies you target. Public DNS observations support discovery, not proof of an internal security weakness.