35 chamber domains, read on one day. Here is everything we found.
On 3 September 2026 we read the published SPF and DMARC records of 35 domains, straight from public DNS. They were chosen as candidate United States chamber-of-commerce and business-association domains from their names alone. This page is the whole result — the counts, the checks, the method, the parts where we found nothing, and what we did not verify. No organisation is named on it and none ever will be.
What the 35 domains publish.
What we did not verify, said before the numbers. We did not confirm, domain by domain, which organisation is behind each of these 35 names. Doing that means reading each organisation’s own website, and for this dataset we read none of them — every figure here comes from DNS alone. So read “chamber domain” here as “a domain we selected as a likely chamber or association domain”, and nothing stronger. A separate, smaller set of 21 domains whose organisations we did confirm is summarised on the front page; these 35 are not that set.
A DMARC record tells a receiving mail server what to do with a message that claims to come from the domain and fails authentication. p=none is not a fault — it is the monitoring setting the standard is designed to start at. We report what is published and nothing further.
| Published DMARC policy | Domains | Share |
|---|---|---|
| No DMARC record at all | 7 | 20% |
p=none — monitoring only | 14 | 40% |
p=quarantine | 9 | 26% |
p=reject | 5 | 14% |
Enforcing (quarantine or reject) | 14 | 40% |
| Published SPF | Domains |
|---|---|
| Publish an SPF record | 29 |
| Publish none | 6 |
Of the 29, share whose SPF path runs through the two include: targets of a single mail-platform vendor | 15 (52%) |
That last row is the one we did not expect. Half of the domains that publish SPF at all hand the same vendor a place in their mail path. We name the vendor nowhere, and we checked its own records before saying anything about it: they expand to address literals only and cost one lookup each. The defects below are in the customers’ records, not the vendor’s.
13 of the 35 carry something quotable. 22 carry nothing these checks find.
15 findings across 13 domains. Each check is named with the clause it evaluates, so anyone can disagree with us by reading the standard rather than by trusting us. 8 of the 14 domains that set an enforcing policy carry at least one.
| Check | Clause | Found |
|---|---|---|
| SPF over the evaluation limit The record needs more than ten DNS-querying terms to evaluate. The standard says an implementation MUST return permerror when that happens, so the record stops authorising anything. This is the only class here that is a live breakage rather than a posture. | RFC 7208 §4.6.4 | 1 |
| SPF close to the limit Eight or nine of the ten terms already used. Nothing is broken today. It means the next vendor added to the record is likely to break it, and whoever adds it will not be told. | RFC 7208 §4.6.4 | 3 |
| SPF void lookup An include: that points at a name publishing no SPF record. The standard recommends receivers cap these at two; the term is spent either way. | RFC 7208 §4.6.4 | 1 |
| Soft-fail under an enforcing policy The SPF record ends ~all, which asks receivers not to reject on that basis alone, while the DMARC record asks for quarantine. An inconsistency between two published statements, not a breakage: DMARC alignment governs the outcome. | RFC 7208 §8.5 with RFC 7489 §6.3 | 2 |
Enforcing policy applied to a fractionp=quarantine published together with a low pct. The policy the domain appears to set is applied to that percentage of failing mail and no more. | RFC 7489 §6.3 | 1 |
Subdomains exemptedsp=none under an enforcing p. The subdomain tag overrides the policy tag for every subdomain, so the enforcement stops at the bare domain. | RFC 7489 §6.3 | 1 |
| Enforcing with nowhere to report An enforcing policy with no rua. Mail is being acted on and nobody receives the aggregate reports that would say which mail, or whose. | RFC 7489 §6.3, §7.2 | 2 |
| No mail exchanger published The domain publishes a DMARC or no-DMARC posture but no MX record. We record it because it changes what any of the rest means, not because a standard is broken. | not an RFC defect | 4 |
What we are not saying. Only one of these 15 findings is a live mail breakage: the domain whose SPF record needs eleven lookups against a published limit of ten. The rest are posture and change-risk. We have not tested anyone’s mail, we have not attempted to forge a message and we would not, and we make no claim at all about DKIM.
Every external reporting address in the set is properly authorised.
When a domain asks for its DMARC reports to be sent to an address at some other organisation, RFC 7489 §7.1 requires the receiver to look for a record at <domain>._report._dmarc.<destination> confirming the destination agreed to it. Where that record is missing, the reporting address MUST be ignored — the domain would be publishing a report destination that no receiver may use.
21 reporting addresses are published across 35 domains; 15 of them point outside the publishing organisation. All 15 are authorised, every one through a wildcard record at the report processor. Zero defects in this class. We publish that because a measurement that only ever finds faults is not a measurement.
How this was taken, in enough detail to be repeated.
Public DNS only
Every figure comes from DNS-over-HTTPS queries for TXT, MX and _dmarc names. No website was crawled for this dataset. No organisation was contacted. Nothing was sent to anyone’s mail server.
Two resolvers, and only a definite answer
Every name is asked on two independent public resolvers. Only NOERROR and NXDOMAIN count as answers; a server failure is retried up to eight times and recorded as unresolved if it never clears, never as an absence. An early pass of ours once read four domains as publishing no SPF; three of them publish one perfectly normally.
Tags are parsed, not matched
A DMARC record is split on ;, each part on its first =, tag names lowercased, and the first occurrence of a repeated tag governs. A record counts only if its v tag reads DMARC1. Where a name carries more than one qualifying record, the policy is recorded as none, which is what §6.6.3 says a receiver does.
SPF terms counted, not guessed
include, a, mx, ptr, exists and redirect each cost one lookup, and nested ones count against the same budget of ten. Each vendor include was expanded recursively and its own querying terms counted.
Counted three times
The policy split was tallied from the recorded dataset, then re-measured live on both resolvers on the day this page was published. All three passes agree on all 35 domains. An earlier draft of this page carried a split that was wrong by one domain; it was caught by this recount and never published.
35/35 agreementNobody is named
No chamber, no association, no member business and no vendor appears on this page, whatever we found. Publishing a list of organisations with defects is pressure, not reporting.
and it will stay that wayRead your own domain, or ask us for your rows.
Our reader takes a domain name and shows you its published DMARC and SPF records with the same checks applied — free, no sign-up, and it names no organisation but the one you type.
If you run one of these 35 domains and want to know whether any row above is yours, email rjhsignaltech@gmail.com and we will send you your own rows privately, free, whether or not you ever pay us anything.