Jordan sent 135 emails. Zero replies. No bounces. Then a stranger called him to say he'd been emailing a WeWork building for three weeks.
Jordan had been running the same sequence for three weeks with nothing to show for it. Not a low reply rate — a zero reply rate. Forty-five companies, three touches each, 135 emails delivered, zero responses. No bounces either, which was what confused him most.
A bounce would have been information. The clean delivery confirmations told him the system was working fine. He found out it was not working fine when a contact named Rachel called him directly.
"I received a forwarded message from my building management office at a WeWork in the Flatiron district asking if I knew who 'Jordan from FindScale' was and why he kept emailing admin@wework-flatiron-suite412.com. I almost reported it as spam."
Jordan thanked her, hung up, and pulled up the enrichment output for all 45 companies he had been sequencing. Every single one was registered to a shared workspace address. He had not been sequencing companies. He had been sequencing buildings.
A shared workspace domain contamination occurs when a resolution engine returns, as a company's primary operational domain, an address belonging to a co-working operator, incubator, or shared building infrastructure rather than the company itself. The returned domain passes every standard verification check — it is registered, it resolves, it accepts SMTP connections. None of that makes it the company's domain. It makes it the building's domain.
Jordan had not given the tool bad input. His list had been carefully built — startup-stage B2B SaaS companies in the 15-to-80 employee range, pulled from recent funding announcements and accelerator portfolios. That was precisely the problem.
Every enrichment tool resolves a company name by tracing available linkages: registration records, address databases, business directories. For a two-year-old startup operating out of a co-working space, the most complete, most recently updated record in those databases is often the address record — which links not to the company's domain, but to the operator's infrastructure at that address.
"The tool had not failed. It had faithfully returned what the available data said. The available data had described a building."
Jordan spent two hours sorting all 45 records — not into "right" and "wrong," but by how they were wrong. He suspected the fix was different for each type. He was correct.
The tool pulled a domain associated with the company's registered address — the co-working operator's domain for that building, sometimes with a tenant reference in the subdomain path. Every result traced back to a business registry record listing the company's address as a floor or suite within a WeWork, Regus, or similar operator. The tool found the most specific linkage available. The linkage led to the building, not the business.
These companies had legitimate standalone domains they owned — but the tool returned a vanity subdomain registered through their workspace operator at setup. Example: brightlane.spaces.io returned instead of brightlane.com. The company had migrated to their own domain, but the operator subdomain was still live in the address database. The tool found it first.
The tool returned what appeared to be the company's real domain — owned by the company, with an active website. But MX record lookups showed the mail exchange records pointed not to Google Workspace or Microsoft 365 but to a generic shared relay associated with an incubator. The email was arriving at a shared server. Nobody was monitoring the inbox it landed in.
A single fix would not work. A method designed for operator-domain cases would produce a different wrong answer on placeholder cases. Each mechanism needed its own resolution path.
Jordan bypassed address-linked data entirely and went to the one source companies maintain themselves: their LinkedIn company page. No company actively displays a co-working subdomain as its official web presence. The LinkedIn URL field is updated by the company's own team and almost always reflects their real domain. He pulled the LinkedIn page, copied the URL, ran a quick MX confirmation to verify active email infrastructure was configured there.
The resolution came from time — searching each company's name alongside their funding round or product launch to find the most recent public mention of their domain. The logic: a company still using a workspace operator's subdomain as their primary email address is not a viable SDR target yet. By the time a company appears in a list built from funding announcements, they have almost always migrated to their own domain. The press coverage revealed the correct current domain for all 15.
Jordan compared the hosting server against company-operated mail infrastructure. Three of the 10 had recently migrated their email to their own provider — those records were updated and ready to sequence. The other seven were still routing through shared infrastructure. Those seven moved out of the email sequence entirely and into a LinkedIn connection approach. Email to a shared relay was not going to reach anyone.
Five records remained after every method. All five were companies under 20 employees, all founded within the last 18 months, all still listed as residents of an accelerator or incubator. One had a domain registered but no MX records configured — it existed on paper but had no independent email infrastructure at all. These were not enrichment failures. There was no correct domain to find because the correct domain did not yet exist.
Jordan moved the five to a watch list and set a 90-day reminder. By then, companies at their stage would typically have left the incubator, registered their own domain, and set up their own email infrastructure. That was the moment to enrich them — not now.
The 45 corrected records that had delivered zero replies over three weeks produced three replies in the first week after the revised sequence launched. Not because Jordan had changed the message. Because the message was reaching a real company inbox for the first time. The building management office did not reply. The actual SDR managers at the actual companies did.
"The first corrected reply came from a company two addresses down from Rachel in the original WeWork building. Same building. This time Jordan had their real domain — and the person replied on the second touch."
FindCompanyDomain resolves company names to the domain the company actually owns and operates — filtering operator subdomains, shared infrastructure, and placeholder addresses before returning a result.
Shared workspace domain contamination occurs when an enrichment tool returns, as a company's primary domain, an address belonging to a co-working operator, incubator, or shared building — rather than the company itself. The returned domain passes every standard check: it's registered, resolves, and accepts SMTP connections. But it belongs to the building, not the business.
This happens because enrichment tools trace available data linkages. For startups operating out of WeWork, Regus, or an accelerator, the most complete record in address databases often points to the operator's infrastructure at that address — not the company's own domain.
Shared workspace infrastructure typically runs mail servers configured to accept incoming SMTP connections — either to route messages to tenants or simply to prevent NDRs (non-delivery reports). This means the mail server accepts your email, your sending platform confirms delivery, but the message routes to an unmonitored inbox or building management — never reaching your intended contact.
No bounce fires because, technically, the delivery succeeded. The failure is silent: confirmed delivery to an inbox nobody checks. This is why the pattern is so dangerous — it looks like a messaging problem when it's actually a domain quality problem.
Three checks reveal shared workspace contamination quickly:
1. MX record inspection: Run an MX lookup on the returned domain. Legitimate company email typically routes through Google Workspace (aspmx.l.google.com) or Microsoft 365 (mail.protection.outlook.com). A generic relay host, shared incubator server, or co-working operator MX record is a flag.
2. LinkedIn URL cross-check: Compare the returned domain against the company's LinkedIn page URL field. Companies maintain their own LinkedIn URL — they almost never display a co-working subdomain there.
3. Domain WHOIS registrant: Check who registered the domain. A domain registered to WeWork, Regus, or a known incubator operator — rather than the target company — confirms contamination.
The risk concentrates in lists targeting early-stage companies: Series A and pre-Series A startups, companies under 50 employees, companies founded in the last three years, and companies sourced from accelerator portfolios or incubator directories.
These companies are disproportionately likely to have co-working addresses in their business registry records, operator-issued vanity subdomains from their initial setup, or incubator-hosted email infrastructure they haven't yet migrated off. Any list built from funding announcements, accelerator portfolios, or growth-stage startup databases will have an elevated concentration of this pattern.
Operator subdomain contamination: The returned domain itself belongs to the co-working operator — e.g., company.spaces.io or a building address subdomain. The domain is real but the company doesn't own it or control its email infrastructure.
Shared MX relay contamination: The returned domain is legitimately owned by the company — correct website, registered in their name. But the MX records point to a shared relay server (often an incubator's or accelerator's mail infrastructure) rather than a company-operated mail provider. The domain looks right; the email routing is wrong.
The fix differs: operator subdomains require finding the real domain; shared-MX records require confirming the domain is correct but routing email elsewhere (e.g., LinkedIn outreach) until the company migrates to their own mail provider.
Basic enrichment tools typically cannot — they resolve company names to the most prominent linkage in available data, which for early-stage startups is often the address record pointing to operator infrastructure. The tool is not failing; it's correctly returning what the data says. The problem is in what data is available and weighted.
More sophisticated resolution systems — like FindCompanyDomain — specifically filter operator subdomains, shared infrastructure patterns, and placeholder addresses before returning a result, and run MX verification to confirm the returned domain has company-operated mail infrastructure rather than a shared relay.
LinkedIn outreach is the correct primary channel when:
MX records point to shared infrastructure: Email will route to an unmonitored shared relay. A direct LinkedIn message reaches the person.
The company has no independently owned domain yet: Email infrastructure hasn't been established. LinkedIn is the only reliably monitored channel.
The company has fewer than 20 employees and was founded within 18 months: At this stage, email infrastructure is often still transitional. LinkedIn engagement is frequently higher.
Email is the correct primary channel once MX records confirm the company operates its own mail provider (Google Workspace or Microsoft 365), and the domain resolves to a company-owned, company-operated address.
