Security

YeyMail sits between your real inbox and the internet, which means you are trusting us with something sensitive. This page describes what we actually do to deserve that — and, at the bottom, what we have not done yet.

Everything here describes the system as it runs today. Where something is planned rather than built, it is in the last section rather than dressed up in the present tense.

The strongest guarantee: there is no mail to steal

We do not store the content of your messages. Mail is relayed over an encrypted connection wherever the receiving server offers one, and the body is discarded the moment it is delivered. There is no archive of your email on our systems: nothing to breach, nothing to subpoena, nothing for an employee to read.

This is a structural property rather than a policy. Most email services have to promise they will not look at your mail; we do not keep it long enough for the question to arise.

What we do keep is delivery metadata: which alias received a message, when, and whether it was delivered, bounced or blocked. That is what powers your activity log and lets you spot an alias that has leaked. Per-message delivery records are kept 30 days and account activity 90 days, both pruned automatically.

Mail in transit

• TLS wherever the other end supports it, enforced where we can verify it. Everything inside our own systems is encrypted, and mail is accepted and relayed over TLS whenever the server at the other end offers it. For destinations that publish an enforcing MTA-STS policy and present a certificate chain our servers can verify, we require that verified certificate and will not fall back to plaintext. That is a specific list rather than every destination. A provider that publishes no policy, or publishes one only in testing mode, or serves a chain we cannot verify, stays opportunistic: encrypted whenever the far end offers it, but not enforced. Microsoft’s Outlook is in that last group today, because the chain it serves ends at a root certificate that current trust stores have dropped. Where we cannot enforce, we would rather deliver your mail than hold it.
• We publish our own MTA-STS and TLS-RPT records. Senders that implement MTA-STS can fetch our policy from mta-sts.yeymail.com and confirm they are really talking to our mail servers before handing over a message. It is currently in testing mode: a sender that finds a problem reports it to us and delivers anyway, so we can read those reports before making the policy binding. It does not yet stop anyone delivering to us in the clear. We will change this sentence when it does.
• Encryption is mandatory for sending. When you send as an alias, the server refuses to accept your credentials over an unencrypted connection at all — a misconfigured client fails to authenticate rather than quietly transmitting your password in the clear.
• SPF, DKIM and DMARC are published for our domains and applied to outbound mail, so recipients can verify that mail claiming to be from your alias genuinely came through us.
• Optional PGP. Add your public key and we re-wrap incoming mail as PGP/MIME before forwarding it, so the body of the copy that lands in your inbox is encrypted to a key only you hold — unreadable even to your own mail provider. As with all PGP/MIME mail, the subject line and the addresses stay readable.
• Webhook deliveries are signed. If you route alias mail to your own endpoint, every request carries an HMAC-SHA256 signature over a timestamp and the exact body, computed with a secret held only by you and us. Your server can prove a delivery genuinely came from us, that nothing was altered in transit, and that it is not an old delivery being replayed.

Your account

• Two-factor authentication is available, using any standard authenticator app. It applies however you sign in — including with Google — because a second factor is a statement about the account, not about which button you pressed. The shared secret is stored encrypted rather than in readable form, so a copy of our database on its own would not let anyone generate your codes.
• Recovery codes are single-use and stored only as hashes. We show them to you once, at the moment you create them, and cannot show them again. Using one to sign in sends you an email saying so, because if it was not you, nothing else would look unusual afterwards.
• Passwords are hashed with argon2id, a memory-hard algorithm designed to make large-scale cracking expensive. We cannot read your password, and neither could anyone who obtained the database.
• Session cookies are HttpOnly, Secure and SameSite=Lax, and carry a random identifier rather than anything about you. JavaScript on a page cannot read them.
• API tokens are stored hashed (SHA-256). A token issued to the browser extension exists in usable form only on your device — reading our database yields nothing you could authenticate with.
• Password-reset requests reveal nothing about whether an address is registered. The response is identical either way.

Separation between accounts

Every request for a resource is scoped to the account that owns it. Asking for another account's alias, domain, delivery log, usage data or suppression list returns “not found” rather than “not allowed” — we do not confirm that someone else's data exists, because that confirmation is itself a leak.

Ownership is checked in one place on every one of those routes, and a request for a resource the caller does not own is refused there rather than filtered later. We do not yet have an automated cross-account test suite; adding one is on the list below.

The kill switch is enforced below the application

When you switch an alias off, mail to it is rejected during the SMTP conversation itself — before a message body is ever transmitted. The sending server is told the address does not accept mail, nothing is queued, and nothing reaches our systems to be mishandled.

It works on every plan, including after a subscription lapses. Shutting down an address that is actively leaking is never behind a paywall.

Abuse and availability

• Sign-up is CAPTCHA-protected, and the check fails closed — if it cannot be verified, the sign-up is refused.
• Rate limits apply per address across the API, with tighter limits on authentication endpoints.
• Inbound mail is scored for spam, and you can have an alias disabled automatically when it takes a burst of spam.
• Repeated sign-in attempts from one address are rate-limited by the API, which starts refusing them long before a password could be guessed.
• Health checks run continuously against the live service and repair what they can, with the results on our public status page.

Addresses are never recycled

Once an address on our shared domain has received your mail, nobody else can ever register it — including after you delete it or close your account. We keep one content-free record that the address was used, purely so it cannot be handed to a stranger who would then start receiving your password resets. That record exists to protect you.

Your data, and leaving

Export and deletion are both self-service in Settings. Deleting your account disables every alias immediately, cancels any subscription, and purges your account, aliases, destination inboxes, domains and mail history. Two things survive: the non-reassignment record above, and — if we had already opened an abuse record against the account — that record and the IP address in it, detached from you, so that erasure cannot be used to clear a history and start again.

If you use your own domain, your addresses are portable by construction: point the DNS elsewhere and they keep working without us. We would rather you could leave easily than rely on you being unable to.

Card details never touch our servers. Payment is handled by Stripe on their own infrastructure; we see the card brand, last four digits and expiry, and nothing more. Full detail on data rights is on our GDPR page.

What we have not done yet

A security page that lists only strengths is not worth reading. These are real gaps, stated plainly, and this section will shrink as they are closed:

• No automated cross-account test suite yet. Tenant isolation is enforced in one place on every route, but it is not yet exercised by an automated test from a second account before each release.
• No third-party penetration test yet. Security work so far has been our own review and our own tests. An external assessment is planned rather than done.
• No formal certification. We hold no SOC 2, ISO 27001 or equivalent. If your organisation requires one, we are not the right choice today.
• No bug bounty programme. We will still take a report seriously — see below — but there is no formal payout scheme.

Reporting something

If you find a vulnerability, email security@yeymail.com. Tell us what you found and how to reproduce it. We will acknowledge within two working days and keep you updated until it is resolved.

Please give us a reasonable chance to fix an issue before disclosing it publicly, and please do not access, alter or retain other people's data while investigating — a proof of concept against your own account is always enough. We will not pursue anyone who reports a genuine issue in good faith.