RACKCRUNCH research | Stories we are following | September 27, 2026 DNS observations
TL;DR: We checked public email-authentication records for a fixed set of 7,024 directory-derived domains. The results describe public records in this selected set, not a national small-business rate or a test of real messages. The source data stays private so no business is singled out.
Email from a business domain carries the trust customers place in that business. Sender Policy Framework (SPF) and Domain-based Message Authentication, Reporting, and Conformance (DMARC) are Domain Name System (DNS) records that help tell receiving systems which senders are allowed and what policy the domain requests when authentication fails. DomainKeys Identified Mail (DKIM) adds a signature to actual messages. These records are a useful place to start checking your own setup.
Click here to see what this means for your business.
Why we checked
TL;DR: In this selected set, 44.76% of domains with a determinate policy-record response published a valid explicit policy at the tested name, 73.86% passed a limited sender-record syntax screen, and 40.25% had candidate signing-key material at a tested selector.
In the fixed 7,024-domain directory-derived cohort, 3,111 of 6,950 domains with a determinate DMARC answer (44.76%) published a valid record with an explicit policy tag at the exact _dmarc name tested. Of the same 6,950, 1,340 (19.28%) declared full p=quarantine or p=reject at that name. A missing explicit policy at that name does not necessarily mean the domain has no DMARC protection.
Of 6,960 domains with determinate SPF answers, 5,141 (73.86%) had one selected record passing a bounded top-level syntax screen. The screen did not follow recursive includes or redirects, check DNS budgets, cycles or void lookups, or test real mail. The outside panel reviewed all 34 historical conservative malformed decisions and all 428 targeted rows (427 accepted and one rejected) against the supplied derived records.
At ten tested DKIM selectors, 2,769 of 6,879 domains with determinate selector and control responses (40.25%) had implementation-compatible SubjectPublicKeyInfo (SPKI) candidate key material under the stated test. The panel confirmed that a literal Request for Comments (RFC) 6376 Public-Key Cryptography Standards #1 (PKCS#1) decoder found no qualifying keys in those decoded records; 1,468 candidates relied only on a multi-hop canonical-name (CNAME) lookup. RFC 6376's published text names RSAPublicKey; a reported erratum proposes SubjectPublicKeyInfo, consistent with deployed implementations. This study reports implementation-compatible SPKI material and does not adjudicate formal conformance. A key at one tested selector does not prove active signing, a valid signature or coverage of other selectors.
| Exact-name measure | Numerator / determinate denominator | Observed share | Conditional 95% Wilson interval |
|---|---|---|---|
| Valid explicit-p DMARC | 3,111 / 6,950 | 44.76% | 43.60-45.93% |
| Full declared DMARC quarantine/reject | 1,340 / 6,950 | 19.28% | 18.37-20.22% |
| SPF selected-record bounded top-level syntax screen (non-operational) | 5,141 / 6,960 | 73.86% | 72.82-74.88% |
| Tested-selector SPKI candidate material (not active signing) | 2,769 / 6,879 | 40.25% | 39.10-41.42% |
The intervals describe conditional variation among responding names in this selected frame. They do not account for directory age, selection, nonresponse, ownership changes, resolver behavior or parser uncertainty. They are not national margins of error, and the cohort is not a verified list of current US small businesses.
How this was measured
TL;DR: We counted exact-name DNS responses in a fixed directory-derived cohort, excluded uncertain responses from each measure, and preserved the designated capture privately. The analysis separates unanswered DNS queries from missing records.
A designated September 27 DNS capture queried mail exchanger (MX), apex text (TXT)/SPF, _dmarc TXT, ten named DKIM selectors and a random DKIM control for each of 7,024 selected hosts: 98,336 query slots. Collection spanned hours rather than one instant. DNS server failure (SERVFAIL) and query errors were left indeterminate, not called DNS absence. Current business status, employee size and the upstream complete directory frame were not independently verified. An RFC 9989-oriented DMARC parser ignored or defaulted malformed trailing/non-policy material in five rows; an all-or-nothing tag-list sensitivity yields 3,106 explicit-p and 1,337 full-policy rows rather than the primary 3,111 and 1,340. The primary counts apply only under the stated error-recovery rule. The earlier September 25 byte-preserved capture was lost; its surviving summary cannot be audited against missing original packet bytes or recreated from later DNS observations. The outside panel recomputed the displayed figures from decoded rows, but did not inspect the original packet archive. Packet-level correspondence remains unverified by that panel. The capture and its hashes remain privately preserved.
Data availability and independent reproduction
TL;DR: You can check the arithmetic, but not rebuild the source counts from public data. Named hosts, exact records and original packets stay restricted.
The restricted verification set contains named hosts and exact DNS TXT values. A scan of its decoded September 27 data found 1,888 query rows with email-like strings across 1,874 distinct hosts (1,851 DMARC rows and 37 SPF rows). Those values are retained only so a permitted reviewer can check the evidence accurately. Any audit copy would be restricted and could not be redistributed by named row. Retention, deletion and incident-handling terms still need confirmation before any further transfer. All company-level rows and raw packets are withheld from the public study to avoid pointing attackers toward a business or mailbox holder. No list of domains by measure is published; the study does not judge individual companies.
Readers can recalculate the percentages and Wilson intervals from the aggregates above. Readers cannot independently reproduce the cohort, DNS answers, per-host classifications or original counts from the public material. Removing just the 1,888 email-bearing rows from a public row-level file would leave incomplete query slots for 1,874 hosts; totals from that partial file would not be the reported study totals. No public row-level subset is planned. Controlled review of underlying evidence is separate from public data availability and is not promised here.
Technical standards: DMARC RFC 9989, SPF RFC 7208, DKIM RFC 6376 and RFC 8301.
What this means for your business
TL;DR: Run the public checker on your own domain, test an actual message, and ask your mail administrator before changing policy.
- See what your DNS says. Put your business domain into RACKCRUNCH's free SPF and DMARC Checker. It checks public SPF, DMARC and mail exchanger (MX) records and shows plain warnings about what DNS alone cannot establish. It does not test DKIM, real-message alignment or inbox placement.
- Check a real message. Send mail through each service your business uses and inspect the receiving mailbox's authentication results. Confirm SPF or DKIM passes and aligns with your From domain. Ask whoever manages your mail to review any failure before changing DNS.
- Tighten in steps. Inventory legitimate senders, fix their authentication, monitor DMARC reports if you use them, then consider a stronger policy when legitimate mail is passing. A rushed
p=rejectsetting can block your own mail. A publishedp=noneis a monitoring policy, not a request to reject mail.
The checker is a starting point, not a security grade. It cannot tell whether mail reaches an inbox. If a result is unclear, ask the person who runs your mail before changing a record.
Check where your domain stands, then verify actual mail with your provider before changing policy.