The EU Email Stack: Why Your DNS and Database Provider Matter Too

"Our email API is GDPR-compliant" is a sentence I see on every email vendor's marketing page. Some of them mean it. Most of them mean "the row that holds the email body is on an EU server." Those are not the same claim. If your DNS, your database backups, your Redis cache, or your bounce-processing webhook destination sits on a non-EU provider, your data residency story has the same number of holes as a Swiss cheese diagram.

This post is about what an honestly end-to-end EU email stack looks like, what usually leaks, and the specific architecture PostStack and HostStack run that closes those holes. It is the architecture post that follows from the GDPR buyer's guide: that one tells you what to look for, this one shows what it actually looks like when someone has built it.

The four places EU residency usually leaks

Walking down a typical "EU email API" with a real audit checklist, you hit four surfaces that almost every vendor handles loosely:

1. DNS provider. Every email vendor instructs you to add SPF, DKIM, and DMARC records to your domain. The DNS provider where those records live also resolves every name lookup your customers' email clients perform. Those lookups are personal data — they contain the recipient IP plus a timestamp. If your DNS is on Route 53, Cloudflare, or any other US-headquartered provider, that resolution metadata is in US-accessible infrastructure.
2. Database backups. Most managed Postgres providers offer "EU region" for the primary cluster. Fewer offer EU-only backup storage. Even fewer guarantee no replication metadata crosses borders. The backup is where the residency story most often breaks silently, because nobody looks at it until they're restoring.
3. Object storage for retained mail. If your provider's plan includes "logs for 90 days" and the underlying storage is S3, you've quietly sent every recipient's email address and message body to AWS. Even at S3 EU regions, the access plane is in US hands.
4. Operational tooling. Error tracking, log aggregation, CDN edge caching, status page hosting. Each one of these takes a slice of customer data to do its job. A Sentry on US infra, a Datadog on US infra, a Vercel deployment of the marketing site — all things your vendor probably uses, all things that can leak data your DPA promised stays in Europe.

The CLOUD Act bit covered in the GDPR post is the legal version of this point. This post is the architectural version: even with the right legal entity in the EU, the wiring still has to be right.

The PostStack stack, surface by surface

I'm using PostStack as the worked example because it's the stack I can publish configurations for without breaking anybody else's NDA. The point is the pattern, not the brand list. Substitute as you like — what matters is that each layer answers the residency question explicitly rather than by hand-wave.

Compute and storage

Bare-metal Hetzner boxes in Helsinki, Finland. Hetzner is a German company under German jurisdiction, with the EU data centre we use sitting under Finnish law. This is where the API runs, where Postfix and Dovecot run, and where the volume-mounted disks live. No US presence anywhere in the data path, no US sub-processor with access to the running instances.

Database and Redis

HostStack-managed Postgres and Redis, also Helsinki, also EU-jurisdictional. Same operator, same DPA. WAL streaming and Redis snapshots go to HostStack's backup layer, which itself is EU-hosted with no replication crossing the EU border. The full migration story is in the engineering post; the residency-relevant bit is that the database tier is explicitly EU end-to-end, not "EU region of a US provider."

DNS

HostStack PowerDNS, run in two anycast regions inside the EU. DNSSEC enabled. The resolver metadata — who looked up what, from which IP, at which second — never touches a non-EU surface. PostStack's customer-facing zones (and PostStack's own zones) all live on this DNS, and the integration that auto-publishes SPF/DKIM/DMARC records publishes them straight into it. Cloudflare's API offers similar automation on the technical side, but with US parent exposure that we wanted off the data path.

Object storage for logs and retained email

Hetzner Object Storage, EU region, S3-compatible API, German operator. Used for tombstoning email rows past the configured retention window and for storing parsed DMARC aggregate report XML. No AWS, no Azure, no GCS in the picture.

Observability

Self-hosted on the same Hetzner infrastructure. Loki for logs, Grafana for dashboards, Alertmanager for paging, Healthchecks.io's EU mirror for cron heartbeats. The single non-EU thing in this layer is the Grafana frontend's static JS, which is served from a CDN — the actual data never leaves the EU box. PostStack doesn't use Sentry or Datadog, not because they're bad products but because both would re-introduce US data flow for trivial benefit.

Marketing and dashboard frontends

Bun + Nginx on the same Hetzner cluster. The marketing site, the docs, the blog, and the dashboard SPA are all served from EU infrastructure. We don't use Vercel, Netlify, or Cloudflare Pages for the public site. They're great products; they're also US companies. For a product whose entire pitch is "no US infra in the path," putting US infra in the path of the public-facing site would be embarrassing.

The honest tradeoff

This whole architecture has costs. A CDN-fronted Vercel deployment would make the marketing site marginally faster outside Europe. Sentry's UX is genuinely nicer than the Loki + Grafana combo. Cloudflare's anycast DNS is faster on the furthest-away resolvers than a two-region PowerDNS setup. None of those tradeoffs is severe, and all of them go in the EU-residency direction by design.

Where it matters: a customer using PostStack to send health, finance, education, or legal correspondence — the categories where data residency is not a marketing bullet but a contractual obligation — can answer "where does the data live?" with a single jurisdiction. No follow-up questions, no asterisks about CDN edges or backup replication or DNS providers, no "EU region of US service" hand-wave.

What to ask your current provider

If you want to test your own stack against this bar, here's the short list. It's deliberately specific enough that vague answers fail it.

1. Where is the DNS that hosts the SPF/DKIM/DMARC records you require? What is the parent jurisdiction of that DNS provider?
2. Where are the WAL backups and snapshot archives of the primary database stored? Same region as the cluster? Same provider? Same legal entity?
3. What object storage holds retained message bodies and attachments? Is it accessible from non-EU jurisdictions by your operator's staff, or only the hosting provider's?
4. What does your sub-processor list look like? Are error trackers, log aggregators, CDN providers, and status page hosts included? Are any of them US?
5. If a US legal process targeted your parent company tomorrow, which of the above would be in scope?

Most providers can answer the first one. Fewer answer the second cleanly. Almost nobody answers all five without "well, technically" qualifications. The set of providers that does is small, EU-headquartered, and tends to run their own infrastructure end to end. PostStack is one. There are others; ask them the same questions and pick the answer you like.