Privacy policy

Effective date: October 7, 2026

Pending update (draft of October 10, 2026). Sections 1, 3, 4, 6, 7 and 8 have been revised to describe how we classify replies and learn from campaign results. These changes are not in effect yet. They take effect on a date we will email account holders about beforehand.

Pending update (draft of October 11, 2026). A new section 12 (Lead data) has been added, and sections 1, 3, 4, 6 and 9 have been revised, to describe the contact and company records we make available to customers, our role as controller of them, and how to be removed. These changes are not in effect yet. They take effect on a date we will email account holders about beforehand.

This policy explains how EmailPal (“EmailPal”, “we”, “us”) collects, uses, stores and shares personal data when you visit emailpal.io, create an account, or use the EmailPal platform, REST API or MCP server (together, the “Service”). It also explains how we handle data belonging to people who receive email sent through the Service, because an email platform that only talks about its customers’ privacy is describing half of what it does.

Questions about this policy or about your data can be sent to privacy@emailpal.io. We answer these ourselves, not through a form.

1. The two roles we play

For the personal data of our customers and website visitors — your account details, billing information, usage of the dashboard and API — we are the data controller. We decide what is collected and why, and this policy is our explanation.

For the personal data of recipients — the addresses our customers upload, the messages they send, and the replies that come back — we are a data processor. That data is controlled by the customer who sent the mail. We process it only to provide the Service, to protect the deliverability of our infrastructure, and to prevent abuse, all as described in this policy and in our terms of service. If you received an unwanted email sent through our infrastructure, section 8 below is written for you. If your details appear in the lead table we make available to customers, section 12 is written for you.

There are two narrow exceptions to the processor role, and they are the only ones. The first: from messages and replies we derive de-identified, aggregated performance data — counts and abstract descriptions of copy, never the text or the people (see “Learning from campaign results” in section 3). For that derived data we decide the purposes ourselves: improving the Service and sharing what it shows across our customers.

The second is Lead Data: contact and company records about business people that we obtain from a third-party data provider and public sources, and make available to customers through the Service (section 12). Unlike a list a customer uploads, nobody uploaded this data to us. We decide for ourselves what we obtain, why, and how it is offered, so for Lead Data we are the data controller. When a customer exports, saves or sends to a Lead Data record, that customer is the controller of the copy it holds.

2. Data we collect from customers and visitors

Account data

When you sign up we collect your email address, and during onboarding we ask for your name, company details, and website. You also choose a password, which we never see in readable form: it is hashed by our authentication provider before it is stored, and a reset replaces the hash rather than revealing it.

Billing data

Payments are processed by Stripe. We never see or store full card numbers. We keep the billing records we generate ourselves — plans, invoice line items, usage quantities, and your prepaid domain balance — because we compute every invoice from our own records and must be able to explain any charge to you line by line.

Usage and log data

We record how the Service is used: dashboard actions, API requests (including the API key used, endpoint, timestamps and originating IP address), jobs run on your behalf, and the automated decisions the platform takes about your sending, such as throttles applied or warming schedules changed. We keep these records because the platform acts automatically and you are entitled to an explanation of every action it took.

Technical data

Standard web server logs: IP address, browser type, pages requested, and timestamps. We use session cookies that keep you signed in, and Google Analytics cookies that record which pages are visited. When a signup or a first paid invoice is attributed to a Meta advertisement, we send Meta a SHA-256 hash of the email address, plus the IP address and user agent of that request, through their Conversions API. Conversion events are sent from our servers, not from the browser. If a Meta Pixel ID is configured, we also load Meta’s pixel so it can set _fbp and _fbc cookies that improve matching between the browser session and that server event.

The chat assistant

The chat button on our website and in the dashboard opens an AI assistant that answers questions about EmailPal. It can be wrong, and it is not a person. When you use it we store:

• The conversation— everything you and the assistant write, the page you were on, the time, and any thumbs-up or thumbs-down you give an answer. Do not type passwords, card numbers or other sensitive information into it; we cannot reliably remove it once sent.
• An identifier for rate limiting and continuity— a random visitor id kept in your browser’s local storage (alongside the transcript, so the conversation survives navigation), which we store only as a keyed hash, and a keyed hash of your IP address. Neither is stored in readable form on our side. If you are signed in, we also link the conversation to your account.
• Email addresses you give it.If you give the assistant your email and agree to be contacted — for a demo, a follow-up, or a question it could not answer — we save it, with your name and a note on what you wanted if you gave them, so a person can write back. We use it for that follow-up only and do not add it to a marketing list.
• Support tickets you open from it. A ticket opened through the assistant carries your email and a copy of the conversation, and a notification goes to our team by email. We reply to the address you gave. Tickets are kept as support records, and we delete one on request at privacy@emailpal.io.
• Questions it could not answer. The text of an unanswered or thumbs-downed question is kept in a review queue so our team can teach the assistant a better answer. Approved answers are written by us and contain no visitor details.

AI provider.The assistant’s replies are generated by Xiaomi’s MiMo language model, so what you write in the chat, the most recent turns of the conversation, and the page you are on are sent to Xiaomi for processing, together with excerpts of our own documentation. If you are signed in we also tell it your email, your workspace name, plan and role, so it can answer in context; we do not send it your password, payment details, mailbox content or other customers’ data. International transfers are covered by section 7.

Retention. Chat messages and conversations are deleted automatically 180 days after the last message. Questions our team has answered or dismissed are deleted 180 days after they were handled, and rate-limiting counters after one day. Saved contacts and the answers we taught the assistant are kept until we delete them; to have a contact removed, email privacy@emailpal.io. Chats are read by our team only to review answer quality and to follow up on a request.

3. Data we process on customers’ behalf

Mailbox content

The Service hosts mailboxes. Messages sent from and received by those mailboxes — including their content, headers, and attachments — are stored on our infrastructure so that features like the unified inbox, reply detection and exports work. This content belongs to the customer. We do not read it out of curiosity or sell it, and we do not use the text of your messages to train machine-learning models. We do inspect it, by automated means and where necessary by a human, for the abuse prevention purposes described in section 5, and we process sent copy and replies in the specific ways described under “Learning from campaign results” below, which produce labels, features and counts rather than a model trained on your text.

Recipient lists

When a customer submits a recipient list for verification, we classify each address (deliverable, invalid, risky, suppressed, duplicate) and return the assessment. A large list is checked over several hours rather than in one pass, so each address and its result are stored while the check runs and returned to the customer as they are decided.

Those per-address records are deleted ninety days after the check, or immediately if the customer deletes the upload or closes the account. What we keep after that is the summary — how many addresses fell into each category, and the resulting verdict — which contains no addresses. The records are readable only by the customer who submitted them; we do not combine uploaded lists across customers or sell them, and we do not add the addresses in them to the Lead Data we make available. Lead Data (section 12) is a separate set of records that we obtain from a data provider and public sources, not from our customers’ lists.

The suppression list

When a recipient unsubscribes from mail sent through our infrastructure, or complains about it via a provider feedback loop, we record that address on a platform-wide suppression list. This is a deliberate retention: the entire purpose of the record is to make sure that address is never mailed again through our infrastructure, by any customer. We consider this processing to be in the clear interest of the recipient, and it is the one category of recipient data we will not delete on a customer’s instruction, because deleting it would cause the very harm it exists to prevent.

Unsubscribe links

Every message relayed through our infrastructure carries a one-click unsubscribe header. The link contains a signed token rather than a database identifier, which means we store nothing about a recipient at the moment of sending — a record is created only if the recipient actually unsubscribes, at which point their address enters the suppression list described above.

Learning from campaign results

To tell you what is working and to help every customer write better outreach, we sort replies into categories and record which kinds of copy led to which outcomes. Here is exactly what that involves.

• Sent copy. For mail sent through the Service we record the subject line and descriptive features of the message: what kind of opener it uses, what it asks for, roughly how long it is, and how much of it is personalized. For cold mail sent from external sequencing tools, and only where this capture is switched on, we also hold a short plain-text prefix of the body (a few kilobytes) for as long as it takes to group messages that share a template, and in any case no longer than 14 days, after which it is deleted. Warm-up traffic is excluded.
• Replies. Each reply is classified (interested, not interested, asks to be removed, out of office, and so on) by an automated classifier. To do that, the text of the reply, without the quoted earlier messages and cut to a short length, is sent to the language-model provider listed in section 6. We store the label and a confidence score. We do not store the reply text in the learning records, and people in your workspace can see and correct every label in the inbox.
• Embeddings.To compare copy by meaning, text with names and other identifying details masked out is converted to a list of numbers (an embedding) by the embeddings provider listed in section 6. Embeddings are kept with your workspace’s data and are not part of the shared results described below.
• Vendor terms. We require each of these providers to process the text only to return its answer, not to retain it, and not to use it for training. We send only what the task needs.

What is shared across customers.The shared results hold de-identified, aggregated performance data only: counts of sends and outcomes grouped by the kind of copy (for example, “opens with a question”), by delivery outcome and by broad context. They do not contain recipient lists, addresses or names, the text of replies, message text, or any identifier of your workspace, and results from workspaces run by the same operator count as one. We never show one customer another customer’s copy, replies or uploaded lists. A figure from the shared results is shown to a customer only when enough separate senders support it that no one of them can be picked out, and only to workspaces that are included in it.

Your control.Under our Terms of Use, every workspace is included in the shared pool from [launch date — to be confirmed]. An owner or admin of a workspace can turn that off at any time in Engage settings under “Include this workspace in anonymized pooled learning”, or ask support to turn it off. Turning it off removes the workspace’s results from the shared pool the next time the pool is recomputed and ends access to the shared figures. Closing an account has the same effect. Reply classification and the “What’s working” view of your own workspace are part of the Service and continue either way, because they use only your own data.

4. How we use data

• Providing the Service — provisioning domains, DNS and mailboxes, warming, routing mail, measuring inbox placement, and operating the dashboard, API and MCP server.
• Reputation management — classifying SMTP responses, monitoring blocklists and provider reputation programs, and adjusting sending automatically. This is the core of the product and it necessarily involves processing delivery metadata about every message.
• Abuse prevention — verifying accounts, screening recipient lists, detecting prohibited content and behaviour, and enforcing our acceptable use policy.
• Learning what works — classifying replies, measuring which kinds of copy lead to which outcomes, showing you the results for your own workspace and, where your workspace shares, improving the shared results described in section 3.
• Making Lead Data available — obtaining contact and company records from a data provider and public sources, letting customers search them and use them for business-to-business outreach, and honouring removal requests, as described in section 12.
• Billing — metering usage and computing invoices.
• Support and communication — answering your requests and sending you operational notices about your account. We do not send marketing mail to recipients, and we do not add our customers to marketing lists without asking.
• Legal obligations — responding to lawful requests from authorities, and keeping the records that tax and accounting law require.

5. Message inspection for abuse prevention

We operate shared sending infrastructure. One customer sending fraud or spam damages the deliverability of every other customer, so we reserve the right to inspect message content, headers, sending patterns, recipient list characteristics and delivery outcomes — by automated systems routinely, and by a human where the automated systems flag something or where we receive an abuse report. This inspection is limited to what is needed to decide whether the acceptable use policy is being followed. Its outcomes (throttles, suspensions, terminations) are recorded, and serious findings such as phishing or fraud may be reported to hosting providers, blocklist operators or law enforcement.

Automated scanning of outbound mail. A sample of the mail sent through the Service, not every message, may be scanned automatically for violations of the acceptable use policy, such as phishing, links that disguise where they go, or a fabricated reply. The scan reads the subject, the start of the text and the links, using rules and a language-model service that processes the text for a single request and keeps nothing afterwards. It does not store the message text. When a message is flagged, we keep the result and a short excerpt of at most 200 characters for 14 days; for a message that is not flagged we keep only a record that it was checked. A single flagged message does not by itself restrict an account.

6. Who we share data with

We do not sell the personal data of our customers, our website visitors or the recipients of mail sent through the Service. Lead Data is different. Making Lead Data available to customers may count as a “sale” or “sharing” of personal information under some US state privacy laws, and if you are in the lead table you can opt out as section 12 explains. We also send hashed identifiers to Meta so we can measure which of our advertisements led to a signup or a paid subscription; Meta does not receive a readable email address. We share data with the service providers we build on, each only receiving what its function requires:

Beyond these, we disclose data only when the law requires it, to enforce our agreements, or as part of a merger, acquisition or asset sale — in which case this policy continues to apply to data transferred, and we will tell you before a new policy does.

7. International transfers, retention and security

Our infrastructure is operated in the United States and the European Union. Where personal data subject to the GDPR or UK GDPR is transferred outside those regions, we rely on adequacy decisions or standard contractual clauses.

We keep account and billing records for as long as your account exists and for the period afterwards that accounting and tax law require. Mailbox content is deleted when a mailbox is deleted, and account content becomes unrecoverable following the export window described in the terms of service. Operational logs are kept for up to twelve months. Per-address verification results are kept for ninety days, as described in section 3. Chat conversations are deleted 180 days after their last message, as described in section 2. Suppression list entries are kept indefinitely, for the reason given in section 3.

For learning from campaign results (section 3): the plain-text body prefix held to group template sends is deleted within 14 days. Reply labels, confidence scores, copy features, embeddings and per-workspace outcome counts are kept for as long as the account exists and are deleted when it is closed. They hold no message text. The shared, de-identified results contain no workspace identifier, so they are not deleted one workspace at a time; instead a workspace that opts out, or whose account closes, is left out of the next recomputation and its contribution leaves the results then. Our language-model and embeddings providers keep nothing after answering a request.

Some mailboxes are leased rather than owned, and the same address is later leased to a different customer. Reuse of an address is never reuse of its contents. When a lease ends we destroy the mailbox on the mail server outright rather than emptying it, delete the stored messages, message index, sync state and credentials from our database, and clear the sender identity attached to it. The address is then recreated from nothing with new credentials, so there is no path by which the previous customer’s mail or logins reach the next one. What survives is the address string and its aggregate deliverability metrics — counts of messages sent, placement outcomes and health scores — which contain no message content and no recipient identities. Mail arriving at a reclaimed address is discarded, not delivered, for a quarantine period before it is leased again.

Sensitive material — mailbox credentials, signing keys, and credentials for connected services — is encrypted at rest, with keys segregated so that no single system holds all of them. Access to production data is restricted, logged, and used for operating the Service rather than exploring it. No description of security is a guarantee, but if a breach affects your personal data we will notify you and the relevant authorities as the law requires.

8. If you received email sent through EmailPal

The sender of that message — our customer — is the controller of your data, and chose to contact you. What we can do, and will do, is this:

• Unsubscribe: use the unsubscribe link in the message. It works with one click, requires no login, and places your address on a platform-wide suppression list so that no customer of ours can mail it again.
• Report abuse: forward the message with its headers to abuse@emailpal.io. Abuse reports are read by a person and acted on against the sending account.
• Exercise data rights: requests to access or delete data held by the sender should go to the sender, who is identified in the message. If you cannot reach them, contact privacy@emailpal.io and we will pass the request to the customer and suppress your address in the meantime.
• Your reply: if you reply to the sender, an automated classifier sorts your reply into a category (for example interested, not interested, or asks to be removed), and the text of the reply is sent to our language-model provider to do that, as described in section 3. Only the category and a confidence score are kept for learning, not the text. A reply that asks to be removed is acted on and your address is suppressed.

9. Your rights

Depending on where you live, you may have the right to access the personal data we hold about you, correct it, delete it, receive it in a portable format, object to or restrict certain processing, and complain to a supervisory authority. Residents of the European Economic Area and the United Kingdom have these rights under the GDPR and UK GDPR; California residents have analogous rights under the CCPA/CPRA, including the right to know and the right to delete. We do not sell personal information about our customers, website visitors or mail recipients. Two uses may count as a “sale” or “share” under the CPRA and similar state laws: making Lead Data available to customers (section 12, which also explains how to opt out), and sending hashed identifiers to Meta to measure our advertising. Those are the only such uses.

To exercise any of these rights, email privacy@emailpal.io from the address associated with your account, or with enough information for us to verify who you are. We respond within the time the applicable law allows, and we do not discriminate against anyone for exercising their rights.

10. Children

The Service is business infrastructure and is not directed at anyone under 18. We do not knowingly collect personal data from children, and we delete any we discover.

11. Changes to this policy

When we change this policy we will update the effective date above, and for material changes we will notify account holders by email before the change takes effect. Continued use of the Service after a change takes effect means the updated policy applies.

12. Lead data

This section is for two audiences: people whose details may appear in the lead table we make available to customers, and customers who use it. For Lead Data, unlike the recipient lists customers upload, EmailPal decides the purposes itself and is the data controller (section 1).

What Lead Data is

Lead Data is a set of contact and company records about business people. A record can contain a person’s name, job title, employer, company domain, industry, company size, location, LinkedIn URL, business email address and phone number. Lead Data covers people located in the United States only: we do not offer Lead Data about people in the European Economic Area, the United Kingdom, Canada or any other country, and customers may use it only to contact people located in the United States.

Where it comes from

We do not collect Lead Data from the people it describes. We obtain it from a third-party data provider and from public sources. The provider is named in the table in section 6.

Why we have it, and the legal basis

We make Lead Data available so that businesses can find and contact people in relevant roles about relevant business offers. Our legal basis is legitimate interests: ours and our customers’ interest in business-to-business outreach, balanced against your interests by the limits we set (United States only, business contact details, and the removal route below). We try to leave out personal addresses at free email providers, government, military and education addresses, but filtering is not perfect. The data we receive has no age field, so we cannot screen out minors; the Lead Data we show is business contact data for people in a working role, and anyone who believes a record belongs to a minor can use the removal route below.

Who sees it and what they may do

Customers of the Service can search the lead table and, subject to the terms of service and the acceptable use policy, use a record for their own business-to-business sales, marketing and recruiting. A customer that exports, saves or sends to a record becomes the controller of its own copy and is responsible for having its own lawful basis. Customers are told they must not resell Lead Data, must not use it to contact anyone outside the United States, and that calls and texts made with phone numbers from it are their responsibility under the TCPA, Do-Not-Call and state telemarketing rules. Where the provider says whether a phone number is a mobile number, we label it; the label is the provider’s information and may be wrong.

What customers see, and what we keep

A customer with an active subscription sees the business email address and phone number of the records it views in the lead table automatically. A customer without one sees names, job titles, companies and similar details only; the email address, phone number and LinkedIn link are withheld by us before the record reaches their browser. Requests are rate limited to protect the data and the Service, and the terms of service say that such limits must not be circumvented.

We hold contact details only transiently: in the memory of the server handling the request, and in the customer’s browser session. We store a contact in our database only when the customer explicitly adds it to a list or a campaign, and from then on the customer is the controller of that copy. The data provider’s own workspace temporarily saves contacts when we retrieve them for a customer, and we delete them from it after delivering them.

Sale and sharing

Making Lead Data available to customers may be a “sale” or “sharing” of personal information under some US state privacy laws, for example the CCPA/CPRA. You can opt out, and the way to do so is the removal route below.

How to be removed

• If you are the person in the record: go to /legal/lead-removal and enter your email address, and a LinkedIn URL if you want to. We send a one-time confirmation link to that address. When you confirm, you are removed from the lead table and your email address is added to our platform-wide suppression list, so no customer can mail it through our infrastructure. We keep one-way (keyed hash) records of the details you gave, so that you are not shown again.
• If you speak for a company: a company can ask for removal of a domain it controls by proving control of the domain with a DNS TXT record. The removal page explains how.
• Anything else— bulk requests, requests from counsel or agencies, and any case the page cannot handle — email privacy@emailpal.io. A person reviews these.
• Reports by customers:a customer can report an individual record, for example because the data is wrong or the person asked not to be contacted. A report hides the record in that customer’s workspace only, until it is verified.

Two limits are worth stating. Removal hides you in our lead table. It does not change the records held by our data provider, and it does not erase copies a customer exported earlier; for those, contact the customer, who is the controller of its copy. Suppression stops any customer mailing your address through our infrastructure.

Your other rights

You can also ask for access to, correction of or deletion of Lead Data about you, and residents of states with privacy laws can exercise the rights described in section 9, by emailing privacy@emailpal.io. We respond within the time the applicable law allows, and we do not discriminate against anyone for exercising their rights.

13. Contact

Privacy questions and requests: privacy@emailpal.io
Abuse reports: abuse@emailpal.io
Everything else: support@emailpal.io