data-brokersdelete-actdroptrustccpa

We Wrote to the Data Brokers Using the Addresses on California's Own Registry. Here Is What Came Back.

Ben TobinUpdated 6 min read

Over the first days of September we did something unglamorous. We took the contact addresses that data brokers themselves published on California's registry, and we wrote to them.

Not a scrape. Not an estimate. Actual messages to actual published addresses, with every bounce body read by a person rather than inferred from a subject line.

33 of the companies we contacted had no working email path.

That number is the headline, and on its own it would be unfair. So here is the breakdown first, before the interesting part.

The honest arithmetic

15 bounced. The mail server refused delivery: the mailbox does not exist, the domain cannot receive mail, the address rejects outside senders, or the mailbox is full or retired.

18 replied to say email is not a channel they accept. They run a web form, or a phone line, or a ticketing queue, and they told us so — several of them politely and immediately. This is not a failure. A company is entitled to choose its intake channel, and a monitored web form is arguably a better privacy channel than an inbox. Six of those eighteen publish a toll-free number, which for a deadline is the fastest confirmable route there is.

So of the 33, 31 are reachable by some route. A portal, a phone line, a ticket queue, or a replacement address they handed us themselves. Three companies simply wrote back with the correct address, which is exactly how this is supposed to work.

If you came here for a story about an industry hiding from consumers, that story is not in this data. Most of these companies are contactable. Some were helpful.

The two that are different

Two published addresses cannot receive mail at all. Not "prefer another channel" — cannot.

One sits on a domain that does not exist. The lookup returns NXDOMAIN: there is no such domain, anywhere. The spelling is a transposition of an ordinary English word, the kind of typo anyone makes once. It was filed, and published, and nobody caught it.

One publishes a Null MX record. RFC 7505 defines this: a domain owner sets it to declare, formally and deliberately, that the domain accepts no mail. This is not an outage or an oversight. It is a configuration someone chose. There is no email path to that company, and there was never going to be.

We are not naming either one. This is a field report about a system, not an accusation against two companies, and a typo does not deserve a pillorying. Both were reported through the appropriate channel.

Why two addresses matter more than thirty-three

On 3 September the California Privacy Protection Agency issued Enforcement Advisory 2026-01, concerning incorrect information in data broker registrations. The advisory is about the accuracy of what brokers file.

What we have is what that question looks like from outside, measured rather than asserted.

A registry of data brokers exists so that a consumer, a regulator, or a journalist can find and contact them. That is its function. When a published contact point cannot receive a message, the entry still looks complete — there is a company name, a domain, an address in the right format. Nothing about the row signals that it is inert. You only discover it by writing, and waiting, and reading what comes back.

A right you cannot exercise through the published channel is thinner than it appears on paper. Not absent. Thinner.

And the check is cheap. An MX lookup and a domain resolution take milliseconds and could run at the moment of filing, the way any signup form validates an email address before accepting it. Neither of the two defects we found would have survived that check.

What this means if you are trying to reach a broker yourself

  • If you are in California, use DROP first. One verified request reaches every registered broker, and none of the above applies to it — DROP is a state platform, not a company inbox. Everything in this article concerns the separate problem of contacting a specific company directly.
  • Expect the web form to be the real channel. For a large share of brokers it is, and it is often better: it timestamps your request and gives you a reference.
  • A phone call is a monitored channel. If a company publishes a number, it produces a dated reference faster than email will.
  • A bounce is information, so keep it. The bounce body names the reason and the reporting server. If you ever need to show you tried, that is the evidence.
  • Do not assume silence means refusal. In our data, most silence had a mundane explanation: the wrong channel, a closed group, a full mailbox.

Frequently asked questions

Which companies are you talking about?

We are not naming them. The point of this piece is a systemic one about registry accuracy and contact channels, and naming individual companies over a typo would obscure that rather than support it. Anyone can reproduce the method described here against the public registry.

Is a broker breaking the law if its published email address bounces?

That is a legal question and not one we answer. What we can say is what we observed: certain published addresses could not receive mail on the dates we wrote. Whether any particular entry violates any particular requirement is for the agency and for counsel.

Is refusing email non-compliance?

No, and we would push back on anyone who framed it that way. Choosing a web form or a phone line as the intake channel is a legitimate operational decision, and 18 of our 33 did exactly that and said so clearly.

How did you verify the two unreachable addresses?

Standard DNS. One returns NXDOMAIN, meaning the domain does not resolve at all. The other resolves and publishes a Null MX record per RFC 7505, the formal way to declare that a domain accepts no mail. Both checks are public and repeatable by anyone.

Does this affect my DROP request?

No. DROP is a platform operated by the state; brokers retrieve requests from it. The contact addresses discussed here are for reaching a company directly, which is a separate route with separate problems.

Disclosure

I run Sirveil, a small California company whose service determines whether a named individual's information is publicly indexed at a named website at a given moment, and reports that observation as INDEXED, NOT INDEXED, or INDETERMINATE. We do not verify that anyone complied with anything, and we do not audit or certify anyone. Index presence is not proof that a deletion request was ignored, and index absence is not proof that data was deleted.

The messages described here were commercial outreach — we were writing to these companies about our own business, and the deliverability data is a by-product of that. I would rather say so plainly than dress it up as a study. It is a field report from a company with an interest, and every number in it is one we can produce the receipts for.


Method: messages sent 3–4 September 2026 to contact addresses published on the California data broker registry. Every classification was read from the actual bounce or reply body, not inferred from a sender or subject line. DNS checks performed 4 September 2026. Counts as of 6 September 2026.

NONE OF THIS CONSTITUTES LEGAL ADVICE. The author writes as a commercial party with a disclosed interest, not as counsel. Whether any registration entry meets any legal requirement is a question for the agency and for your own counsel.

Share this article

PostShare

Get privacy insights delivered

No spam. Unsubscribe anytime. We send one email per week with new guides and data broker news.

Start protecting your personal data

Scan, verify, remove: Sirveil finds where brokers list you, you confirm which entries are yours, and your takedown requests are prepared, transmitted, and chased on your behalf — tracked end to end.

Get Sirveil

Available now on the App Store and Google Play.