Privacy notice

Junkmail is a private, receive-only disposable-email service operated as a pseudonymous cypherpunk project. No personal or corporate operator identity is published. This notice explains the data the service handles and the controls available to you. It does not turn your aliases into public inboxes, and Junkmail does not forward received mail to your real address.

Data we handle

• Account data: your real email address, password hash, verification and password-reset state, optional two-factor setup, plan and preference settings.
• Alias and mailbox data: claimed alias addresses, labels and notes, received message content and headers, extracted verification codes and links, attachments, tags, and mailbox state such as read, starred, pinned, or archived.
• Security and operations data: session identifiers stored only as hashes, IP address and browser information for session security, rate-limit state, delivery and abuse counters, and service diagnostics.
• Integrations you configure: API-token metadata, webhook URLs and delivery state, and browser push-subscription endpoints and keys.
• Mailbox sharing: a pseudonymous handle generated for your account the first time you take part in sharing, keyed digests of invite-me tokens you generate, the invitations you send or receive, the shares you hold, handles you have blocked, and a record of which of your guests' webhooks and API tokens reach a mailbox you own. Junkmail keeps only a keyed digest of an invite-me token; the words themselves are shown to you once, through short-lived encrypted storage bound to your session, and are not recoverable afterwards.
• Optional billing data: the selected Premium or Pro tier, a random order identifier, BTCPay invoice identifier and status, quoted amount and currency, settlement and paid-through times, and typed webhook-delivery metadata. Junkmail never stores your wallet private key, seed phrase, card, or payment credential.

Passwords, personal access tokens, recovery codes, and webhook signing secrets are stored only in hashed or encrypted form appropriate to their use. A newly issued token, recovery code, or webhook secret is shown only when it is created.

Mailbox sharing

You can give another Junkmail account access to one of your mailboxes. It only happens on your instruction and only after that person generates an invite-me token in their own account and gives it to you, so nobody can push a share at you. Nothing about sharing is ever emailed; invitations appear in the app.

Real email addresses never cross between the two accounts. Each side sees the other only as a pseudonymous handle such as quiet-falcon, which is drawn at random and is not derived from your address.

What a guest can see is the mailbox you shared and nothing else about you: its address and domain, whether it is active, paused or burned, when it last received mail, and every message in it—sender, subject, headers, body, attachments, and extracted verification codes—plus their own unread count. A guest cannot see your label or private note on the alias, your counters, your storage use, your push or self-destruct settings, how many other guests you have, any other mailbox you own, or anything about your account. Depending on the role you choose they may also delete messages from that mailbox, which deletes them for you too. Their read, starred, pinned, and archived marks and their tags on that mail are private to them, as yours are to them.

You remain the controller of the mail in your own mailbox. Sharing does not transfer it: the messages stay stored against your account, count against your storage, and are deleted on your plan's retention schedule—a guest pinning a message does not extend that. You can change a guest's role or remove them at any time, and you can end any single webhook or API token a guest has pointed at your mailbox without removing them. When access ends, for any reason, it ends immediately: the mailbox disappears from the guest's account, their marks and tags on its mail are deleted, and their integrations on it stop.

An operator can see that a share exists, its role and state, and the handles involved, and can end a share or block an account from sharing in response to abuse. There is no operator route to the mail in a shared mailbox, and the audit record of such an action carries identifiers and handles only.

What we use it for

We use this data to authenticate you, receive and display mail for aliases you control, search and organize your mailbox, deliver notifications or webhooks you request, prevent abuse, enforce service limits, protect the service, and operate backups and diagnostics. The receiving domains cannot send or reply, and received messages are never forwarded.

Grounds for processing

Account, alias, mailbox, API, requested-integration, and optional paid-plan data is processed to provide the service you ask for under the Terms of service. Security, fraud prevention, rate limits, aggregate reliability statistics, and service defense keep the shared system safe and available. Minimum billing records are retained for payment integrity and any non-waivable obligations that apply. Optional browser notifications are enabled only at your request and can be withdrawn by removing the subscription or disabling push.

The project does not publish a legal entity, controller address, or chosen jurisdiction. This page describes actual product behavior; it is not a claim that anonymity displaces mandatory privacy rights or laws that may apply according to the facts and your location.

Retention and deletion

In short: unpinned mail is deleted automatically once your plan’s retention window ends—60 days on the launch Free plan—pinned mail stays until you remove it or a storage limit forces eviction, and deleting your account purges the mailbox from the live service. The list below is the exact schedule for every category of data.

• Unpinned messages are automatically deleted after the retention period for your plan; the launch Free plan uses 60 days. Pinned messages remain until you unpin or delete them, reach a storage limit, or delete the account.
• Rejected mail is count-only. Junkmail does not retain rejected message content as a quarantine.
• Sender and recipient metadata in operational logs is kept for no more than 30 days.
• When a share ends—you remove a guest, the guest leaves, the alias is burned or its timer fires, or either account is deleted—the guest's read, starred, pinned, and archived state and their tags on that mailbox are deleted immediately, along with any grant their webhooks or API tokens held on it. The share record itself is retained in a revoked state so the same mailbox is not silently re-opened to a revoked integration.
• When an account is deleted, its mailbox content, stored files, integrations, credentials, and sessions are purged from the live service. Claimed alias addresses remain as anonymized, permanently burned tombstones so they can never be reassigned; labels, notes, and account ownership are removed.
• Immutable operator-audit entries are preserved indefinitely for audit integrity. They contain administrator and affected-account identifiers, the administrator request IP address and bounded browser user-agent string, and safe action metadata. They never contain message bodies, recipient addresses or subjects. An operator-send entry keeps only the desk, plaintext byte size and the identifier of the sent record, which is deleted on its own retention schedule. Once an affected account has been deleted, its numeric identifier no longer resolves to an account record.
• Mail sent to abuse@, postmaster@, or privacy@junksink.com always has a reporting route, whether or not a full mailbox is available. When a mailbox is available, mail is stored in full, including attachments, and is readable by the operator through the account that owns the desks. Otherwise, only the sender address, subject and a bounded plaintext description are kept; raw mail and attachment bodies are not retained. Stored incoming messages and the replies sent from those desks are deleted after ninety days. Pinning or any other mailbox control cannot extend that period. A separate abuse-queue report keeps the sender address, subject and a bounded plaintext description: open reports remain until handled, then resolved or dismissed reports are deleted after 90 days.
• Operational recovery copies, when enabled, follow the documented retention and deletion controls for the active storage configuration. Deleted data is not used for ordinary processing and, if a recovery copy must be restored, deletion controls are reapplied before normal service resumes.
• Account exports requested by you or an administrator are generated by a background worker, kept in private storage for at most 24 hours, and downloadable only by the account owner.
• Typed BTCPay delivery events that are not needed to prove an entitlement are deleted after the configured operational retention period. Checkout URLs and transient error fields are cleared on that shorter operational schedule. On account deletion, an active subscription is removed and retained invoice, entitlement, settlement, and exact-once accounting records are detached from the account and stripped of checkout/error data. The minimum invoice and delivery identifiers, fingerprint, amount, currency, term, status, and accounting timestamps are retained indefinitely for accounting and payment integrity.

Service providers and destinations you choose

Junkmail uses infrastructure needed to host, store, search, and protect the service. Account verification, password resets and operator-desk replies go through a dedicated transactional provider when sending is configured. Desk replies use a dedicated sending domain and direct answers back to the published desk address. Junkmail receiving domains remain receive-only. If you enable browser push, the push service associated with your browser receives only the alias, sender, and subject—not the body or extracted code. If you configure a webhook, its metadata-and-code payload is sent to the HTTPS endpoint you choose.

Premium and Pro checkout is served by Junkmail’s self-hosted BTCPay Server. It processes the invoice, Bitcoin address, payment and network data needed to observe settlement. Bitcoin transactions are also recorded on the public Bitcoin network. Junkmail’s application receives only signed invoice events and reads the canonical invoice status; it does not receive or store a wallet private key or seed phrase.

Hosting, DNS, and transactional-mail suppliers process data needed for their operational role. A webhook destination is selected by you, and a browser push service is selected by your browser vendor. Providers and destinations may process data in other jurisdictions; the project does not publish a corporate domicile or make a blanket claim that every transfer is covered by a particular corporate transfer mechanism.

Junkmail has no ads and no cross-site tracking. It does not sell mailbox data. Authentication and security cookies are used only to provide sign-in, session, remember-me, and CSRF protection; aggregate service metrics do not require tracking cookies.

Your controls

From Your data, an authenticated user can download a ZIP containing JSON account, alias, message, billing, session, security-activity, sharing, and integration metadata plus the raw .eml files still retained, or permanently delete the account after confirming the current password. Password and two-factor secrets, token and recovery-code hashes, webhook secret ciphertext, push encryption keys, payment credentials, and internal storage paths are excluded from the export because disclosing credential material would weaken account security. You can also delete individual messages, burn aliases, revoke sessions and API tokens, remove webhooks and push subscriptions, and disable optional two-factor authentication.

Your mailbox-sharing records are in that export file, and all of them stay visible and reversible in the product on the Sharing page: your handle, your invite-me tokens with their state, invitations you have sent and received, mailboxes you share and mailboxes shared with you including any a plan change has paused, the handles you have blocked, the guest webhooks and API tokens reaching your mailboxes and the ones you have pointed at somebody else's, and your own read, starred, pinned, and archived marks and your tags on mail in a mailbox shared with you. Three things are deliberately not in it. The other account appears only as its pseudonymous handle, because no email address is recorded against a share and none may cross that boundary. The words of an invite-me token are absent because only a keyed digest of them is kept and the words cannot be derived from it. Your marks and tags on a mailbox you can no longer open are absent because they are deleted when access ends, and a paused share stays closed to you until it resumes—for the same reason a guest's marks and tags on your mail are in their export and never in yours.

Depending on where you live, you may also have rights to access, correct, erase, restrict, port, or object to processing, and to withdraw consent without affecting earlier processing. Use the self-service controls where they cover your request, or email privacy@junksink.com for a privacy question that cannot be completed in the product. You may lodge a complaint with the data-protection supervisory authority responsible for your habitual residence, workplace, or the place of an alleged infringement.

Security boundary

Message HTML is treated as hostile input: it is sanitized, displayed in a sandboxed frame, and remote images are blocked by default. Mailbox content has no operator-console reading route. No system can make internet email risk-free, so protect your account password and recovery codes and revoke access you no longer use.