Trust

Security at Rykon Mail

Email holds a company’s most sensitive conversations. This is how we protect it, written from what the service actually does, with nothing claimed that the code does not prove.

Last reviewed
30 October 2026
Data location
Germany
Report a vulnerability
support@rykonmail.com

Signing in

Who you are is checked by our own identity service. What you may do is decided on our servers, on every request.

Our own identity service

Sign-in runs on an identity service we host ourselves. Rykon Mail’s website never sees your password: it receives a signed token, verified against the service’s published keys, using PKCE, state and nonce checks.

Passkeys and two-step sign-in

Sign in with a passkey, and add an authenticator app or passkey as a second step. A new account works only after its email address is confirmed, and repeated failed attempts from one source are turned away.

Short, sealed sessions

A session is sealed with AES-256-GCM into a cookie limited to one host, HttpOnly, Secure and SameSite=Lax. It lasts at most 12 hours, whatever the browser does.

Staff access is narrow

The operator console needs an internal account, a confirmed email address and an allowlist. A customer typing a staff address into their profile gets nothing.

Architecture

The parts that can change customer mail are not on the public internet, and the browser holds nothing that could reach them.

A private control plane

The service that provisions domains, mailboxes and sending is reachable only over our private network. The public consoles talk to it from the server, never from your browser.

No keys in the browser

Every console operation is its own named server route that checks the session first. There is no generic proxy, and no control plane key ever reaches a browser.

Writes must come from our site

A request that changes anything is refused unless its Origin is the console itself, as well as the cookie’s SameSite protection.

Hardened containers and headers

Services run as a non-root user. Our pages refuse to be framed by other sites (except hosted sign-up forms, which exist to be embedded), and send nosniff, referrer and permissions policies.

Keys and credentials

What we do not keep cannot leak. What we must keep is sealed to the record it belongs to.

API keys shown once

A key holds 256 random bits and is shown exactly once. We store only its SHA-256 hash and compare in constant time, so a database copy cannot produce a working key. Keys carry only the scopes they need; an agent’s key reaches its own mailbox and nothing else.

Sealed credentials

A DNS provider token you connect is encrypted with AES-256-GCM and bound to its own record, so it cannot be moved to another account. Disconnecting destroys it.

Mailbox passwords are never stored

A mailbox password exists only in the response that sets it. The one exception is an AI agent’s mailbox, which no person signs in to; its password is sealed the same way.

Nothing secret in the audit log

Passwords, tokens and keys are redacted from audit records whatever a caller passes in.

Sending and reputation

Each customer sends as itself. One account’s problems cannot reach another’s mail.

Ownership first

A domain is configured nowhere until its ownership record is seen at the domain’s own nameservers.

A sending identity per customer

Each customer’s mail leaves through Amazon SES under its own verified identity, configuration set and credential, which may send only as that customer’s domains, with its own rate limit.

Automatic stops

Bounce and complaint rates are read continuously. An account that crosses the threshold has its sending stopped before it can harm anyone else’s delivery.

One-click unsubscribe

Every campaign and automated email carries a standard one-click unsubscribe header and link, effective at once and never tracked.

Abuse prevention

Protection that does not track the people it protects.

Proof of work, not a CAPTCHA

Public sign-up forms are protected by a small calculation the visitor’s browser does while they type. Challenges are signed, bound to one form, expire in 30 minutes and are accepted once. No third-party script, no cookie.

Generous throttles

Public forms and each API key are rate limited, generously enough that a person is never locked out, with an overall ceiling against floods.

No way around consent

Transactional mail sent through the API never goes to an address that bounced or complained, and to someone who unsubscribed only account, security, receipt or order mail; a message that reads as selling is refused.

AI with limits

AI features receive only what the task needs, never contact lists. The instructions the model follows are fixed on our servers, each account has a daily allowance, and generated studio text is cleared after 90 days.

Records and recovery

What happened is written down where it cannot be rewritten, and the data can be brought back.

Append-only audit log

Every change is recorded with who made it and the outcome. The database refuses to alter or delete an audit record, even for its owner.

Replicated database

The database runs on two servers in two German data centres, one a synchronous standby of the other.

Encrypted offsite backups, tested

Backups are encrypted before they leave our servers and stored offsite. The whole database cluster is restored from them once a month to prove they work.

Data in Germany

Servers, databases and mail storage are at Hetzner in Germany. Our subprocessors page lists everyone else and where.

What we do not claim

Rykon Mail does not hold SOC 2, ISO 27001 or any other certification today, and has not been through an external audit. We will say so here when that changes, and not before. Our data processing addendum sets out how customers can review our measures in the meantime.

Reporting a vulnerability

If you believe you have found a security issue, write to support@rykonmail.com with “Security” in the subject, and give us a reasonable time to fix it before telling anyone else. Please do not access other people’s data, disrupt the service or send mail as part of your testing. We will not take action against research done in good faith under these rules.