Why compliance pages matter (DPA, sub-processors, hosting, imprint)

I'm Sebastian, CTO at ReceiveHQ (Cortena B.V.). Use-case #7 — the last in this series: after fan-out, filters, anti-spam, retries, and German baremetal, the question procurement actually asks — where are the pages I can send to legal?

The problem

Topics 2–6 made the pipeline useful. None of that closes a security review if the buyer has to chase you in email for a DPA, a sub-processor list, a hosting declaration, or an imprint. For German legal, tax, healthcare, and similar customers, "we'll send the PDF later" is not a posture — it is a delay.

We built ReceiveHQ because we were tired of shipping European data through American infrastructure. Cortena already runs self-managed baremetal Kubernetes with a short, mostly European subprocessor list. Postmark inbound was a pragmatic compromise for years. When outbound/dunning forced consolidation, we wanted inbound that matched the rest of the stack — and public trust pages you can open without asking.

The four pages (and what each one answers)

These are not marketing footnotes. They are the documents a DPO or vendor-risk team expects before a trial becomes a production MX.

What the DPA actually covers

The public DPA (/dpa) is incorporated into the ReceiveHQ customer agreement. Highlights that matter in a review:

• Processor role — Cortena B.V. processes Customer Personal Data only on documented instructions (the agreement + your endpoint config)
• Purpose limit — inbound reception, MIME parse, storage, webhook/blackhole delivery, console, support. No training AI models on your mail
• Security — TLS in transit, encrypted volumes at rest, private German K8s, MFA for production, CIDR-restricted SMTP, optional Basic auth on webhooks
• Retention — operational MinIO raw .eml / delivery logs: 14-day window unless otherwise agreed
• Breach notice — without undue delay, and in any event within 72 hours of awareness
• Sub-processors — authorised list at /sub-processors; ≥30 days written notice before add/replace; objection path
• Transfers — core mail and application data stay in Germany / the EEA; no unauthorised transfers outside the EEA without prior written consent
• Governing law — Netherlands; Amsterdam courts
• Contacts — compliance@cortena.ai · DPO Sharon Klaver (dpo@cortena.ai) · signed DPAs on request

Sub-processors vs your webhooks

Core hosting is Hetzner Online GmbH (Germany). Where you enable DNSRBLs, Abusix may see connection metadata only (sender IP/domain) — not mail content. Your configured webhook destinations are under your control; they are not Cortena subprocessors. Pointing a webhook at a US SaaS is a hop you justify, not one we hide.

Why this cut of the story matters

The canonical spine is unchanged: tired of EU data via US infra → Cortena baremetal K8s + short EU subprocessors → Postmark inbound compromise → finance-critical mail forced consolidation → no great EU inbound at sane price → ReceiveHQ (custom domains, multi-endpoint fan-out + filters, anti-spam, MCP agent inbox).

Compliance pages are how that spine survives a vendor questionnaire. Hosting says where. The DPA says under what rules. Sub-processors say who else. The imprint says who signs.

Setup sketch (for the security review, not just the MX)

1. https://receivehq.com — magic-link sign-in
2. Domain + MX → mx.receivehq.com, verify
3. Endpoints + filters / anti-spam as in prior posts
4. Send legal: hosting · DPA · sub-processors · imprint
5. Signed DPA / AVV: compliance@cortena.ai · DPO: dpo@cortena.ai

Series wrap

1. Agent inbox (MCP / blackhole)
2. One domain → prod + staging webhooks
3. Recipient filters (support@ vs invoices@)
4. Anti-spam before webhooks fire
5. Retries, resend, multi-endpoint
6. German baremetal — what stays in the EU
7. This post — why the compliance pages matter

Try: https://receivehq.com · €10/mo or €100/yr · 100k inbound · first 10 free

Disclosure: I work on ReceiveHQ as CTO & Co-founder of Cortena B.V.