Privacy policy.

Last updated: November 4, 2026 — the held-mail paragraph now also covers an account whose Free plan has ended under Section 16 of the Terms of Service. October 29, 2026 — how long mail waits during an incoming-volume safety pause (up to 72 hours in the pause, then up to 72 more in the holding area before it is deleted undelivered), and that once held mail has been deleted, further mail to your aliases may be refused and the sender normally told; also what happens to mail sent to a new account (opened on or after 12:00 UTC on October 29, 2026) that has no paid plan: it is held undelivered for up to 72 hours, and afterwards further mail may be refused (earlier: October 17, 2026 — the sign-up referrer category, how you arrived attached to a Stripe checkout, and the record of upgrade offers shown to you started without the 30-day email described under "Changes to this policy"; October 10, 2026 — a sign-in email sent to an address that has no Emcognito account now shows the IP address the request came from, is limited to two a day and three a week, and has a link to stop such emails; October 8, 2026 — Siftfy may now also train its spam model on TypeSafe verdicts and on spam corrections reported by its own sites, so TypeSafe verdicts are no longer excluded from training; October 7, 2026 — referral rewards now qualify on one hand-made alias and one real forward instead of five forwards across three days; October 4, 2026 — replying from your own mail app, phone device tokens, new-sender alerts and sending-domain blocks on paid plans, and what we keep for 30 days after a move to Free; September 30, 2026 — immediate ban for payment fraud (a fraudulent chargeback or an issuer early fraud warning), automatic shared allowances and bans for accounts linked by browser or Gmail mailbox, how you arrived at sign-up, and the optional question asked once of paying accounts; September 27, 2026 — Siftfy Content Gate sign-in screening and model-training disclosure, which took effect without the 30-day email described under "Changes to this policy"; before that, 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.
• Why you upgraded (paid plans only, optional). After your first payment we ask once, in the dashboard, what made you upgrade. If you answer, we store the option you chose, any note you add (up to 200 characters) and the time, linked to your account; if you close the question, we store that you did, so we do not ask again. We use the answers only to decide what to build and how to describe the plans, and they are deleted with your account.
• Phone device tokens (Plus and Pro, optional). If you set up the iPhone Shortcut, we store a one-way hash of the device token (never the token itself), the device name you give it (up to 40 characters), when you created it, and when it was last used. The token can only create aliases. Revoking a token deletes this record.
• Blocked sending domains (Plus and Pro, optional). If you block a sending domain on an alias, we store that domain name on the alias, up to 200 per alias, until you unblock it or delete the alias.
• 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.
• How you arrived, at sign-up. When you request a sign-in link for a new account, we store on that account the page or campaign tag you arrived through and a coarse category of the site that referred you: a search engine, Reddit, Hacker News, the Chrome Web Store, GitHub, another site, or direct (no referring site). We never store the referring address itself. It is recorded once, when the account is created, and never changed; if you start a paid checkout, the same two values are attached to the checkout record we create at Stripe. We use it only to count which channels bring people who go on to use or pay for Emcognito, and it is deleted with your account.
• Your IP address, in a sign-in email to an address with no account. When you request a sign-in link for an email address that has never signed in to Emcognito, the email we send to that address shows the date and time of the request, a coarse description of your browser and device (for example "Chrome on Windows"), and the IP address the request came from. Whoever reads that inbox will see them, so if you mistype your own address, a stranger can see your IP address. We include it so that someone who did not ask for the link can tell the request was not theirs and ignore it rather than report it as spam. We do not look up or show a location. A sign-in email to an address that already has an account does not show your IP address.
• Sign-in emails to an address with no account: limits and opting out. We send at most two sign-in emails a day, and three a week, to an address that has never signed in, and we keep the times they were sent for up to eight days so we can count them. Each of those emails has a one-click link (and an Unsubscribe button in mail apps that show one) to stop sign-in emails to that address. If it is used, we keep a one-way fingerprint of the address, not the address itself, so we can refuse to send to it again; we keep it until you ask us to remove it at hello@wm.emcognito.com. A request for a sign-in link to that address then gets the usual reply, but no email is sent.
• 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 one year from when it was first created; use does not renew it. Identifiers created before September 30, 2026 under the earlier 30-day lifetime keep their value and now also last one year from their creation. 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; if the account is banned, that hash is kept on the ban denylist instead, for as long as the ban stands. We use it to share free allowances and extend bans between accounts that use the same browser profile, and administrators can review it; 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. Similar addresses, email prefixes, and network addresses never restrict or ban an account on their own. A matching browser identifier or the same personal Gmail mailbox can: Free accounts linked that way are placed on one shared free allowance at any level of use, and can be banned when an account they are linked to is banned, as described under "Decisions we make automatically" below. 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.

Free accounts whose verified addresses resolve to the same personal Gmail mailbox share one free allowance automatically. 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, except a browser hash held on the ban denylist. 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. Mail that arrives during a separate incoming-volume safety pause waits, undelivered and unread, for up to 72 hours; if processing has not resumed by then, it moves into the same holding area for up to a further 72 hours, about 144 hours in all, and is then deleted undelivered. 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, share free allowances and extend bans between accounts linked by browser or Gmail mailbox, screen requests for a sign-in link with Siftfy Content Gate as described under Sign-in screening by Siftfy Content Gate, 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. Separately from GA4, we keep a record linked to your account of which upgrade offers the dashboard showed you (at most one entry per offer per day, expiring after 400 days), and we count the sign-up channel and the optional upgrade answer described above, to see which offers, channels and reasons lead to paid plans.
• 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 and fraud warnings. If a charge is disputed we store the Stripe dispute identifier and whether it is open or resolved. If a card issuer sends an early fraud warning about a charge, we store the warning identifier the same way. A dispute reported as fraudulent, or an early fraud warning, bans the account immediately and places it 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. Apart from the sign-in check described under Sign-in screening by Siftfy Content Gate, which scores a request for a sign-in link with a model and can use Siftfy's own deny lists and reputation signals, 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. Apart from the dispute and early fraud warning notices a card issuer sends through Stripe about a charge on your account, we do not buy or receive risk data about you from anyone else, 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.

Sign-in screening. Siftfy Content Gate can refuse a request for a sign-in link without a person reviewing it first, as described under Sign-in screening by Siftfy Content Gate. If that happens, try again later or email hello@wm.emcognito.com and a person will look at it.

Referral rewards. New rewards require both accounts to be at least seven days old and the referred account to create an alias itself and receive at least one qualifying forward. 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-fraud bans and payment-dispute holds affect the account; composing locks affect composing; shared free-allowance protection affects available free forwarding capacity; linked bans end access to the account.

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.

Automatic sharing for Free accounts on one browser or mailbox. Verified, signed-in Free accounts that each presented the same unexpired authenticated browser identifier, or whose verified addresses resolve to the same personal Gmail mailbox, are placed on one shared free allowance at any level of use, without a person confirming it. An existing shared allowance is extended or merged to include them. It does not use email spelling, email prefixes, or network addresses. Paid accounts are left out, and a group that an administrator dismissed is not shared again while that decision is retained. An administrator can restore separate allowances. This is a deterministic quota decision, not proof of common ownership or a finding of fraud; a shared or public computer can cause a match.

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 reports a charge on your account as fraudulent, we ban your account and place it on hold, immediately and automatically, before a person reviews it. The ban refuses sign-in, ends existing sessions, and stops forwarding and replies, and the Free accounts strongly linked to yours are banned with it, as described under "Automatic bans for linked accounts" below. The hold stops forwarding, replies, composing, alias changes, developer API keys, and new purchases. After an early fraud warning we also refund the reported charge and cancel your subscriptions. Mail that arrives while the account is banned or on hold is discarded. We do not email you when this happens; sign-in fails.

The logic, in full. There is no risk score, no model, and no profile. The rule has two triggers, and either one is enough: a payment dispute notice from Stripe that carries the reason code fraudulent, or an early fraud warning that a card issuer sends through Stripe for a charge on your account. 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, and the ban never lifts on its own, so if you think either is wrong, write to us rather than wait. If a review shows the fraud report was mistaken, we lift the ban and the linked bans it caused.

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.

Automatic bans for linked accounts. Apart from the payment-fraud ban described above, a person decides to ban an account. When an account is banned, software also bans the Free accounts strongly linked to it: an account that presented the same browser identifier, whose verified address resolves to the same personal Gmail mailbox, or that is on an enforced shared allowance with such an account, followed link by link. This runs when the ban is made and again in a daily check. Nothing else feeds it: no similar spelling, email prefix, network address, usage level, risk score, or model. Paid (Plus or Pro) accounts and groups of more than 10 accounts are not banned this way; a person decides them. A match an administrator dismissed is not banned, and neither is an account an administrator unbanned on its own. When an account is banned, the keyed hash of its most recent browser identifier, if we hold one from the last 30 days, is kept on the ban denylist for as long as the ban stands, and a new account that signs in presenting that identifier is banned and its sign-in refused. A ban refuses sign-in, ends existing sessions, and stops forwarding and replies. We do not email you when an account is banned; sign-in simply fails. This is a deterministic rule, not proof of common ownership or a finding of fraud; a shared or public computer can cause a match.

Contesting a linked ban. You have the right to have a person review a ban, including one applied automatically, to tell us your side (for example, that you share a computer), and to challenge the outcome. Email hello@wm.emcognito.com from the banned address, or tell us which address it is. A member of our team, not software, reviews it, decides, and replies. Lifting the original ban also lifts the linked bans it caused, and an account unbanned on its own is not banned again by linkage.

Administrator review. Administrators can dismiss a match or restore separate allowances with a recorded reason. Apart from the payment-fraud ban described above, the original decision to ban an address, and pausing a bouncing destination, are made or confirmed by a person, using the evidence described under "Keeping the service safe." The linked bans and sign-in bans that follow from a ban are automatic, as described above.

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." A held message that is not delivered in time is deleted, and its sender is not told. After that, we may refuse further mail to the same account's aliases when it arrives, with an "over quota" error, until the account's held mail has cleared; the sender's mail server will normally tell the sender the message could not be delivered. 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 then wait for up to 72 hours under the safety pause and, if processing has not resumed, up to a further 72 hours in the holding area, as described under "How long we keep things." 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. Mail waiting under the separate incoming-volume safety pause first has its own 72-hour limit, and enters this window only when that limit ends.
• 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.

Replies from your mail app, new-sender alerts, and blocks

• Reply addresses (Plus and Pro). To let you reply from your own mail app, a forwarded message can carry a reply address unique to it. For each one we keep a one-way hash of the address, the alias, the original sender's address (so your reply reaches them), and when it was created, for up to 365 days, and less if you pause or delete the alias. We keep no message body.
• Checking a reply really came from you. When a reply arrives at one of these addresses, our software reads its envelope sender, its From line, and the SPF and DKIM results for your mail provider, to confirm it came from the address you sign in with. We remove your own address and your mail provider's routing headers before sending the reply on from the alias. A reply that fails these checks is refused and is not stored. A reply we send counts toward your monthly sends like a composed message.
• New-sender alerts (Plus and Pro). When a company sends mail to one of your aliases for the first time, we may email you an alert. It shows the sender's address and the subject line of that first message, taken from the same delivery record described above, so you can tell whether the address leaked. We keep that sender and subject in the outgoing alert only until it is sent. The alert's Pause and Block links carry a signed token that expires after 30 days; the pages they open set no cookies and load no tracking.
• Blocked mail. Mail to an alias from a domain you blocked is deleted on arrival without being forwarded or read. We write a delivery record for it with the outcome blocked_sender, kept for the delivery-log window of your plan.

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.

Sign-in screening by Siftfy Content Gate

The forms that email you a sign-in link — sign-in, sign-up, and the email step of the upgrade page — are screened by Siftfy Content Gate, a bot and spam check. Siftfy is operated by VectraSEO LLC, the same company that operates Emcognito, so it is not a separate third party. Siftfy's privacy policy at siftfy.io/privacy is the authoritative statement of how Siftfy handles what it receives; this section summarizes it for these forms.

• What is sent. The only text these forms send is the email address you enter, with surrounding spaces removed and letters lowercased. Your browser loads the check from siftfy.io and sends Siftfy a one-way SHA-256 fingerprint of that address, not the address itself. Once the address passes our own format check, our server sends Siftfy the address so it can confirm the check and return an allow, review, or block result. Because your browser connects to siftfy.io directly, Siftfy also sees your IP address, from which it derives a pseudonymous identifier as its policy describes. A block result can stop the link from being sent.
• What Siftfy keeps from these forms. Since 2026-09-23, Siftfy does not collect a submission whose entire text is a single email address. A request from these forms is only ever that, so it is not kept for evaluation, cannot be labeled, and is not used for training. Before that change, Siftfy kept the address from these requests for up to 30 days for evaluation, and a Siftfy reviewer could label it; an address labeled between 2026-09-22 and 2026-09-27 is covered by the exception below.
• Training on labeled submissions. From 2026-09-27, Content Gate submissions that a Siftfy reviewer has labeled legitimate or spam may be used to train Siftfy's spam, AI-authorship and automation (bot-detection) models. Unlabeled submissions, and submissions labeled uncertain, are not used. Evaluation copies are kept for 30 days; the training copy is kept for 12 months from collection and then deleted. Credentials are removed first, but the text is not anonymized.
• An exception, stated plainly. Submissions a Siftfy reviewer labeled between 2026-09-22 and 2026-09-27 are also used for training, although they were collected before this use was disclosed.
• TypeSafe verdicts. Siftfy sends some submissions to TypeSafe AI, a third-party classifier, for a judgment, as its policy describes. From 2026-10-08, TypeSafe verdicts on Content Gate submissions from Siftfy's own sites, Emcognito included, may be used to train Siftfy's spam model. Where TypeSafe judged a submission spam or legitimate, that verdict may be copied as a label, with the submission text, into the same training copy and kept for 12 months from collection. Only the verdict is kept, not TypeSafe's confidence or model name, and a Siftfy reviewer's label takes its place where there is one. Verdicts TypeSafe gave before 2026-10-08 are included while Siftfy still holds the submission's 30-day evaluation record, but only for submissions collected from 2026-09-27. Because Siftfy has kept nothing from these forms since 2026-09-23, no sign-in address is used this way.
• Corrections reported by Siftfy's own sites. From 2026-10-08, spam and not-spam corrections reported by Siftfy's own sites, today Folio and EchoThread, may be used to train Siftfy's spam model; the reported text, with credentials removed, is kept for 12 months from the latest report. When our own server tells Siftfy that a sign-in link drew a complaint or bounced, it sends a reference to the check, not text, and that report is not used for training.

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. Emcognito does not send user data to AI-model providers (OpenAI, Anthropic, etc.). Siftfy, which screens the sign-in forms, is operated by VectraSEO LLC and so is not listed here as a third party; its use of TypeSafe AI for some Content Gate submissions is described under Sign-in screening by Siftfy Content Gate. 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 deleted on arrival and are permanently lost — we cannot recover them; and a message held for the full 72 hours without your account regaining capacity is deleted undelivered. We do not email you or tell the sender about each lost message; each one is recorded in your Delivery Log. After a held message has been deleted at the end of its window, further mail to your aliases may be refused when it arrives, in which case the sender's mail server will normally tell the sender the message could not be delivered, until your held mail has cleared. 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.
• Forwarded email bodies for an account without a paid plan: up to 72 hours. If your account was opened on or after 12:00 UTC on October 29, 2026, or its Free plan has ended under Section 16 of our Terms of Service, and it does not have an active Plus or Pro subscription (including a Pro free trial) — because you have not subscribed yet, because a subscription or trial has ended, or because your Free plan has ended — we do not forward mail sent to your aliases. Each message instead waits, undelivered and unread, in the same holding area and under the same limits as mail held at a monthly cap. It is delivered as soon as practicable if you subscribe within 72 hours of its arrival, and is otherwise permanently deleted, undelivered, when those 72 hours end. We do not email you when this happens. A delivery record of each message (sender, subject, alias, outcome and time) stays in your Delivery Log for 30 days. After a held message has been deleted this way, further mail to your aliases may be refused when it arrives, in which case the sender's mail server will normally tell the sender the message could not be delivered, until your held mail has cleared or you subscribe. Mail paused under the separate incoming-volume safety pause follows the rules for that pause instead.
• Incoming-volume safety pause: up to 72 hours, then up to 72 more in the holding area. While processing is paused, an accepted message waits, undelivered and unread, on the forwarder. You can review or suspend affected aliases and explicitly resume a limited batch from the dashboard; another burst can pause processing again. If processing has not resumed within 72 hours of a message's arrival, the message moves into the same holding area, under the same limits, as mail held at a monthly cap, and a new 72-hour window starts. It is delivered if processing resumes and your account has forwarding capacity within that window, and is otherwise deleted undelivered when the window ends, so a paused message can wait about 144 hours in all. If the holding area is full when the message moves, it is deleted then. We do not email you or tell the sender about each deleted message; each one is recorded in your Delivery Log. After a held message has been deleted at the end of its window, further mail to your aliases may be refused when it arrives, in which case the sender's mail server will normally tell the sender the message could not be delivered, until your held mail has cleared. You can ask support to delete waiting mail sooner. Suspending or deleting an alias does not by itself erase mail already accepted for it. 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, the time the referred account first created an alias itself and first received a qualifying forward, a capped activity counter (at most five forwards and three dates, no longer used to qualify rewards), 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, the reason, and, for a ban that followed from a linked account, that account's address. If we held a browser identifier hash for the banned account from the last 30 days, that keyed hash, the banned address, and the time are also kept on the denylist; lifting the ban deletes them. 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, rejected, or blocked_sender), 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.
• Reply addresses: up to 365 days after the forwarded message, and deleted earlier with the alias.
• Phone device tokens: until you revoke them or delete your account.
• Blocked sending domains: until you unblock them or delete the alias.
• After a move from Plus or Pro to Free: reply addresses, phone device tokens, and blocked sending domains stop working but are kept for 30 days, so they work again if you return to a paid plan within that time. After 30 days on Free we delete them.
• 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. Otherwise, quota-held mail is deleted after 72 hours, and safety-paused mail after up to 72 hours in the pause plus up to 72 hours in the holding area. 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, the reason, the address of any banned account the ban followed from, and the keyed hash of the account's browser identifier if we held one — nothing else, and no aliases, mail, or usage history. We do that so a banned address or browser 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 emcognito_browser_evidence_v1 random browser identifier, which lasts one year from when it was first created, for the free-allowance sharing, ban enforcement, and 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.

Changes on November 4, 2026. The held-mail paragraph now also covers an account whose Free plan has ended under Section 16 of the Terms of Service. This is not a new use or a new category of personal data: the same messages, the same 72-hour hold, and the same deletion rule already applied to a new account without a paid plan; the paragraph now states that the rule also applies to these accounts. We did not email registered users 30 days before this accuracy update.

Changes on October 4, 2026. The records listed under Replies from your mail app, new-sender alerts, and blocks, phone device tokens, and blocked sending domains are new categories of collection. We did not email registered users 30 days before adding them. We chose to start them now because each one is collected only from a Plus or Pro account that turns the feature on, after this policy describes it, and nothing already collected is put to a new use. If you never use these features, nothing about your data changes.

Changes made without that email. The Siftfy training use described under Sign-in screening by Siftfy Content Gate is a new use of personal data. It was published on 2026-09-27 and took effect the same day. We did not email registered users 30 days before it took effect, as the paragraph above promises, and we have not emailed them since; we chose to start without that notice. For the sign-in forms the effect is narrow: since 2026-09-23 Siftfy keeps nothing they send, so the only addresses that can be used are those a Siftfy reviewer labeled between 2026-09-22 and 2026-09-27. The change published on 2026-10-08, training on TypeSafe verdicts and on corrections reported by Siftfy's own sites, also took effect when it was published, without that email; it adds no sign-in address to what can be used. We said then that future changes of this kind would get the 30-day email. The changes published on 2026-09-30 did not: automatic shared allowances and bans for accounts linked by browser or Gmail mailbox, the ban-denylist browser hash, the one-year browser identifier, and the immediate ban for payment fraud each took effect when they were published. We chose to start them without that email because they protect against fraud and ban evasion, and a 30-day delay would have left those accounts running. The change published on 2026-10-10, showing the requesting IP address in a sign-in email to an address with no account, is a new disclosure of personal data and also took effect when it was published, without that email, as did the opt-out fingerprint described with it. We chose to start it now because unwanted sign-in emails to strangers were being reported as spam, and those reports put the delivery of every sign-in email at risk. It affects only a request for a sign-in link to an address that has never signed in. Three records this policy has described since 2026-09-30 start on 2026-10-17, the day this change was published, without that email: the coarse category of the site that referred you (under "How you arrived, at sign-up"), how you arrived attached to a Stripe checkout you start, and the record of which upgrade offers the dashboard showed you. Each is a new category of collection. We chose to start them now, rather than 30 days after an email, so we can see which offers and channels lead to paid plans. You can ask a person to review any ban or shared allowance at any time by writing to hello@wm.emcognito.com.

Contact

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