Data Residency Mode
Privacy tiers at a glance
EmailConnect minimises data exposure at every level. Each tier builds on the one before it.
| Tier | Plan | What EmailConnect stores | Where email is processed |
|---|---|---|---|
| Default | All plans | Full email, 1-hour retention | Shared EU node |
| Custom retention | Business+ | Full email, configurable window | Shared EU node |
| Data Residency Mode | Platform | Routing metadata only | Shared EU node |
| DRM + regional node | Platform | Routing metadata only | In-country node (e.g. mx-de) |
| DRM + dedicated node | Platform | Routing metadata only | Your own infrastructure |
- Default — content auto-deletes after 1 hour. Minimal exposure by design.
- Custom retention — set your own retention window. Delete records instantly via the
DELETE /api/v1/emails/{messageId}endpoint. Optional custom S3 for attachments. - Data Residency Mode — email content is parsed in memory and relayed directly to your webhook and S3 bucket. Never written to our database. Requires custom S3 storage.
- DRM + regional node — a geography-specific MX server (e.g.
mx-defor Germany) ensures email content never leaves the target country. For organisations where data transit through another jurisdiction is a concern, not just storage. - DRM + dedicated node — you operate the processing node on your own infrastructure or private cloud. We provide the container image and configuration. Full isolation.
Most organisations are well served by the default retention or custom retention tiers. Data Residency Mode and its regional options exist 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.
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.