StackCheck: Data sovereignty scanner
StackCheck scans a website's DNS, hosting and embedded scripts, then those of every service it finds, to show where its data actually flows and under which jurisdiction.
By Xander Groesbeek, founder · Published February 2026 · Updated October 2026 · 4 min read
In brief
The issue. Privacy policies say "GDPR compliant" but rarely say whether a service runs on AWS, uses a US DNS provider or sends support tickets through a US helpdesk. Server location is not legal jurisdiction.
What it means for you. To know where your data goes, you have to look at the infrastructure itself, including the services your vendors rely on.
What to do.
- Scan your own domain and your key vendors at stackcheck.eu.
- Look at the infrastructure layer first: one non-EU host outweighs everything else.
- If you own a site, verify your listing to correct the automated result.
The problem: marketing pages don't show the infrastructure
While building EmailConnect I kept asking the same question about every service I evaluated: where does my data, and my users' data, actually go?
Privacy policies say they "take data protection seriously". None of that tells you whether a service runs on AWS in Virginia, uses Cloudflare for DNS or routes support tickets through a US-headquartered helpdesk. And a company can host in Frankfurt on AWS and still fall under the US CLOUD Act. The only way to know is to look at the infrastructure. That is what StackCheck does.
How a scan works: three phases, then recursion
StackCheck takes a domain and analyses it in three phases.
| Phase | What it checks | What it finds |
|---|---|---|
| 1. DNS | DNS records, SPF includes, verification records | Email infrastructure and services disclosed in DNS |
| 2. Infrastructure | IP geolocation, ASN ownership, CDN detection, TLS certificate issuer, subdomains | Who actually hosts the service, as the servers report it |
| 3. Content | Third-party scripts and tracking pixels on the homepage, privacy policies, sub-processor pages | Analytics, chat widgets, payment processors and other embedded services |
Then it scans every third-party service it found in the same way. That shows when an EU-based service runs on non-EU cloud infrastructure underneath: a chain is only as strong as its weakest link.
Scoring: weighted layers, worst result counts
Every service lands in one of four layers, weighted by how sensitive the data it handles is.
| Layer | Weight | Examples |
|---|---|---|
| Infrastructure | 3x | Hosting, servers, CDN, TLS certificates |
| Backend services | 2x | Email, payments, auth, databases, monitoring |
| Frontend and third-party | 1x | Analytics, tracking, widgets, embedded content |
| Disclosed services | – | Services named in privacy policies |
Each service gets one of three statuses: EU (company and infrastructure in the EU), EU Hosted (non-EU company on EU infrastructure) or Non-EU. Within a layer the worst result counts, so one non-EU service in a critical layer can't be averaged away by five EU ones.
Why "EU Hosted" is not "EU"
A US company can run servers in Frankfurt, so your data sits in the EU physically. But under the CLOUD Act, US authorities can compel a US-headquartered company to hand over data wherever it is stored. The legal exposure differs, so StackCheck keeps the two apart.
Grades: A++ to F, with hard caps
Scores map to letter grades. The top two grades are for verified listings only: site owners who have confirmed or corrected the automated result.
| Grade | Score | Meaning |
|---|---|---|
| A++ | 95–100 | Verified EU-sovereign (verified listings only) |
| A+ | 90–94 | EU-sovereign (verified listings only) |
| A | 80–89 | Strong EU posture (highest grade without verification) |
| B | 70–79 | Mostly EU, some concerns |
| C–D | 40–69 | Mixed, significant non-EU dependencies |
| F | 0–39 | Non-EU infrastructure at critical layers |
Hard caps stop good scores elsewhere from hiding a fundamental problem: any non-EU infrastructure caps the score at 35 (F), non-EU backend services at 55 (D), and non-EU frontend services at 75 (B).
Detection signatures are open
The patterns StackCheck uses to recognise services in DNS records, HTML and network data are public domain (CC0) and hosted on Codeberg. Anyone can add a pattern for a service StackCheck doesn't detect yet.
Why I built it
StackCheck started as a tool for myself. When I chose services for EmailConnect, I needed to check that the whole stack, every third-party dependency and not just my own servers, met the EU standard I promise customers. Privacy policies and marketing pages weren't enough, so I built the analysis, then realised others could use it too.
How EmailConnect fits
StackCheck is a separate side project, but it grew out of the questions behind EmailConnect's own setup.
- Every company that processes your email is listed, with its location and the data it handles. Sub-processors →
- Processed in the EU. Hetzner in Germany for the application, database and mail server; Scaleway in France and the Netherlands for optional attachment storage and backups. No US company is in the processing chain, apart from optional sign-in with Google or GitHub. Security →
- Changes announced 30 days ahead, so you can object before a new sub-processor is used. Data Processing Agreement →
- The whole stack, written up, including where I made compromises. The European tech stack in 2026 →
Related
The European tech stack in 2026
European alternatives at every layer, from hosting to payments to monitoring.
2025: The sovereign cloud reality check
Microsoft's CLOUD Act answer, the ICC and Airbus: what changed in 2025.
The hidden GDPR trap
Why server location alone does not make a service compliant.
Sub-processors
Who handles your data when you use EmailConnect, and where.
StackCheck is a side project by the founder of EmailConnect. It is built independently and doesn't share any data with EmailConnect or any other service.