Security

The short answer

Mailens encrypts every connection — your browser to our servers, our servers to the database, and incoming mail over SMTP. However, Mailens is not end-to-end encrypted (E2EE). This is the same security model used by Gmail, Outlook, Hey, Superhuman, and virtually every other email provider.

Your emails are stored encrypted at rest in our database and protected by authentication, but the server can technically access them — just like any standard email service.

“Can’t you encrypt with my wallet?”

This is a great question, and one we thought about carefully. Since every Mailens user has a Lens account with a wallet, it might seem natural to use wallet keys for end-to-end encryption. Here’s why that doesn’t work for an open email service:

• Email is an open protocol. Anyone on the internet can email your handle@mailens.xyz address — a colleague from Gmail, a newsletter from Substack, a receipt from Amazon. Those senders don’t have Lens wallets or encryption keys.
• Incoming emails were never encrypted to begin with. When Gmail sends you an email, it travels over standard SMTP. By the time it reaches our server, the content is already in plaintext. There’s no key to decrypt with because it was never encrypted end-to-end in the first place.
• Partial encryption creates a false sense of security. We could encrypt only Lens-to-Lens messages, but that would mean some emails in your inbox are E2EE and others aren’t — with no meaningful way for most users to tell the difference. That’s worse than being upfront about the model.

We’d rather be honest about what email can and can’t do than add encryption theater.

Encryption in transit — everywhere

Every connection in the Mailens stack is encrypted using TLS:

• Web app — HTTPS with modern TLS
• Inbound email (SMTP) — STARTTLS with TLSv1.3 and a Let’s Encrypt certificate
• Database connections — SSL encrypted
• Outbound email — sent via Resend API over HTTPS
• Realtime updates — HTTPS WebSocket connections

This means no one can eavesdrop on your data while it’s moving between systems. TLS is the backbone of internet security — it’s what protects your banking, your messages, and every secure website you visit.

Email authentication (anti-spoofing)

We use the full suite of DNS-based email authentication to verify that incoming emails are legitimate and that outbound emails from Mailens are trusted:

• SPF — verifies that emails come from authorized servers. Prevents attackers from sending emails that appear to come from @mailens.xyz.
• DKIM — cryptographically signs every outbound email with a 2048-bit RSA key. Recipients can verify the signature to confirm the email wasn’t tampered with in transit.
• DMARC — instructs receiving mail servers on how to handle emails that fail SPF or DKIM checks.

For incoming emails, our spam engine verifies SPF and DKIM records from the sender’s domain to detect spoofing attempts.

Access controls

• Wallet-based authentication — you sign in by proving ownership of your Lens account via a wallet signature or Orb login. No passwords to leak.
• Mailbox isolation — every database query is scoped to your Lens profile ID. There is no API endpoint that can access another user’s emails, contacts, or drafts.
• Session tokens — JWT stored in an httpOnly cookie (not accessible to JavaScript). Validated on every request.
• Rate limiting — tiered rate limits protect against brute-force attacks and abuse. Auth endpoints are limited to 10 requests per minute.

Spam protection

Every incoming email runs through a multi-layer spam scoring engine before it reaches your inbox:

• SPF and DKIM verification of the sender’s domain
• DNSBL / RBL lookup — checks the sender’s IP against known spam blocklists
• Content heuristics — pattern-based analysis of the email body

Emails that score above the spam threshold are automatically routed to your Spam folder. You can always review them and mark false positives as “Not Spam.”

What we can see (transparency)

We believe you should know exactly what the service can access:

• Email content — stored in our database (Supabase PostgreSQL). Anyone with database access can technically read it. This is true of Gmail, Outlook, and every non-E2EE email provider.
• Operational alerts — when an email is sent, we log the sender, recipient, and subject line to a private Discord channel for monitoring. Email body content is never sent to Discord.
• SMTP server logs — structured logging with privacy redaction. Email content is never written to log files.

For full details on what data we collect and how it’s used, see our Privacy Policy.

Attachments

Email attachments are stored on Grove, Lens Protocol’s decentralized storage layer. Once uploaded, files are immutable — they cannot be modified or tampered with. Uploads use TLS and are capped at 125 MB per file.

Infrastructure

• Web app — hosted on Vercel with automatic HTTPS and DDoS protection
• Inbound mail server — dedicated VPS in Helsinki (Hetzner) with STARTTLS and auto-renewing Let’s Encrypt certificates
• Database — Supabase (managed PostgreSQL) with SSL connections and encryption at rest

Looking ahead

We’re genuinely excited about the possibility of wallet-based encryption for Lens-to-Lens messages in the future. As the Lens ecosystem grows and more people communicate within it, E2EE for on-network messages becomes a real possibility worth exploring — without compromising the open email experience for everyone else.

For now, our focus is on getting the fundamentals right: transport encryption everywhere, strong authentication, spam protection, and full transparency about how your data is handled.