Transparency
Security and delivery
What we do so email arrives, arrives intact and reaches only whom it should, and where the limits still are. Every item below is in the mail server’s code.
Encryption in transit (TLS)
- Incoming (port 25): we offer STARTTLS with TLS 1.2 or 1.3 and a Let's Encrypt certificate. As on every mail server, a sender that does not use TLS can still deliver.
- Sending (port 587): STARTTLS is required before the login; without it, the server does not accept the password.
- Delivery to the destination: we use STARTTLS whenever the destination server offers it, as Gmail, Outlook and the big providers do, and try to verify the certificate first. If the destination requires TLS through its MTA-STS policy, the message only goes out encrypted and with a valid certificate; without that requirement, we prefer the encrypted connection over plain text even with a certificate that does not match. Details in Delivery to other domains.
- Dashboard and API: HTTPS only.
MTA-STS and TLS-RPT
MTA-STS tells other servers that your MX accepts TLS with a valid certificate, which makes intercepting the connection harder. Our own domain publishes its policy (in testing mode) and receives TLS-RPT reports. For your domain, the dashboard shows an mta-sts CNAME and two TXT records: we serve the policy with a certificate issued for your name only, and TLS-RPT reports go to an address on your domain. It is optional.
Delivery to other domains
When delivering a message, we check whether the destination domain publishes an MTA-STS policy (RFC 8461). We fetch it from https://mta-sts.<domain>/.well-known/mta-sts.txt, cache it for the time it states (max_age) and fetch it again when the id in the _mta-sts TXT record changes.
- Policy in
enforcemode: we deliver only to the MX hosts the policy lists, with mandatory STARTTLS and a valid certificate (a trusted chain and the MX name). If that fails, the message does not go out in plain text: it stays in the queue and we retry; after 5 days without success, the sender gets the bounce. - Policy in
testingmode: we deliver as if there were no policy and record, internally, when it would have failed. We do not send TLS-RPT reports to the destination yet. - No policy (most domains): STARTTLS whenever the destination offers it, trying to verify the certificate first. If verification fails, we still deliver encrypted, without verifying: that is opportunistic TLS, the norm for email on the internet. Plain text only when the destination does not offer STARTTLS.
- DANE (TLSA records): not enforced yet.
The log of each delivery says whether TLS was verified, not verified or absent.
DKIM, with two-phase rotation
- Each domain has its own 2048-bit RSA key. The private key is encrypted in the database (XChaCha20-Poly1305) and signs what you send through port 587.
- Rotation without losing email: when you rotate, the new key gets another selector, but the current one keeps signing. Only when the new key’s TXT shows up in your DNS does it start signing; the old TXT stays in the dashboard for 7 more days, because an already signed message may still be retried.
SPF, DMARC, ARC and SRS
- Incoming, we check every message’s SPF, DKIM and DMARC and honor
p=reject. - On your domain, SPF includes our server (
include:), and you can publish DMARC; the DMARC report reader is free and runs in your browser. - ARC: we seal every forwarded message with the platform key, so the destination sees the original authentication passed.
- SRS: the envelope sender is rewritten when forwarding, so SPF passes at the destination and bounces go back to whoever sent.
Anti-spam
rspamd runs on our server and gives each message a score; each domain picks the level:
| Level | Refused from | Marked as spam from |
|---|---|---|
| Lenient | 20 | 10 |
| Normal | 15 | 6 |
| Strict | 10 | 4 |
The filter can also be turned off. A message marked as spam does not go to channels (webhook, Telegram).
Plan limits
Each plan has a ceiling of messages per day (per month on the free plan), of destinations per address and of summaries per hour on channels (60 per channel). Above the daily limit, incoming email gets a temporary deferral and the sender’s server retries later; sending through port 587 is refused until the next day. The limits exist so that a compromised account cannot harm the others. Each plan’s numbers are on the plans page.
Accounts and isolation
- Dashboard passwords in bcrypt; SMTP passwords in argon2, shown only once, at creation; API tokens stored only as a hash. Optional two-factor login.
- An SMTP credential only sends as addresses of its own domain.
- Each team only sees its own data, checked twice: in the dashboard and in the mail server.
Where the server is
On a dedicated Hetzner server in Finland (European Union): the mail server, the database, the queue and the log are on it, with a daily backup. The other companies that handle data (DNS, billing, the dashboard’s emails) are in the subprocessor list of the Privacy Policy.
Status and incidents
The status page checks the MX, the sending SMTP, the dashboard and the MTA-STS policy every minute, shows 90 days of uptime and the forwarding time, and lists the incidents. The checks run on the server itself, so a full outage of it shows up as missing data, not as red; whatever we learn some other way becomes an incident.
Frequently asked questions
Is email encrypted in transit?
Whenever the other side accepts it. We offer STARTTLS (TLS 1.2 or 1.3) for incoming mail and require it on the sending SMTP, port 587. When delivering we use STARTTLS whenever the destination server offers it, as the big providers do, and try to verify the certificate first.
Do you honor the destination domain’s MTA-STS?
Yes. If the destination publishes an MTA-STS policy in enforce mode, we deliver only to the MX hosts it lists, with TLS and a valid certificate; if that fails, the message does not go out in plain text: it stays in the queue and we retry for up to 5 days. In testing mode, or without a policy, we deliver with opportunistic TLS. DANE is not enforced yet.
Do I need to set up MTA-STS?
It is optional. If you want it, the dashboard shows one CNAME and two TXT records: we serve your domain’s MTA-STS policy with its own certificate, and TLS-RPT reports reach the address you choose.
Where are the servers?
On a dedicated Hetzner server in Finland (European Union). The database, the queue and the log are on it.
How do I change the DKIM key without losing email?
With the Rotate DKIM button: the new key only starts signing once its TXT shows up in your DNS, and the old TXT stays in the dashboard for 7 more days.
How do I know if the service has a problem?
On the status page, which checks the MX, the sending SMTP, the dashboard and the MTA-STS policy every minute and lists the incidents.
Want to try it with your domain? The free plan needs no card. Create a free account