Data Residency Mode
Privacy-conscious by default
Before diving into Data Residency Mode specifically, it's worth noting that EmailConnect is designed to minimise data exposure at every tier:
- Free and Maker plans default to 1-hour retention — email metadata is automatically deleted within an hour of processing. There is very little to expose in the first place.
- Business and Platform plans open up the
DELETE /api/v1/emails/{messageId}endpoint, allowing you to programmatically delete email records as soon as your workflow has processed the webhook delivery. This can reduce your data exposure window to under 5 seconds. - Platform plan adds Data Residency Mode — the subject of this guide — which ensures email content is never stored in our database at all.
Each tier builds on the previous one. Most organisations are well served by the short default retention. Data Residency Mode exists for those with jurisdiction-specific requirements that go beyond retention policies.
What is Data Residency Mode?
Data Residency Mode is an opt-in feature for Platform plan users that ensures EmailConnect never stores email content (body, attachments, headers) in its central database. Content flows through memory to your webhook endpoint and your own S3 storage — only routing metadata is retained by EmailConnect.
This is designed for organisations in regulated industries (finance, healthcare, legal, government) that need email content to remain exclusively within infrastructure they control.
How it works
Standard mode (default)
In standard mode, EmailConnect stores the full parsed email in its database for the duration of your configured retention period. This enables features like payload preview in the dashboard, replay of previously delivered emails, and manual retry of failed deliveries. After the retention period expires, all stored content is automatically and permanently deleted.
Even in standard mode, the default retention is deliberately short — 1 hour for Free and Maker plans, 24 hours for Business and Platform — so the exposure window is minimal by design.
Email arrives → Parsed → Stored in DB → Delivered to webhook
↑ ↓
Retained for configured Replay available
period, then auto-deleted during retention
Data Residency Mode
With Data Residency Mode enabled, email content is parsed in memory and delivered to your webhook. The full payload is never written to the central database. Only a metadata summary is stored for operational purposes.
Email arrives (TLS) → Parsed in memory → Delivered to webhook (HTTPS)
↓
Metadata summary stored (no content)
All data flows are encrypted in transit — email ingress uses STARTTLS, webhook delivery uses HTTPS, and S3 uploads use HTTPS. Content is never written to disk on EmailConnect's infrastructure.
What EmailConnect retains
When Data Residency Mode is enabled, the following routing metadata is stored in the central database:
- Message ID — for deduplication and delivery tracking
- Recipient address — identifies which alias handled the email
- Subject line — for log readability (can contain PII; see note below)
- Timestamps — processing and delivery times
- Delivery status — pending, delivered, failed, rejected
- Attachment summary — filename, content type, and size for each attachment (not the attachment content)
- Spam score and classification — for filtering metrics
- Domain and alias identifiers — internal routing references
What is NOT stored
- Sender address — not stored in the database or metadata payload
- Email body — neither plain text nor HTML
- Attachments — neither content nor binary data
- Email headers — except the message ID
- Any content-derived fields — markdown conversion, link extraction results, integrity hashes
A note on subject lines
Subject lines are retained as operational metadata because they make the delivery logs usable. A log showing only message IDs and timestamps is difficult to work with. However, subject lines can contain PII (e.g. "Invoice for John Smith"). If this is a concern for your compliance requirements, we recommend discussing this with your DPO.
Storage connection security
Custom S3 storage credentials are encrypted at rest using AES-256-GCM with a per-installation salt before being stored in the database. EmailConnect never stores your S3 access keys in plain text.
Geographic routing with MX servers
The architecture
EmailConnect can operate regional MX (mail exchange) servers across the EU. When you configure your domain's MX records to point to a specific regional server, all email processing for that domain happens on that server. The email content is parsed, delivered to your webhook, and stored in your S3 bucket — all within that geography.
The central database (Hetzner, Germany) receives only routing metadata. No email content from your users reaches the central database.
Available regions
| Region | Server | Availability |
|---|---|---|
| Germany | mx-de |
On request |
| Netherlands | mx-nl |
On request |
| France | mx-fr |
On request |
We provision regional MX servers based on customer requirements. Contact us to discuss your geographic needs — setup is typically completed within days.
Additional regions under consideration based on demand:
| Region | Availability |
|---|---|
| United Kingdom | On request |
| Poland | On request |
| Finland | On request |
| Spain | On request |
If your organisation requires a specific EU country not listed above, contact us — we can evaluate adding a regional node for your jurisdiction. On-premise deployment is also available for organisations that need to run the processing node on their own infrastructure.
What stays where
| Data type | Location | Persistence |
|---|---|---|
| Email content (body, attachments) | Regional MX server (memory only) → your webhook + your S3 | Transient on MX; permanent in your infrastructure |
| Routing metadata | Central database (Hetzner, Germany) | Until configured retention expiry |
| Delivery logs | Central database (Hetzner, Germany) | Until configured retention expiry |
| Audit logs | Central database (Hetzner, Germany) | Configurable (default 90 days; Platform can extend) |
| Financial records (invoices) | Central database (Hetzner, Germany) | 7 years (Dutch legal requirement) |
Encryption in transit
All data flows between components are encrypted:
- Email ingress — SMTP with STARTTLS from the sending mail server to the regional MX server
- Webhook delivery — HTTPS from the MX server to your endpoint
- S3 uploads — HTTPS from the MX server to your S3 bucket
- Internal metadata — encrypted connection from MX server to central database
At no point does email content touch disk on EmailConnect's infrastructure. It is parsed in memory, delivered over encrypted channels, and discarded.
Why this matters
A Platform customer using mx-fr can guarantee to their regulators that email content never leaves France — provided their S3 bucket and webhook endpoint are also hosted in France. The only data that reaches Germany is operational metadata needed for delivery tracking and billing. This metadata contains no sender addresses, no email body content, and no attachments.
This architecture enables compliance with jurisdiction-specific requirements without requiring EmailConnect to operate entirely separate infrastructure per country.
Sovereignty tiers
Data Residency Mode is the foundation for a broader range of sovereignty options:
| Tier | Description | Availability |
|---|---|---|
| Data Residency | Metadata-only central DB. Content stays in your S3 and webhook. You choose the MX region. | Available now |
| Regional Node | EmailConnect-operated processing node in your country. We manage it; you get guaranteed locality. | Contact us |
| Dedicated Node | Customer-operated node on your own infrastructure or private cloud. You manage it; we provide the image and configuration. | Contact us |
All three tiers build on the same principle: the central database is content-free, so it doesn't matter where the processing node runs. The difference is who operates the node and where it's hosted.
Requirements
- Platform plan with the
compliance.data_residencypermission - Custom S3 storage connection — Data Residency Mode cannot be enabled without an active custom (non-platform) S3 connection, because attachments need somewhere to go
- S3 must be configured before enabling Data Residency Mode; the last custom S3 connection cannot be deleted while DR mode is active
Trade-offs
Enabling Data Residency Mode disables certain features that depend on stored content:
| Feature | Standard mode | Data Residency Mode |
|---|---|---|
| Webhook delivery | Full payload | Full payload (unchanged) |
| Dashboard payload preview | Available | Unavailable (content not stored) |
| Replay previously delivered emails | Available | Unavailable |
| Manual retry from dashboard | Available | Unavailable |
| Delivery logs | Full detail | Metadata only |
| GDPR data export | Excludes payload (by design) | Same — metadata fields only |
The webhook delivery itself is identical — your endpoint receives the same full JSON payload regardless of mode. The difference is only in what EmailConnect retains after delivery.
Enabling Data Residency Mode
- Ensure you have an active custom S3 storage connection in Settings → Storage
- Go to Settings → Compliancy
- Toggle Data Residency Mode on
- Confirm the trade-offs
The change takes effect immediately for all new emails. Existing email records are not modified.
DPA coverage
When Data Residency Mode is enabled, the downloadable DPA from your Compliancy settings automatically includes a Section 2a addendum that reflects the reduced data scope. This addendum:
- Documents that email content is not stored by the Processor
- Lists the specific metadata fields that are retained
- Transfers responsibility for content storage to you as the Controller
- Notes the operational limitations (no retry, no payload preview)
You do not need to request a separate DPA — the generated document adapts to your current settings.
Questions?
For compliance questions about Data Residency Mode, regional nodes, or on-premise deployment, contact enterprise@emailconnect.eu or your dedicated Platform support contact.