Privacy Policy

Last updated: September 15, 2026 — recovery-copy clarification and failed-feedback retention notice

This policy describes what Emcognito collects, why we collect it, who we share it with, and the choices you have. The plain-English questions above are part of this policy; the sections below are the formal version. Where the two ever disagree, the plain-English answer is the controlling one and you should email hello@wm.emcognito.com so we can fix the formal text.

Who we are

Emcognito is operated by VectraSEO LLC, a Pennsylvania limited liability company and a small independent team. When this policy says "we," "us," or "Emcognito," it means that operator. When it says "you," it means the person using the service at emcognito.com. For any privacy matter you can reach us at hello@wm.emcognito.com.

What we collect, and why

Information you give us

• Your account email address. Used as the destination for forwarded mail, passwordless sign-in, account and service notices, lifecycle messages, support, and, for paid accounts, the Stripe customer relationship. This is the one piece of personal data the service cannot function without.
• The aliases you create. Each alias is a unique address on a domain we operate (for example, abc123@emcognito.com). You may optionally attach a label, source, note, or category to an alias; if you do, we store that text so the dashboard can show it back to you.
• Optional support messages and feedback. If you email us or use the feedback form, we keep the message so we can reply.
• Custom-domain research waitlist responses. If you submit the research waitlist form in Billing Settings, we store your configuration choices (domain status, count, use case, timeline, catch-all/migration needs, and whether you'd like an email notification) linked to your account. No domain name is ever requested or stored. You can edit your choices or withdraw/delete your response at any time using "Leave research waitlist" in Billing Settings, which immediately deletes the entry from our database.
• Billing details (paid plans only). If you subscribe to a paid plan, Stripe — not Emcognito — collects and holds your payment card. We store a customer identifier and the subscription state Stripe sends us, never your card.

Information we collect automatically

• Forward counts and timestamps. For every forwarded message we increment a counter on the destination alias and on your account so we can enforce monthly plan limits, surface aliases that are getting unusual volume, and detect a destination inbox that's bouncing. We do not retain the message body after delivery, with undelivered mail subject to the quota hold and separate incoming-volume safety pause described under "How long we keep things" below.
• The delivery log. For every message handled for one of your aliases — not only mail you miss — we record a delivery record: the sender's address, the subject line, which alias it was addressed to, the outcome (forwarded, held, released, expired, or rejected), and the time it was recorded. We never store the message body — there is no field for one. This is enabled for every account by default; there is no setting that turns it off. Each record is deleted automatically after a retention window set by your plan — 30 days on Free, 6 months (180 days) on Plus, and 12 months (365 days) on Pro. The window is fixed when each record is written, so a longer window applies only to records written after you upgrade and never restores records already deleted or expired. You can read, search, and filter the log in the dashboard's Delivery Log, and export the full window your plan keeps under your current filters as a CSV at any time. See "How long we keep things" below.
• A count of messages you missed. When a message cannot be forwarded because your account is over its monthly cap, we add 1 to a running total on your account. This is separate from the delivery log above — it is a single number with no sender, no subject, no alias, and no time attached, kept for everyone either way, so we can tell you "you missed 12 messages this month" at a glance without you having to read the log. It resets when your monthly cap resets.
• Standard request logs. AWS records request metadata for the website and API, and DigitalOcean records operational metadata for the mail forwarder. Depending on the service, this can include IP address, user agent, timestamp, route, and HTTP or SMTP status. We use these records for delivery, security, reliability, and abuse prevention; retention follows the configured provider and service settings rather than a single promised period.
• Consent-based analytics. Google Analytics 4 (GA4) is not loaded until you explicitly accept analytics. If accepted, it records page views and product interaction events across public and signed-in pages. We do not use GA4 for advertising. You can decline initially or withdraw consent at any time through "Analytics preferences" in the footer; withdrawal blocks future events and removes accessible GA cookies where possible.
• Service and lifecycle email events. Account, onboarding, quota, and other lifecycle messages may record delivery outcomes and use signed links or a small image request to record clicks or opens. Open data can be affected by mail-client privacy proxies and is treated as an approximate engagement signal. These operational lifecycle events are separate from optional GA4 browser analytics.

Failed email-feedback processing

To avoid losing email delivery feedback, such as bounce and complaint reports, when our feedback handler is unavailable, we are introducing an encrypted AWS SQS recovery queue after publication of this notice. Reports that cannot be delivered to the handler may be retained in that queue for up to 7 days. They can contain recipient and sender addresses, message identifiers, delivery or complaint details, timestamps, and email headers, including subject lines when supplied by AWS SES. This is operational feedback metadata, not a backup of forwarded message bodies. Access is restricted to authorized operators for investigating failures and retrying feedback processing, so delivery protections and recipient preferences can be applied. It is not used for advertising or content profiling. Deleting an account does not immediately remove reports already waiting in this queue; they remain subject to the queue retention limit and separate operational handling of deletion requests.

Related-account protection

Related-account and free-allowance protection. We compare verified account email addresses using provider-specific mailbox rules and look for similar addresses alongside quota use. After a successful sign-in, we may retain a keyed hash of the network address and the observation time for 30 days. The network correlation key changes monthly. When browser-evidence collection is enabled, completing sign-in stores a random first-party browser identifier in local storage for 30 days. After successful authentication, we may retain a keyed hash of the latest browser identifier presented by each account and its observation time for up to 30 days. This helps administrators review accounts that use the same browser profile; it does not identify a physical device or prove common ownership. Clearing site storage removes the browser identifier, and we do not reconstruct it using other storage. It persists across sign-out until it expires, but contains no email address or sign-in credential. This evidence is linkable security data, not anonymous data. We do not collect canvas, font, WebGL, or hardware fingerprints, or include message content in this evidence. Those signals alone do not automatically restrict an account. When automatic quota protection is enabled, matching non-generic email prefixes across different providers, matching authenticated browser observations, and a forwarding attempt after another account reached its free cap can place the accounts on one shared free allowance pending review. You can request a correction through support; accounts and mail remain separate. We retain a bounded verified-account candidate index and cap timestamps for up to 30 days, and decision audit records for up to 90 days.

Verified addresses that resolve to the same personal Gmail mailbox may share one free allowance. Account access, aliases, and messages remain separate; paid plans keep their own allowances. Administrators can review the evidence, dismiss a match, or restore separate allowances. Contact hello@wm.emcognito.com to request a review. We do not use an LLM to decide whether accounts are related.

Review decisions and their reasons are retained for up to 90 days. Temporary quota-reservation records expire after 7 days. Account deletion removes network and browser evidence and reservation records from the live database. Recovery copies are subject to the separate Database recovery copies section below. A shared mailbox digest and usage counters remain while related accounts exist, or for 35 days after the last account is deleted to prevent deletion from resetting the current month's allowance. Expired evidence is excluded from decisions immediately; physical removal follows the storage provider's expiration processing.

What we don't do

The limits below on reading forwarded messages concern message bodies. We process limited delivery metadata, including headers and subject lines in the delivery log and failed-feedback reports described above, to operate delivery and its protections.

• We do not read, scan, profile, or analyze the contents of the email messages forwarded through your aliases. They pass through our forwarder host (Postfix → AWS SES) and are deleted from disk as soon as SES accepts them for delivery. Undelivered mail can instead wait under two separate protections. For a message that arrives while your account is over its monthly forward cap, that message waits, undelivered and unread, in a holding area on the same forwarder host for up to 72 hours, so it can still be delivered if you upgrade within that window. A separate incoming-volume safety pause can retain accepted mail until you resume processing or support verifies deletion; it does not automatically expire after 72 hours. See "How long we keep things" below.
• We do not sell, rent, or trade your information to third parties.
• We do not share your data with marketers, data brokers, or advertising networks.
• We do not build behavioral profiles of you across sites, and we do not profile you inside Emcognito either, beyond the narrow abuse signals described under "Keeping the service safe."
• We do not use third-party advertising trackers or ad pixels on this site.

How we use what we collect

Specifically and exhaustively:

• To run the service: route forwarded mail, enforce plan quotas, issue magic-link sign-ins, suspend aliases that are getting bounced by a dead destination inbox.
• To bill you (paid plans only): create a Stripe customer, process subscriptions, deliver receipts.
• To keep the service safe: rate-limit abusive traffic, detect credential stuffing or magic-link enumeration attempts, count the complaints and bounces caused by mail composed through your account, act on payment disputes reported to us as fraudulent, and let an administrator review an account against that evidence and record in writing why a restriction was applied or lifted. What we do with those signals, and what we do not do with them, is set out under "Keeping the service safe" below.
• To support you: reply to your emails, investigate issues you report.
• To improve the service: GA4 analytics tell us which pages people read, which CTAs they click, and which product actions they take in the dashboard, so we can fix confusing flows and prioritize features. We configure GA4 not to identify you by name and do not merge GA events into your account record.
• To comply with legal obligations: respond to lawful requests from authorities with jurisdiction over us; preserve records we're required by law to preserve. Now that some undelivered mail sits with us briefly, it is worth being precise about that mail specifically: US law treats a message awaiting delivery as being in electronic storage, and we will not disclose the contents of a held message to a government authority on a subpoena alone. For content we require a warrant, and we will decline or challenge requests that do not meet that bar. We will of course comply with a valid warrant.

Our legal bases (for EEA/UK users)

If GDPR or UK GDPR applies to you, we rely on the following legal bases:

• Performance of a contract (Art. 6(1)(b)) — to create your account, forward your mail, sign you in by magic link, and bill paid plans.
• Legitimate interests (Art. 6(1)(f)) — to keep the service secure, prevent abuse, enforce plan limits, and understand product usage through analytics, balanced against your privacy rights.
• Legal obligation (Art. 6(1)(c)) — to keep tax and accounting records and to respond to lawful requests.
• Consent (Art. 6(1)(a)) — where we ever ask for it explicitly; you can withdraw consent at any time without affecting prior processing.

Keeping the service safe

Emcognito's ability to deliver anyone's mail depends on the sending reputation of the whole service, so we keep a small amount of information about abuse. It is worth being precise about what it is, because it is information about you rather than about your mail.

• Complaint and bounce counts. When mail you compose through Emcognito is reported as spam or bounces, we add one to a counter on your account, alongside the number of messages you have sent since the counter last reset. We use it to work out whether composing from your account should be paused, and to show an administrator the evidence behind that. We do not read the message, and the counter carries no recipient, subject, or content. Recipients who report a complaint are added to a do-not-send list for Compose.
• Payment disputes. If a charge is disputed we store the Stripe dispute identifier and whether it is open or resolved. Disputes reported as fraudulent place the account on hold, as described under "Decisions we make automatically."
• Administrator notes. When an administrator restricts an account, lifts a restriction, or bans an address, they record a short written reason — up to 280 characters — on the account. It is there so the next person to look at the account knows what happened. It is not shown to you in the app, but it is your personal data: ask us and we will send it to you.
• What this is not. There is no risk score, no ranking, no model, and no profile built from your browsing or your mail. We do not check your address against outside blocklists or fraud databases, we do not buy or receive risk data about you from anyone, and we do not share these signals with other companies. Bounces at your own destination inbox are a separate thing entirely: they say something about your mailbox provider, not about you, and we never treat them as evidence of abuse.

Decisions we make automatically

Incoming-volume protection. Per-alias and per-account burst limits can pause processing before further forwarding quota is spent. This protects recipients and service capacity; it is not a finding that the account holder is abusive. You can review aliases and explicitly resume a limited batch, or contact support. When the mail host is under queue or disk pressure, it can temporarily refuse new SMTP intake so the sending server can retry; delivery and retries depend on that sender.

Referral rewards. New rewards require both accounts to be at least seven days old and the referred account to receive at least five qualifying forwards across three distinct days. An account can qualify at most four referral rewards. Related-account checks, reciprocal referrals and review flags can defer rewards for review; existing earned bonuses are not removed by this change.

The decisions below can be made by software without a person reviewing them first. Payment-dispute holds affect the account; composing locks affect composing; shared free-allowance protection affects available free forwarding capacity.

Automatic shared free-allowance protection. When enabled, this rule requires two verified Free accounts with matching non-generic email prefixes across different providers, matching unexpired authenticated browser observations, and a recorded forward exhausting one account's allowance before a later forwarding attempt on the other. The first account must still be at its cap and combined usage must reach the applicable shared allowance. Similar names, a shared network, or a browser match alone do not trigger this rule. This is a deterministic quota decision, not proof of common ownership or a finding of fraud.

Effect and review. Existing usage counts toward one shared free allowance. If it is exhausted, new mail follows the normal over-cap holding policy: up to 72 hours, then discarded if it cannot be released. The accounts, sign-ins, aliases, and mail remain separate, and paid plans keep their own allowances. The shared relationship persists through monthly resets unless restored after review. You can request human review, explain a shared computer or another mistaken connection, and ask us to restore separate allowances by emailing hello@wm.emcognito.com; you do not have to pay to request a review. Requesting review does not itself pause the mail-retention deadline. Your dashboard explains personal and shared usage without exposing another member's email address.

What it is. If a card issuer notifies us that a charge on your account has been disputed as fraudulent, we place your account on hold immediately and automatically. Forwarding, replies, composing, alias changes, developer API keys, and new purchases stop; reading your account, contacting support, and managing your card stay available. Mail that arrives during a hold is discarded.

The logic, in full. There is no risk score, no model, and no profile. The rule is a single condition: a payment dispute notice from Stripe that carries the reason code fraudulent. A failed payment does not trigger it. A dispute filed for any other reason — a service or product complaint, a duplicate charge — does not trigger it. No other signal we hold, including complaint counts, the country you are in, the kind of card you used, or the email address you signed up with, feeds this decision.

Why it works this way. A dispute alleging fraud usually means someone's card was used without their permission. Continuing to send mail on an account bought that way costs the cardholder more money and damages the sending reputation every other Emcognito user depends on. Waiting for a person to review first would leave that running for days.

What you can do about it. You have the right to have a person review this, to tell us your side, and to challenge the outcome. Email hello@wm.emcognito.com. A member of our team — not software — reads the account, decides, records a written reason, and tells you the result. A hold also lifts on its own if the dispute closes in our favour. It does not lift on its own in any other case, so if you think a hold is wrong, write to us rather than wait.

The other two decisions concern composing. If you use Emcognito to write and send a message, two further checks run without a person. First, before the message leaves we look at its subject line and count the web links in its body — not to read what you wrote, and not keeping any of it — to catch the shapes bulk spam takes; three messages refused this way within a day lock composing. Second, composing locks automatically if two people who received your composed mail report it as spam, or if more than 5% of it bounces once you have sent at least 50 messages. Neither lock touches forwarding to your own inbox or anything else on your account. Ask us to review either one and a person will — and unlocking clears the counts that caused the lock, so you do not lock again the moment you resume.

Administrator review. Administrators can confirm a shared allowance or restore separate allowances with a recorded reason. Banning an address and pausing a bouncing destination are decided or confirmed by a person, using the evidence described under "Keeping the service safe."

Mail written by other people

A message forwarded through one of your aliases was written by somebody else. That sender is not an Emcognito user, has not agreed to our Terms, and usually does not know Emcognito is in the path at all. Their message is still personal data that we handle, and since we now hold some of it briefly rather than passing it straight through, we would rather set out exactly what that means than leave it to inference.

• What we do with it. We accept the message, hand it to AWS SES for delivery to your real inbox, and delete it. If your account is over its monthly forward cap, we instead hold it undelivered for up to 72 hours so it can still reach you, as described under "How long we keep things." If your account is on hold following a payment dispute, we discard the message on arrival instead: we do not deliver it, we do not keep it, we do not send the sender a bounce or any other notice, and we do not write a delivery record for it — so a discarded message leaves no trace in your Delivery Log either. Otherwise we record a delivery record noting the sender's address, the subject line, the alias it was addressed to, and the outcome — described in the next bullet. Separately, unusually high incoming volume can pause processing before quota is spent; accepted messages wait under the safety-pause retention criteria below, rather than the 72-hour quota window. Apart from that record, we do not read it, scan it, index it, profile from it, train anything on it, use it for analytics, or keep it for any purpose other than delivering it to you.
• The delivery log. For every message handled for one of your aliases we keep the sender's address, the subject line, the alias addressed, the outcome, and the time for a plan-based retention window — 30 days on Free, 6 months (180 days) on Plus, and 12 months (365 days) on Pro — so you can see what happened to your mail. This retains some sender-written text after the message itself is gone; the separate failed-feedback queue described above can also contain email headers and subject lines. We keep the delivery log to the minimum that answers the question "what happened to this message", never store the body in it, and delete each entry automatically when the window that applied when it was written ends. Upgrading extends the window for new records only: it does not extend records already written and cannot restore records already deleted. It is enabled for every account by default; there is no setting that turns this log off. The Art. 14 notice below covers this data too.
• Our legal basis for the sender's data (EEA/UK). Legitimate interests (Art. 6(1)(f)): the recipient's interest in receiving mail addressed to them, and the sender's own interest in having the message they sent actually arrive. We do not rely on your contract with us (Art. 6(1)(b)) as the basis for handling a third party's personal data, because the sender is not a party to that contract.
• Why the quota-hold window is 72 hours. It is the shortest period that still gives an account holder a realistic chance to see the cap notice and act on it before the mail is lost — roughly a long weekend. It is a ceiling, not a target: held mail is released the moment your account has capacity again, and quota-held mail is not kept beyond that window. This deadline does not apply to mail waiting under the separate incoming-volume safety pause.
• Our role, and why the limits above are the point. European guidance takes the view that where a provider's only role is to enable the transmission of a message, the provider is not the controller of the personal data inside that message — the person who wrote it is. We keep to that role deliberately. The list above is not modesty about what we happen not to do; it is the boundary that keeps us a carrier of your mail rather than a reader of it, and we would have to tell you here if that changed.
• Notice to senders (GDPR Art. 14). For the routing data we do control — which alias was addressed, when, the sending address, the outcome, and the subject line — we have no relationship with senders and no practical way to notify each one individually. Writing to them would mean sending unsolicited mail to people who never contacted us, and would reveal that their message passed through an alias, undoing the privacy the service exists to provide. We publish this policy as that notice. If you are a sender and you want to know whether we are holding a message of yours, or want it deleted, email hello@wm.emcognito.com and we will act on it.

Mail you write yourself

Emcognito can also send mail from one of your aliases, if you write it here. That mail is handled differently from mail forwarded to you, and this section says how.

• We check it before it goes out. When you press send, our software looks at the subject line and the body: it rejects a subject containing control characters or written entirely in capitals, and it counts the web links in the body, rejecting a message with too many of them or one whose links are all URL shorteners. That is the whole test. It runs in memory at the moment you send and produces only a yes or no; this check does not store or log the subject or body. Separate provider feedback can contain headers and subject lines as described under "Failed email-feedback processing." If a message is rejected we tell you and we do not send it.
• We count what happens to it afterwards. If someone you sent to marks the message as spam, or if it bounces, we increment a counter on your account. We keep the count, not the message and not the recipient's address in readable form. These counters are what the automatic composing locks described under "Decisions we make automatically" are based on.
• What we do not do. We do not read composed mail for any purpose other than the check above, we do not keep a copy after sending, and we do not use anything in it to build a profile of you.

Subprocessors — the third parties we use to run Emcognito

We use a small number of named third parties ("subprocessors") to run the service. Each has access only to the categories of data it needs to do its job. We list them so the policy you read matches what you'd find with a network inspector.

• Amazon Web Services (AWS). Hosts the web app and static assets (S3 and CloudFront), API compute, account and alias data (DynamoDB), outbound delivery (SES), and the failed-feedback recovery queue (SQS) introduced by this notice. AWS processes account and alias records, API request metadata, forwarded messages handed to SES for delivery, and the operational email-feedback metadata described above.
• DigitalOcean. Hosts the Postfix mail forwarder. It processes incoming message bodies and routing metadata while messages are delivered or waiting under the quota hold or incoming-volume safety pause.
• Stripe, Inc., United States. Payment processing for paid plans. Stripe sees billing email, card details (which they hold, we never see), and subscription state. Stripe's privacy policy: stripe.com/privacy.
• Google LLC (Google Analytics 4). Processes browser analytics only after explicit consent. GA4 receives event and network metadata, but not forwarded message contents. Google's privacy policy: policies.google.com/privacy.
• DNSCove. Provides authoritative DNS for emcognito.com. DNS resolvers may send DNS request metadata; DNSCove does not receive Emcognito account records through the product.

Provider processing locations depend on each provider's infrastructure and policies. We do not use AI-model providers (OpenAI, Anthropic, etc.) on user data. If we add or change a material subprocessor, we will update this list and the date at the top.

International data transfers

Emcognito is operated by a US company and uses providers whose processing locations vary by service and provider policy. If you use the service from a country with data-transfer rules, your information may be transferred internationally. You can ask about the safeguards relevant to your account at hello@wm.emcognito.com.

How long we keep things

The database retention and deletion periods below describe live service records. Recovery copies are separate, as explained under Database recovery copies. Expired security evidence is not used for matching, even while physical deletion is pending.

• Forwarded email bodies (delivered normally): not retained. Stored on disk only between Postfix receipt and SES handoff (seconds), then deleted. Undelivered messages may wait under the quota hold or the separate incoming-volume safety pause described below.
• Forwarded email bodies held at your monthly cap: up to 72 hours. If a message arrives when your account is over its monthly forward cap, we do not delete it and we do not deliver it — it waits in a holding area on our forwarder host. It is delivered as soon as your account has capacity again (because you upgraded, or because your monthly cap reset), and it is deleted once it has been waiting 72 hours, whichever comes first. We do not read it while it waits. Two limits you should assume rather than hope against: the holding area is bounded in size and in message count, so when it is full, further over-cap messages are refused at the door and are permanently lost — we cannot recover them and we do not notify the sender or you which messages were lost; and a message held for the full 72 hours without your account regaining capacity is deleted undelivered. The hold is a best-effort second chance to receive mail you were otherwise over your limit to receive. It is not a mailbox, not a backup, and not a delivery guarantee.
• Incoming-volume safety pause: accepted messages remain on the forwarder while processing is paused. You can review or suspend affected aliases and explicitly resume a limited batch from the dashboard; another burst can pause processing again. This queue does not automatically expire after 72 hours. Mail remains until successful delivery or verified mail-host deletion following support review or a deletion request. Suspending or deleting an alias does not by itself erase previously accepted safety-paused mail. An independent age alert flags messages waiting over 72 hours for operator review; the alert does not itself delete them. This is not a backup or a delivery guarantee. We keep bounded admission counters, account/alias identifiers, file identity and pause/queue timestamps to operate this protection, not a content-derived risk profile.
• Referral qualification: we retain the referral relationship, a capped count of the first five qualifying forwards and up to three distinct activity dates, reward issuance records and review status while the account exists. We use these with account age to qualify rewards, limit issuance and flag referral cycles or unusually large referral groups for human review. Test messages do not qualify. No message content is used in this decision.
• Billing reconciliation: checkout attempt identifiers, account/customer/subscription bindings and recovery status remain until the billing operation is resolved; unresolved operations do not automatically expire. An unresolved operation can delay account-record deletion while we reconcile it with Stripe, so an outstanding subscription is not silently abandoned.
• Account row (your account email and plan state): retained while your account is active and removed when an account-deletion request is processed, except records we must retain for security, billing, or legal obligations.
• Banned addresses: for as long as the ban is in force, and not deleted when the account is deleted. A row holding the email address, the time of the ban, and the reason. This security record outlives account erasure for the reason given under "Right to deletion"; other retained records and recovery copies are described separately.
• Payment-dispute markers: while a dispute is open, and after it closes as a record that it happened. We store the Stripe dispute identifier, whether it is open or resolved, and — where an administrator has reviewed and lifted a hold — who did that, when, and the reason they recorded, up to 280 characters.
• Abuse counters: until reset. Counts of complaints and bounces generated by mail you composed through Emcognito, together with the send count they are measured against. These are reset when an administrator clears a related restriction.
• Administrator notes: while the account exists, and removed with the account when it is deleted. Short free-text notes recording why a restriction was applied or lifted.
• Alias rows (your aliases and their labels): retained while your account is active or until you delete each alias.
• Delivery log (on by default): 30 days on Free, 6 months (180 days) on Plus, and 12 months (365 days) on Pro. For every message handled for one of your aliases, we store a delivery record — the sender's address, the subject line, which alias it was addressed to, the outcome (forwarded, held, released, expired, or rejected), and the time it was recorded. We do not store the message body — there is no field for one. Each entry is deleted automatically at the end of the retention window that applied when it was written. Because the window is fixed at write time, upgrading keeps new records longer but does not extend records already written and cannot restore records already deleted — the delivery log is forward-only. There is no setting that turns this off; it is enabled for every account by default, and the plain count of how many messages you missed, described under "Information we collect automatically" above, is kept alongside it either way. You can read, search, and filter the delivery log in the dashboard's Delivery Log — by alias, outcome, or date — and export the full window your plan keeps under whatever filters you have applied as a CSV at any time. Note that this record necessarily contains information about the people who wrote to you, not only about you; we do not use it for anything other than showing you what happened to your mail.
• Missed-message count (always on): until your monthly cap resets. A single number per account, with no sender, subject, alias, or timestamp attached to it. There is nothing to delete individually and nothing to switch off; deleting your account removes it with the rest of the account record.
• Custom-domain research waitlist response: retained while your account is active or until you edit or delete it using "Leave research waitlist" in Billing Settings or delete your account.
• Magic-link tokens: 15-minute TTL; deleted automatically once consumed or expired.
• Failed email-feedback reports: the encrypted AWS SQS recovery queue described above has a retention limit of 7 days. This queue limit is not measured from when the original email was sent; it does not extend the separate delivery-log retention window or preserve the forwarded message body. Account deletion does not immediately clear queued reports.
• Standard request logs: retained according to the relevant AWS, DigitalOcean, and application configuration; we do not promise one universal retention period.
• Stripe billing records: retained by Stripe under its policy and by us where needed for subscription administration, accounting, disputes, and applicable legal obligations.
• Support emails: retained for up to 2 years after the last reply, then deleted.

Database recovery copies

We use AWS DynamoDB continuous backups to recover from accidental deletion or database damage. Where enabled, these retain historical database checkpoints in a rolling window of up to 35 days. This is a window of recovery points, not a limit measured from when information was first collected. A record removed from the live database may remain in an earlier checkpoint until that checkpoint ages out. These copies can include account, alias, billing and quota metadata, and network or browser evidence stored in the protected tables; they are not backups of forwarded message bodies.

The 35-day window does not apply to every backup. Older separately created backups can remain longer; we are reviewing their inventory and retention and cannot yet state one verified deletion deadline for all historical copies. Removing live records does not immediately erase those copies.

Our recovery procedure restricts recovery copies to recovery work, not normal account access, marketing, or related-account matching. Before a restored database can return to live service, an operator must verify that applicable deletion requests and account or credential revocations have been reconciled. This is a manual release requirement, not a claim that an automated deletion replay is in place. If that verification cannot be completed, the restored database must remain isolated. Contact support about the status of recovery copies when requesting deletion.

Your rights

Wherever you sign up from, we apply the following:

• Right to access: email hello@wm.emcognito.com and we'll send you a copy of what we have on you. That includes anything an administrator has written about your account, any restriction on it and the reason for it, and the complaint and bounce counts we hold — not only your aliases and settings. If a hold has been applied to your account automatically, we will also explain how that decision was reached.
• Right to deletion: from inside the app you can delete individual aliases at any time. To wipe your entire account record and every associated alias, email support and we'll do it. We will respond within 30 days, explaining what has been deleted and any remaining records or recovery copies. Deletion of account database records alone does not verify deletion from the mail host. Support must separately verify removal of accepted undelivered mail before confirming that part of your request complete. Quota-held mail otherwise expires after 72 hours; safety-paused mail requires separate processing or verified deletion and has no automatic 72-hour expiry. Some records and recovery copies survive live-account deletion as described above. In particular, if we have banned your email address for abuse, we keep that address on a denylist after your account is gone. We keep the address itself, the date, and the reason — nothing else, and no aliases, mail, or usage history. We do that so a banned address cannot simply delete its account and sign up again, and we keep it for as long as the ban is in force. You can ask us to review a ban at any time by writing to hello@wm.emcognito.com.
• Right to correct: you can edit alias labels and notes inside the app at any time. Email support to correct anything you can't change yourself.
• Right to portability: email support and we'll export your aliases as JSON or CSV.
• Analytics choice: GA4 does not load before you explicitly accept it. Use "Analytics preferences" in the footer to accept, decline, or withdraw that choice. A tracker blocker can provide an additional control.
• Right to object / restrict (EEA/UK): where we process data on the basis of legitimate interests, you may object to that processing or ask us to restrict it; email support and we'll review the request.
• Right to lodge a complaint: EU/EEA residents may complain to their national data-protection authority and UK residents to the ICO. California residents have the rights described under the CCPA/CPRA — including the right to know, the right to delete, the right to correct, and the right to non-discrimination for exercising those rights. We do not sell or share your personal information, and we do not use it for cross-context behavioral advertising, as those terms are defined under the CCPA/CPRA — so there is nothing to opt out of on that front.

We don't charge for fulfilling rights requests and we don't ask for legal-style documentation — your account email is enough.

How we protect your data

• In transit: HTTPS (TLS) for the website and API. Forwarded mail uses SMTP over TLS to AWS SES.
• At rest: account and alias records are encrypted at rest in DynamoDB. Undelivered mail held at your monthly cap or during an incoming-volume safety pause is different, and we would rather say so plainly than let the line above imply otherwise: it sits as a file on our forwarder host, protected by host hardening and access control rather than by any encryption we apply. We do not claim held mail is encrypted at rest. Whatever encryption exists at that layer is whatever our hosting provider applies to its own volumes, and we have not independently verified it. If that matters to your threat model, treat the hold as unencrypted storage.
• Access: only the operator can read the production database. We do not use third-party customer-data tools (no Segment, no CRM, no support desk with full-account visibility).
• Sign-in: magic links are single-use, expire after 15 minutes, and are consumed when verified. You may also register passkeys. Emcognito stores public passkey credential data, never the private key, PIN, or biometric; a platform provider may sync a passkey across your devices. Sessions are signed JWTs with a 7-day TTL.

No service can promise zero breaches. If we discover a personal-data breach that affects you, we will notify you by email without undue delay — and within any timeframe required by applicable law — describing what happened, what data was involved, and what you should do. Where a breach reaches the over-cap holding area it may also involve messages written by people who are not our users and whom we have no way to contact; in that case we will describe the exposure in our notice to you and to the relevant supervisory authority, and we will say so publicly on this page.

Cookies

We use local-storage entries to keep you signed in (the emcognito_session entry contains your session JWT), remember preferences, and, when browser-evidence collection is enabled, hold the 30-day emcognito_browser_evidence_v1 random browser identifier for account-abuse review described above. The browser identifier is separate from analytics, is not shared with advertising services, and is not derived from your device characteristics. You can remove it by clearing this site's storage; unavailable storage does not block sign-in. Google Analytics is deferred until explicit consent and may then set analytics cookies across public and signed-in pages. Declining or withdrawing analytics consent prevents future GA events and removes accessible GA cookies where possible; it does not control the separate security identifier. We do not set advertising cookies or collect browser/device fingerprints.

Children

Emcognito is not directed at children under 16. We do not knowingly collect personal data from anyone under 16. If you believe we've collected data from a child, email support and we'll delete it.

Changes to this policy

When we change this policy we update the "Last updated" date at the top. Some changes only make this page more accurate — for example, stating the retention period that already applies to your plan — and we make them as soon as they are true. For material changes that amount to a new use of your personal data, a new category of collection, or a new subprocessor, we will also email registered users at least 30 days before the change takes effect. We will not use your data for a new purpose without telling you first.

Contact

Privacy questions, deletion requests, complaints, or anything else: hello@wm.emcognito.com.