Legal

What we do with
your mail.

OpenEmail is a mailbox, so this document is mostly about the one thing that matters: your messages are yours, and what we hold is only what delivering them requires. Last updated September 16, 2026.

Our Commitment to Privacy

At OpenEmail, we believe that privacy is a fundamental right. Our email solution is built with privacy at its core, and we're committed to being transparent about how we handle your data.

Important: OpenEmail is a mail host, not a client that leaves your mail somewhere else. Mail sent to a domain you have connected is delivered to us and we store it (the full message and its attachments) because there is no other copy for it to live in.

What that means in practice:

Storage: messages and attachments are written to object storage and indexed in a database of their own per mailbox. They stay there until you delete them.
Processing: mail is parsed, threaded, spam-scored, summarised and indexed for search on the server, before a browser is involved. The browser renders what is already stored.
User Control: delete a thread, delete a workspace, and revoke our access to your Google sign-in whenever you like.

Google Account Integration

When you sign in to OpenEmail with your Google Account:

We ask Google for your name, your email address and your profile picture, and for nothing else. No mail scope is requested, so signing in this way gives OpenEmail no ability to read, send or store anything in a Google mailbox.
We use secure OAuth 2.0 authentication provided by Google
You can revoke our access to your Google account at any time through your Google Account settings

Data Collection and Usage

Google Services Data Handling

The profile Google returns when you sign in is handled in accordance with the Google API Services User Data Policy
Data in transit is encrypted with TLS on every hop we control. The SMTP hop to or from a server that is not ours is opportunistic and unmeasured, as the encryption section below sets out. Data at rest is encrypted by the storage provider; we add no second layer of our own, and we hold the keys, so we are technically able to read what we store, and the features that summarise and search your mail do exactly that. The exception is a message that arrived end-to-end encrypted: what we store of it is ciphertext sealed to a key we do not have, so no feature of ours reads it and neither can we.
Operational logs may briefly contain request data, as they do for any request to any server, and they age out on the platform's schedule rather than a period we set.

Data Processing Locations

The app runs on a single virtual server in Ashburn, Virginia, and the database it reads sits alongside it. Attachments are stored separately, in Cloudflare R2. Mail and account data are therefore processed in the United States.
Mail itself moves through Amazon Web Services, in the us-east-1 region (Northern Virginia). A message sent to an address here is received by Amazon SES, written in full to an Amazon S3 bucket in that region, and read back from there by our server, which parses it and stores the result in the storage described above. Mail you send leaves through Amazon SES in the same region. So every message either way passes through the United States, whatever the route it took to reach us.
That S3 copy is the message exactly as it arrived: headers, body and attachments, encrypted at rest by Amazon and readable by us in the same way the parsed copy is. It is deleted automatically 30 days after it arrives, and nothing in the product reads it once the message has been ingested. A message that arrived end-to-end encrypted is ciphertext there as it is everywhere else.

AI and Your Email Data

What is sent to a model, and when

When you ask. Opening the assistant, asking for a summary, generating a reply or running a search sends the material that request needs: the text of the messages or thread in view, and the instruction you typed. Attachments are not sent unless the action you chose is about the attachment.
When mail arrives. New threads are summarised and labelled automatically, and subject lines are sampled to work out what you get mail about. That is a model call you did not individually ask for, and we would rather say so plainly than leave you to discover it: it is what makes summaries and labels there when you open the inbox instead of after a wait. It runs on the thread as it arrives.
When you send. The text of a message you send is passed to a model to maintain the writing-style profile that lets the product draft in your voice. This happens on every send, including one you wrote entirely yourself, and there is currently no setting to turn it off.
Every prompt you trigger is readable and editable in the product, so you can see what a request would send before you send it.

What is kept

We do not use your email, prompts, or completions to train models, and we do not sell them or hand them to anyone for their own use.
Some AI output is stored, because a summary you cannot keep is not worth generating: thread and message summaries are saved against your mailbox, and your conversation with the assistant is kept so it is still there when you come back. Clearing the assistant conversation deletes it. Deleting a thread removes the message, its attachments and the summary written for search. That summary is a paragraph describing the thread, so leaving it behind would leave a readable description of something you had deleted.
Beyond that, prompts and completions are not retained as a separate transcript. Operational logs may briefly contain request text, as they do for any request to a server, and they age out.

Where inference happens

The assistant, compose, web search, the search queries we build for you, the writing-style profile and the topic sampling of your subject lines are routed through OpenRouter carrying a no-retention routing preference: data_collection: 'deny', applied in apps/api/src/lib/ai-key.ts as PLATFORM_ROUTING. The router excludes from those requests every upstream provider whose policy permits keeping prompts for training; if no eligible provider remains for the chosen model, the request fails rather than falling back to one that does.
That preference is a routing instruction to our provider. It is the mechanism, and it is what we can honestly claim, not a guarantee we are in a position to make on an upstream provider's behalf.
The background work on arriving mail (a summary for each message and thread, and the label suggestions that go with them) goes through OpenRouter, the same route as everything else above, so the routing preference applies to it too.

Data Protection and Security

Security Measures

End-to-end encryption works in both directions, though sending reaches a smaller set of people than reading does. You can generate an OpenPGP key in your browser and publish its public half to a directory that other signed-in OpenEmail senders can look up. The private half is generated in that browser, is never sent to us, and exists in no backup, log or support tool of ours. There is deliberately no escrow and no recovery: your passphrase is the only way in, and if you lose it nobody, including us, can open mail that was sealed to you. That mail is then gone, permanently, and no request to us recovers it.
A PGP message that arrives sealed to a key your browser holds is now decrypted in your browser and shown to you there. We hold that message as ciphertext and we never see the opened text: the decryption happens on your machine, the plaintext is never sent back to us, and nothing of ours writes it down. Because of that, a sealed message is also outside everything the server does by reading mail. There is no readable body for any of it to work on, so it is not searchable by its body, it is not summarised or translated, the AI features have nothing to read on it, and rules cannot match on what it says.
Sending is wired now, and it reaches a smaller set of people than reading does. Composing to a recipient whose public key is published seals the body in your browser before the request leaves it, and a send that would be encrypted fails rather than going out. It never falls back to sending in the clear. But the only place a recipient's key is looked up is our own directory, which holds keys published from this app by people whose address is on a domain hosted here: there is no Web Key Directory, no keyserver, no Autocrypt, and no way to export your own public half. So in practice sealing works OpenEmail to OpenEmail, while READING has no such limit: any PGP message sealed to a key in this browser opens, whatever client sent it. Encrypted replies are refused, because the quoted original would fall outside the seal.
Every other message here moves over TLS on the hops we run, and is encrypted by the storage provider at rest; the server can read all of them, which is what lets it thread, search and summarise them. The hop between us and a server that is not ours is opportunistic STARTTLS (offered, never required), and nothing handed over with a delivered message says which the sender used, so we do not claim TLS on any individual message. Even on a sealed message, PGP covers the body and nothing else: the subject line, who you wrote to and when all travel in the clear, drafts are saved to your mailbox unsealed while you write, and we would rather say so than let a padlock imply otherwise. S/MIME is recognised and labelled but cannot be opened here, which is not the same as being opened.
OAuth 2.0 for connected Google accounts, with the narrowest scopes the features need
Dependency and security updates are automated

Infrastructure Security

The hosted service runs on Cloudflare (Workers, R2, Durable Objects, KV and Queues) over a managed Postgres database, with Amazon Web Services (SES and S3, us-east-1) carrying mail in and out. It inherits those providers' physical and network security.
Stored data is encrypted at rest by those providers. We run no data centre of our own and make no certification claim of our own.

Security Response

Vulnerabilities are reported privately to [email protected] and handled by the people who wrote the code.
There is no bug bounty and no staffed 24/7 rota. Claiming either would set an expectation we cannot meet.

Google User Data Handling

Data Access and Usage

The only Google user data we receive is the sign-in profile: your name, your email address and your profile picture. We request no Gmail scope, so no message content, no message metadata and no labels from a Google mailbox ever reach us.
That profile is used to create and identify your OpenEmail account. The address and the name on it also go on the product mailing list described below, as they would for an account created with an email and a password. That is the one use beyond your account itself, and it carries an unsubscribe link.
No Google user data is used for profiling or for advertising, and none of it is handed to an advertiser or a data broker
Access to stored user data is limited to the maintainers who operate the service. There is no per-access audit log: the product does not keep one, and we would rather say that than imply a record we could not produce.

Data Sharing and Transfer

Google user data is never shared with third parties except as required for core service functionality
When necessary, we only work with service providers who comply with Google API Services User Data Policy
Your address goes on a mailing list when you register, so we can reach you about the product. It is held at Resend, who also carry the transactional mail, and it holds your address and the name on your account: nothing about your mail, and nothing about who you correspond with. Every message sent from it carries an unsubscribe link, and unsubscribing does not affect your account.
The providers the hosted service depends on are a virtual server in Ashburn, Virginia for the application itself, Cloudflare for attachment storage and for serving the web pages, Amazon Web Services for sending and receiving mail and for the raw inbound copy described above, a managed Postgres host for the database, Polar for payments, Resend for transactional mail and the mailing list above, and the AI providers named in the section above. Five more are reached from your browser or on your behalf and are named for completeness rather than because they receive much: Gravatar, asked by our server for a picture of a correspondent using a hash of their address and never the address itself; a public DNS resolver, asked whether a sender's domain publishes a brand logo, which therefore sees that domain but never an address or a message; Google and GitHub, which serve the profile picture of anyone on OpenEmail who brought it from a Google or GitHub sign-in, straight to your browser when that person appears in your mailbox; ElevenLabs, which your browser opens a workspace to only while you are actually using voice mode, and not otherwise; and the sender's own host. That host is reached two ways. Our server asks it, or wherever it points, for the brand's logo or site icon when a correspondent has no other picture, which it sees as a request from us. Your browser fetches the images inside a message from it directly. Both can be switched off in Account → Privacy, the first with picture lookup and the second with external images. Picture lookup, like Gravatar above, is ON by default. So are external images, so a tracking pixel in a message does see your address and the moment you opened it until you turn them off. Typefaces are not on this list because they are not fetched from anyone: every face is bundled and served from the same origin as the app. Error reporting is not either unless it is configured. Nothing is sold or handed to anyone for their own use.
Users are notified of any material changes to our data sharing practices

Data Retention and Deletion

Stored mail has no expiry. It is kept until something deletes it, and nothing deletes it on a timer.
The one exception is the copy of each inbound message held in Amazon S3 as it arrived: that is deleted automatically 30 days after delivery.
Deleting a thread removes the stored message and its index entry.
Disconnecting an account purges the mailbox behind it. So does removing the last domain in a workspace, which takes every message stored for it. The app warns you before it does.
Ask us and we will delete whatever is left.

User Rights and Controls

Right to access: Request a copy of your data
Right to rectification: Correct inaccurate data
Right to erasure: Request deletion of your data
Right to restrict processing: Limit how we use your data
Right to data portability: request your data in a portable form. Handled on request like the rest of this list. There is no self-serve export in the product yet, and this page will not imply a button that does not exist.
Right to object: Opt-out of certain data processing

Limited Use Disclosure

Our use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Your Rights and Controls

Right to revoke our Google sign-in access at any time
Right to request deletion of the mail and the data we hold
Right to ask for a copy of your data
Right to lodge complaints about data handling

Pricing and Refund Policy

Free Plan and Paid Plans

OpenEmail offers a free plan (1 domain and 10 addresses) that requires no payment information
Paid plans raise those limits and add team members: Starter is 5 domains, Business 10 domains and Enterprise unlimited domains, each with unlimited addresses
The REST API, the MCP server and the TypeScript SDK are on every plan, the free one included. What meters programmatic sending is the same monthly send allowance that meters everything else, not a separate entitlement
Receiving is unlimited on every plan. The free plan includes 10,000 sends a month and 50 AI actions a day, and the paid plans lift both. There are no usage charges of any kind. You are only ever charged the price of the plan
There is no free trial on any paid plan. The free plan is not a trial either: 1 domain and 10 addresses, with no card required and no time limit
A paid plan is charged when you buy it, and on each renewal after
You can cancel at any time; the plan runs to the end of the period you paid for

Payment and Billing

Subscription fees are billed in advance, monthly or yearly
Current pricing information is available on our pricing page
All payments are processed securely through our trusted payment partners
Subscription charges will appear on your billing statement as "OpenEmail"
We accept major credit cards and other payment methods as available in your region

Non-Refundable Policy

Important: subscription fees are non-refundable once a billing period has begun
This policy applies to Starter, Business and Enterprise alike, on either billing period.
Refunds are not provided for partial subscription periods
Refunds are not available for unused portions of your subscription
In exceptional circumstances, refunds may be considered on a case-by-case basis at our sole discretion

Subscription Management

You can cancel your subscription at any time through your account settings
Cancellation takes effect at the end of your current billing period
You will continue to have access to premium features until the end of your paid period
No partial refunds are provided for early cancellation
Reactivation of cancelled subscriptions may be subject to current pricing

Price Changes

We reserve the right to modify subscription pricing at any time
Existing subscribers will be notified of price changes at least 30 days in advance
Price changes will take effect at your next billing cycle
You may cancel your subscription before the price change takes effect

Contact

For privacy-related questions or concerns:

[email protected]

Updates to This Policy

We may update this privacy policy from time to time. We will notify users of any material changes through our application or website.

What we do withyour mail.