---
title: "Security · Proxy Mail QA"
description: "How Proxy Mail QA handles your data and test passwords end to end: test accounts only, AES-256-GCM encryption for saved passwords, row-level security between projects, retention, and what isn’t built yet."
url: https://proxymail.qa/security
---

Security

# Security is important to us.

Here’s what happens to your data from sign-up to an expired inbox: what we store, how test passwords are encrypted, who can see what, and what isn’t built yet.

Updated 13 October 2026 · Covers the app, the API and MCP server, and Proxy Mail QA for Chrome

## Test accounts only

Proxy Mail QA is for development, staging, preview and QA testing of apps you build or are allowed to test. Its addresses are disposable and are deleted when they expire. Don’t use them for production or personal accounts, and never use or save a real or personal password. Use the strong passwords Proxy Mail QA generates, or a password you made up for testing.

## The short version

### Inboxes are ours, never yours

Test addresses are created by Proxy Mail QA on its own domains. You can’t connect a personal mailbox, and a password can’t be saved for any email that isn’t one of ours.

### Receive-only

Nothing is ever sent from a test address. Mail to an address that doesn’t exist or has expired is refused.

### Everything expires

Addresses last up to 30 days. Their mail, codes, links and saved passwords are deleted with them.

### Test passwords are encrypted

AES-256-GCM in our API, with a key that never sits in the database. A database leak alone doesn’t reveal them.

### Projects are walled off

Postgres row-level security on every table, with an isolation test suite that runs on every change.

### Agents get the code, not the email

Scripts and AI agents receive only the code or link and a few facts about it, never the email’s text.

## End to end: from sign-up to an expired inbox

1. You create a Proxy Mail QA account.  
With your own email and a password, or with Google. You confirm your email before you can create test addresses. Cloudflare Turnstile checks sign-up, sign-in and password reset for bots.
2. You create a test address in a project.  
A random or custom name on one of our receiving domains, optionally with a fictional name and username and a generated password for the form.
3. You sign up to the app you’re testing with it.  
By hand, with the Chrome extension, or through the API or an AI agent.
4. That app’s email arrives.  
Cloudflare Email Routing hands it to our receiving service, which first checks the address exists, is live and is within its size and rate limits. Anything else is refused at the door.
5. We extract the code or link and clean the rest.  
The verification code or link is extracted, the HTML is sanitised and attachments are dropped. The original email file is kept only if the project has debug mode switched on.
6. It appears in your project.  
Live, for the people on that project. You copy the code or click the link yourself: Proxy Mail QA never opens or prefetches links, so single-use links still work.
7. The address expires.  
An hourly cleanup deletes expired addresses with their mail, codes, links and saved passwords. The name is retired and never issued again.

## Passwords

There are two kinds, and they’re handled differently.

| Question        | Your Proxy Mail QA password                                        | Saved test-account passwords                                                              |
| --------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------- |
| What it is      | The password you sign in to Proxy Mail QA with                     | The password a test account uses on the app you’re testing                                |
| Where it’s kept | Supabase Auth, as a one-way bcrypt hash                            | Our database, as AES-256-GCM ciphertext                                                   |
| Can we read it? | No. Only the hash exists.                                          | Only through our API, when someone on the project asks to see it. Every reveal is logged. |
| Rules           | At least 8 characters. Use a password you don’t use anywhere else. | Only for Proxy Mail QA addresses. Never a personal or reused password.                    |

### How saved test passwords are protected

- **Generated strongly.** Generated passwords are 16 characters of upper- and lower-case letters, digits and symbols, from the platform’s cryptographic random generator. In the Chrome extension they’re made on your device and fitted to each field’s rules.
- **Encrypted with a key the database never has.** Encryption happens in our API (a Cloudflare Worker) with AES-256-GCM. The 256-bit key is stored only as a Cloudflare secret, not in the database or the code, so someone with a copy of the database sees only ciphertext.
- **Bound to one address.** Each ciphertext is tied to its address and label, so it can’t be copied onto another address and decrypted there.
- **Reuse is spotted without revealing anything.** A keyed fingerprint (HMAC-SHA-256, with a key derived from the main one) lets QA reports flag one password used on several addresses without showing it.
- **Revealed only on request.** Only people on the project can reveal one, at most 30 a minute per person, and every reveal is written to the project’s activity log. API keys can’t read saved passwords unless they were created with that permission, and AI agents connected by sign-in never can.
- **Only on our addresses.** The database refuses to save a password for any email that isn’t an existing Proxy Mail QA address in a project you’re on. Your personal email, and its password, can’t be stored here, from the app, the API or the extension.
- **Your own test password is fine.** If you type a password you invented into a sign-up form with one of our addresses and choose to save it, that’s the one saved. Just don’t make it one you use anywhere real.
- **Left out of reports by default.** QA reports include saved passwords only when you tick the option, and they disappear from the screen when you untick it.

## Your account and sessions

- Sign-in is handled by Supabase Auth: email and password with confirmation, or Google. Cloudflare Turnstile protects sign-up, sign-in and password reset.
- A Proxy Mail QA account can’t be created with one of our own test addresses, so nobody can make accounts that confirm themselves. The database enforces this for every sign-up route and for email changes.
- The web app sends strict security headers: a Content-Security-Policy that only allows our own scripts plus Turnstile and Stripe’s checkout, HSTS, no referrer, and no framing by other sites.
- Signing out, or signing in as someone else, clears everything the app had loaded for the previous account.
- You can delete your account in Account settings. Its addresses, mail and saved passwords are deleted straight away.

## Test addresses and the mail they receive

- Addresses are only ever created by Proxy Mail QA, on our receiving domains (mailclub.dev and enable.li). There’s no way to add an existing mailbox or forward personal mail in.
- For each email we store the sender, subject, plain text, sanitised HTML, the extracted code or link, and timestamps. Attachments are not stored. Emails over 5 MB are refused, and each address and account has rate limits.
- The original email file is kept only when a project has debug mode on, in Cloudflare R2, and is deleted with its email (with a 31-day backstop).
- Mail is stored in our database, which our host encrypts at rest, so the app can show it to your project. It is not end-to-end encrypted. Treat test inboxes as test data, not private correspondence.
- Emails open in a sandboxed view with remote images blocked until you allow them, so tracking pixels don’t fire.
- Our logs record ids, sizes and outcomes, never message content, codes, links, passwords or keys. When a request fails we record its path and status code, and the path can include a test address.

## Who can see what

- Everything belongs to a project, inside a personal space or an organisation. You see only the projects you’re on; organisation owners and admins see all of their organisation’s projects.
- Postgres row-level security enforces this on every table, and live updates use private channels that only project members can join. An isolation test suite of more than 140 tests runs against a fresh database on every change.
- Anyone on a project can read its test mail and reveal its saved passwords. Reveals are logged, so share projects only with people who should have that access.
- Our admin tools show account details and counts for abuse handling. They don’t show mail or passwords.
- Organisation owners and admins get an activity log of who created or deleted addresses, saved or revealed passwords, connected apps and turned extension sites on or off, kept for 90 days.

## API keys, AI agents and the Chrome extension

### API keys

- Shown once, then stored only as a SHA-256 hash.
- Each works in one project and acts as the person who made it. It stops when they leave the project or revoke it.
- Can read saved passwords only if created with that permission.
- Rate-limited per key: 60 requests a minute on Free, 600 on Team.

### AI agents (MCP)

- Connect with OAuth 2.1 and PKCE: you sign in and approve one project.
- Tokens are stored hashed. Access lasts an hour; refresh tokens last 90 days and are replaced each time they’re used.
- Results carry the code or link only, never the email’s text, so an email can’t slip instructions to your agent.
- Can’t read saved passwords. Disconnect any time in Project settings.

### Proxy Mail QA for Chrome

- Off on every site until you turn it on for one; Chrome then grants access to that site only. It refuses broad patterns like \*.com.
- On those sites it reads only the email, name, username and password fields of the form you fill.
- New passwords stay on your device until you choose to save one. A saved one is fetched only when you pick that account to sign in, and the reveal is logged.
- Never opens links on its own. No analytics, ads or remote code.

### In transit

- Every connection to the app, API and website uses HTTPS, with HSTS on the app.
- The extension and agents talk only to our API; nothing is sent to other services on their behalf.

## Where data lives and who handles it

| Supabase   | Database, sign-in and live updates. Hosted on AWS in us-east-2, United States.                                               |
| ---------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Cloudflare | Receiving email, running the API, hosting the app and website, original email files in debug mode, and Turnstile bot checks. |
| Resend     | Sending organisation invite emails.                                                                                          |
| Stripe     | Payments for the Team plan. Card details go to Stripe and never reach us.                                                    |
| Google     | Only if you choose to sign in with Google.                                                                                   |

## How long things are kept

| Data                                                         | Kept until                                                         |
| ------------------------------------------------------------ | ------------------------------------------------------------------ |
| Test addresses, their mail, codes, links and saved passwords | The address expires (up to 30 days) or you delete it               |
| Original email files                                         | Only with debug mode on; deleted with their email, 31 days at most |
| Archived projects                                            | Restorable for 15 days, then deleted with everything in them       |
| Activity log                                                 | 90 days                                                            |
| Agent sign-in codes                                          | Expire after 10 minutes; deleted within a day                      |
| Your account                                                 | You delete it; deletion is immediate                               |

## Ground rules for using it

- Use it only for test accounts on development, staging, QA, preview or local versions of apps you build or are allowed to test.
- Never use a Proxy Mail QA address for a real account, such as banking, shopping or anything you’d need to keep.
- Never use or save a personal or reused password. Let Proxy Mail QA generate one, or invent one just for testing.
- Keep personal data out of notes and labels. Personas are fictional on purpose.
- Remember that everyone on a project can read its mail and reveal its saved passwords.

## Not built yet

So you know exactly where things stand today.

- Two-factor sign-in for Proxy Mail QA accounts.Not yet
- Checking account passwords against known breaches.Before public launch
- Rotating the saved-password encryption key on a schedule. Ciphertexts carry a version prefix so the key can be changed, but rotation isn’t automated.Not yet
- An independent security audit or certification such as SOC 2.Not yet

Questions or a security concern?

Email hello@proxymail.qa or see [Support](https://proxymail.qa/support). The legal terms are in the [privacy policy](https://proxymail.qa/privacy) and [terms](https://proxymail.qa/terms).

[Create a free account](https://app.proxymail.qa/?mode=signup)
