your-email.eu
PlatformOwn nodeShared nodesDevelopersCompliance
Log inRequest access

GDPR compliance

Last updated: 2026-09-02

your-email.eu is built for organisations that must know where their mail goes and who can see it. This page sets out, in plain terms, how the service maps onto the General Data Protection Regulation: the roles, the data, the locations and the retention periods. The Data processing agreement is the binding version of the same facts.

Contents

  1. Roles
  2. Where data is processed
  3. What we hold, by how a message is submitted
  4. Retention
  5. Security measures
  6. Sub-processors
  7. Data subject requests
  8. Getting the agreement

1Roles

  • Your organisation is the controller of the personal data in the mail it sends: recipient addresses, subjects, bodies, headers.
  • [Legal entity name] is the processor for that data, acting only on your instructions — which are the settings you make in the console and the requests you send to the API.
  • [Legal entity name] is the controller for the data of the people who use the console (accounts, sessions, configuration) and for access requests; the Privacy policy covers these.

2Where data is processed

The console at app.your-email.eu, its database, backups and every shared sending node run in data centres inside the European Union, operated by [Hosting provider of the console and shared nodes, EU data centres]. No mail data is processed outside the Union, and no sub-processor outside the Union has access to it.

With your own node, the sending node runs on your infrastructure, wherever you place it. Mail it delivers never passes through ours.

3What we hold, by how a message is submitted

Three paths exist and they differ in what reaches the console. The same organisation may use all three.

  • Submitted through the API (POST /api/v1/messages), in either mode: the console stores the message record — sender, recipients, subject, custom headers, text and HTML body — so it can hand the message to a node and retry if that node is down. It also stores the message's status, the node that took it, its queue id, any error and the timestamps.
  • Submitted over SMTP directly to your own node: the console never receives the content. The node queues and delivers the message on your infrastructure, and ships to the console only the delivery events described below.
  • Submitted over SMTP to a shared node: the message sits in the node's queue on our infrastructure until it is delivered or bounced, and is then removed from the queue. The console receives only the delivery events.

Delivery events are the node's log lines for each message: timestamps, queue id, sender and recipient addresses, the remote server's response and the resulting status. Nodes also send periodic status reports — hostname, version, queue depth — with no message data in them.

4Retention

  • Delivery events: deleted 30 days after they are recorded.
  • Node status reports: only the 100 most recent reports per node are kept.
  • Message records submitted through the API, including their content: kept for as long as the organisation exists, unless a shorter period is agreed in the order form. Deleting the organisation deletes them.
  • Deleted data: purged from live systems within 30 days and from backups within a further 90 days.

5Security measures

  • TLS on every connection to the website, console and API; per-destination TLS policies (opportunistic, required or DANE) for mail in transit.
  • API keys, SMTP credentials and node tokens shown once and stored hashed; keys scoped to abilities and optionally to a single sender; every key and credential revocable at any time.
  • A domain may send only after the console has verified an ownership TXT record and its DKIM key, so mail cannot be sent from a domain the organisation does not control.
  • Role-based permissions inside each organisation decide what each member may see and change; API keys carry only the abilities they were given.
  • Tenant isolation enforced in the application for every query; a node authenticates with its own token and cannot name a tenant on its own.
  • Production access limited to the operators of the service; backups encrypted at rest.

6Sub-processors

The Data processing agreement lists the sub-processors and the notice period for changes. For mail data there is currently one: [Hosting provider of the console and shared nodes, EU data centres]. Cloudflare serves the marketing website only and sees no mail data.

7Data subject requests

Requests from recipients of your mail (access, erasure, objection) go to your organisation as the controller. The Messages log lets you find every message to a given address. Deletion of message records and their events is done on request to privacy@your-email.eu, within 10 working days; there is no self-service delete yet. If a request reaches us directly we forward it to you and, where you ask us to, assist within the terms of the Data processing agreement.

8Getting the agreement

The Data processing agreement is part of the Terms of service and applies from the moment your organisation is created. A countersigned copy, and the completed annexes for your organisation, are provided during onboarding; write to privacy@your-email.eu for either.

your-email.eu

Email sending for organisations. Own node or shared nodes, hosted in the EU.

Product

PlatformOwn nodeShared nodesDevelopersComplianceFAQAlternatives

Developers

API docsLog inhello@your-email.eu

Legal

GDPR compliancePrivacy policyTerms of serviceData processing agreement
© 2026 your-email.euHosted in the European Union