Subprocessors
Last updated: 3 August 2026
This page is what makes our sovereignty claim checkable. It lists every third party that processes data on our behalf when you use Postvow, with the role it plays, where it processes, and what it can see. It is kept consistent with Annex 3 of the Data Processing Agreement — if you ever find the two disagreeing, the DPA governs and we want to hear about it at privacy@postvow.com.
The claim we make is narrow and we state it in its narrow form: Postvow adds zero email-content subprocessors beyond the single EU data-centre operator that hosts the mail infrastructure. No third-party email service provider, no US relay, no deliverability or analytics vendor sees the content of your messages. We do not claim that no third party is involved at all, and we do not claim that no metadata ever touches a non-EU company — neither statement would be true.
Sovereign Core — every customer, always
| Provider | Role | Processing location | What it can see |
|---|---|---|---|
| Hetzner Online GmbH | Infrastructure and data-centre operator for the mail production host | Germany (EU) | This is where email content is processed: message bodies, headers, recipient addresses, DKIM signing and delivery logs all live on infrastructure operated by this provider. It is the only email-content subprocessor. |
| Cloudflare, Inc. | Authoritative DNS, static hosting for this website, and the authenticated tunnel to the operator console | United States (a US entity; edge nodes worldwide) | DNS query metadata, HTTP request metadata for this website, and the transport of authenticated console sessions. It does NOT terminate TLS for email: the mail records (api, mail) are DNS-only, not proxied, and that is enforced mechanically by our infrastructure configuration rather than left to convention. Because this is a US company, it is in scope of the US CLOUD Act — we name that rather than omit it. |
Optional modules that add a subprocessor
A second optional module can also add a subprocessor, independent of eIDAS above: Microsoft-inbox fallback, a per-tenant opt-in relay used only for messages to Microsoft-hosted recipients when direct delivery underperforms. It is OFF by default for every tenant, and no subprocessor beyond the two backends listed below is ever added; a tenant that activates the module selects exactly one of them, and only that backend is added to that tenant's Annex 3.
| Provider | Role | Processing location | What it can see |
|---|---|---|---|
| Qualified trust service provider (to be named) Roadmap — not built | eIDAS qualified timestamps for delivery evidence — ROADMAP, not built, not available today | EU (a provider on the EU Trusted List) | Would receive a cryptographic hash of a delivery record for timestamping — never message content. The specific provider will be named in Annex 3 before the module ships, with prior notice and a right to object. |
| Sendinblue SAS (Brevo) Conditional — only for customers who activate this module | Microsoft-inbox-fallback relay — one of the two backends for the optional module described above | France (EU) | Recipient email metadata, subject line, message body and custom headers, for messages routed through this backend only. Added as a subprocessor only for a tenant that turns the module on and selects this backend; it sees nothing for any tenant that does not. |
| Scaleway SAS Not yet available — pending DPA and supplier approval | Microsoft-inbox-fallback relay — the alternative backend for the same optional module | France (EU) | Would see the same categories as the Brevo backend above, for messages routed through it. Not offered to any tenant today: its Data Processing Agreement and supplier risk assessment are still pending. |
This website
postvow.eu is a set of static files with no cookies, no analytics and no third-party requests, served by Cloudflare (already listed above). Serving these pages therefore adds no subprocessor beyond the one named in the Sovereign Core table. Under the DPA we notify customers before adding a new subprocessor and give them a right to object — that is a contractual commitment under Article 28(2) GDPR, not a courtesy, and it applies to changes to this page as much as to changes to Annex 3.