relay
Get started free

Data privacy

relay processes your message data only to deliver email and to show you
reports. The defaults follow one line: keep the data, keep it short, keep it
in Europe, and never build something on top of it. This page states what
relay runs, what relay stores, and what relay will not do.

Hosting

All relay services run on Hetzner, in the Falkenstein data center (fsn1) in
Germany:

Component Role Processes
Web dashboard and API Your browser and your OAuth sign-in Django web application behind a TLS-terminating reverse proxy
MCP server Message access for AI assistants FastMCP ASGI application behind the same reverse proxy
Authoritative nameserver DNS for your sender domains DNS proxy (dnsdist) and dnslib nameserver
SMTP submission Your message submissions aiosmtpd on 587 and 465
MX Inbound delivery on 25 aiosmtpd, STARTTLS
Task worker Asynchronous delivery, scans, webhooks Threadmill task runner
PostgreSQL Message metadata, org and domain state Postgres 18+
Redis Caching and rate limiting Redis
Object storage Raw message bodies S3-compatible bucket, behind a proxy that serves signed links
Spam and virus scanning Content filter rspamd with ClamAV, cluster-internal

No component of this stack belongs to a provider in a third country. relay’s
servers make no third-country data transfers. Location lookups run in your
browser, not on relay’s servers, and are described under Data flows.

The node’s first-boot configuration is stored with Hetzner as the server’s user
data, because that is how the node’s operating system receives it. That document
holds the cluster’s private keys, and Hetzner serves it back to anything running
on the node. relay treats the node as inside the trust boundary for its own
cluster credentials, and it accepts the risk deliberately: the alternative is a
hand-rolled install that gives up repeatable provisioning. See
Security for the full
limitation.

What relay stores, and for how long

Data Where How long
Raw message bodies Object storage Only for delivery, deletion after successful delivery
Message metadata PostgreSQL 30 days
Message headers (DKIM signatures, sender IPs) PostgreSQL With the retention of the message metadata
SMTP and webhook transcripts PostgreSQL, with the message With the message retention
DMARC, TLS-RPT, webhook-delivery records PostgreSQL With the retention of the message metadata
Suppression list PostgreSQL, salted SHA-256 hashes Until you remove the entry

The binding legal text is the privacy
policy. This table describes how the platform implements it.

What relay never stores

  • Plain suppressed addresses. A suppression entry is a salted SHA-256
    hash of the lowercased address. relay can compare, but not read back.
  • The message body inside webhook payloads. A delivery carries the event
    and a signed, expiring storage URL. The link grants read access to that one
    message for an hour. The body never travels inline.
  • Passwords. GitHub OAuth signs in, and relay stores no password at all.
  • API keys in plain form. The database holds prefixes and hashes. The
    plain key is visible once at creation.
  • Customer-supplied Feedback-IDs. relay replaces them with its own header
    at submission. The message does not carry your campaign identifiers.

Monitoring with boundaries

Sentry is off by default. When operators enable it, error reports contain no
message bodies, tokens, or credentials.

What relay does not do with your data

  • no profiling of your senders or recipients,
  • no data mining, no model training on your content,
  • no sale and no resale of message data.

Processing exists for delivery, for bounces, for reports, and for the
dashboards you use. Anything else requires an explicit product
decision, not a hidden default.

Data flows

  • GitHub OAuth provides your identity at sign-in. relay stores your
    GitHub identity and your email address, and requests the email addresses
    scope only.
  • Sending requires the platform to talk to receiving mail servers and to
    DNS resolvers. Delivery is the product.
  • IP location lookups happen in your browser. relay runs them when you
    open a transmission drawer that carries an IP address and when a DMARC
    report lists source IPs. Your browser sends those addresses to ipwho.is
    for an approximate location. Transmission drawers also load map tiles
    from OpenFreeMap. relay does not proxy these requests, does not store the
    result, and does not send message data to either service.
  • Reports come in from mailbox providers to the addresses your DMARC
    and TLS-RPT records name. relay parses them for your dashboards.

GDPR

relay operates under GDPR rules, and the platform design supports them:
EU-only processing, short storage, data minimization, and encryptions at
rest for secrets. For legal binding commitments, read the
terms of service and the
privacy policy, which also cover
your rights as a data subject.