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 encrypted connections 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 on every hop we control. Mail arrives, is processed, and leaves over encrypted connections.
• 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 copy that lands in your inbox is encrypted to a key only you hold — unreadable even to your own mail provider.
• 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

• 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.
• Sign-in does not reveal whether an account exists. A wrong password and an unknown address produce an identical response, as do password-reset requests, so the login form cannot be used to test whether someone has an account here.

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.

This is tested against the running system rather than assumed: each of those paths is exercised from a second account and must be refused before a release ships.

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 failed sign-ins from an address are blocked at the network level.
• 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 — with the single exception of the non-reassignment record above.

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:

• Backups sit with a single provider. The database is dumped nightly, and our infrastructure provider takes automated system-level backups held separately from the running machine — so losing the host does not lose the data. What we do not yet keep is a copy with an unrelated provider, which is what would cover the rarer case of losing the account or the vendor itself.
• No third-party penetration test yet. Security work so far has been our own review and testing against the running system. 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.