Privacy

Last updated: September 18, 2026

This privacy policy informs you, in accordance with Articles 13 and 14 of the General Data Protection Regulation (GDPR), about the processing of personal data when using the SchlüsselBot service, accessible at https://schluesselbot.de (hereinafter referred to as "Service" or "SchlüsselBot").

1. Controller

The controller within the meaning of Art. 4 para. 7 DSGVO is:

MessingerDesign, Philipp Messinger & Werner Messinger GbR Dahmestraße 10 12526 Berlin Germany

represented by the individually authorised partners Philipp Messinger and Werner Messinger.

• Email: pmessinger@messingerdesign.de
• Phone: +49 174 967 61 56
• VAT identification number: DE332090964

1.1 Data Protection Officer

We are not legally required to appoint a data protection officer (Art. 37 GDPR, § 38 BDSG). For any questions regarding data protection or to exercise your rights, please contact the responsible party listed above directly.

2. Fundamentals of the service architecture (server blindness / zero-knowledge)

SchlüsselBot is designed as a deliberately data-minimal, server-blind service. Understanding this concept is essential for the legal classification of the following data processing activities:

• Client-side encryption: The content you submit (message and optional attachment) is encrypted directly in your browser – that is, on your end device – before being transmitted to our servers, when using the website. An exception exists for the API: there, you may choose to submit the content either encrypted (field ciphertext) or in plaintext (field message). In the latter case, the content reaches us in readable form, is encrypted by us, and the plaintext is immediately overwritten in memory; for this process, server blindness as described below does not apply. The key required for decryption is never stored together with the ciphertext on the Vault server. During direct delivery, it is carried exclusively in the so-called URL fragment (the part of the link after the # character). A URL fragment is technically not sent to the server when the page is later accessed and therefore does not appear in our server logs. For the direct open button in recipient secure inboxes, the limited exception under section 6.3 c applies.
• Delivery method — your choice: Whether the key reaches us is determined by you when sending directly via our sending form prior to sending. In Security Mode ("Secure"), you transmit the access link together with the key yourself via another channel; the key never reaches our servers. In Convenience mode ("Simple"), you explicitly authorise us to assemble and send the completed link on your behalf; for the duration of sending, the key is temporarily transferred to us. For a Receiving secure inbox, access is determined by the protection level selected during setup; the E2E passphrase uses a separate key pair and does not transmit any key fragment to us. Details and legal bases are available in section 6.3.
• Key and ciphertext remain separated: The content is stored exclusively as encrypted ciphertext on the Vault server. During direct dispatch and with E2E passphrase, we do not store the decryption key. Only for receiving secure inboxes without E2E passphrase does the Edge server temporarily hold an additional encrypted copy of the URL fragment for the logged-in inbox; its server key is stored outside the database and not included in our application backups. The copy is removed after retrieval, expiry or hiding. Neither keys nor URL fragments appear in logs. Technical inability to access the key applies to the “Secure” dispatch method and E2E passphrase secure inboxes.
• Exception: API (Business only): If a customer sends content in Plain text (field message) via the interface, we encrypt it on their behalf. The content reaches us in readable form and is immediately overwritten in memory after encryption; it is not stored or logged. For this route, the above statement "not possible" does not apply, so it is not applicable. Anyone wishing to exclude knowledge of the content even in this case must encrypt it themselves and submit a pre-encrypted ciphertext. Purpose: fulfilment of the usage contract. Legal basis: Article 6(1)(b) GDPR.
• Two-server separation: The publicly accessible server ("Edge") does not store any content permanently; encrypted content resides exclusively — additionally encrypted at rest — on a separate, non-publicly accessible server ("Vault").

Legal consequence (Art. 11 GDPR): As we are unable to read or identify the stored encrypted content, this constitutes processing that does not require identification of the data subject. We address the resulting limitations on your data subject rights separately and transparently under section 20.1.

Our role: For the unencrypted data processed (e.g. recipient email address, sending emails, IP addresses, logs, account and payment data), we are the data controller as defined in Article 4(7) of the GDPR. Regarding encrypted content and attachments, we act as a mere hosting or forwarding service without knowledge of the content – even in the Comfort Mode (Clause 6.3), where although we hold the key, the decrypted content is never transmitted to us; in this respect, the liability protections under Sections 7(2), 8 to 10 of the Digital Services Act (DDG, formerly TMG) apply, and the user remains responsible for the lawfulness of the content.

3. Definitions

This privacy policy uses terms defined in the GDPR (e.g. "personal data", "processing", "controller", "processor", "consent"). Additionally, the following service-specific terms apply:

• Secret: A single encrypted transmission (message and/or attachment).
• One-time code: A proof sent by email to the recipient, demonstrating they control the specified inbox; used as an additional access control before the ciphertext is released.
• Edge server / Vault server: The two-server separation described in Clause 2.
• Delivery method: The route by which the access link reaches the recipient – Security Mode ("Secure") (you transmit the link yourself) or Convenience mode ("Simple") (we send the completed link on your behalf). You select the delivery method when using our sending form. For submissions via a receiving secure inbox, access is governed by the protection level chosen by the owner. Details in section 6.3.
• Receiving secure inbox: A permanent submission address ( /i/<nutzer-nummer>/<name> ), available to users on paid plans. During setup, options include one-time code via email, account Passkey, Code plus Passkey, Code plus second factor, and a personal passphrase with true end-to-end encryption. For Passkey levels, we use the account’s public WebAuthn credentials; biometric data never leaves the end device. For E2E passphrase, we store the private secure inbox key exclusively encrypted with the passphrase.
• Janitor: An automated, time-triggered deletion process that reliably and permanently deletes expired or accessed secrets, regardless of access.

4. Hosting and infrastructure

We operate the service on a two-server architecture:

• Edge server (publicly accessible): Hosted by netcup GmbH, Daimlerstraße 25, 76185 Karlsruhe, Germany. Server location: Germany.
• Vault server (not publicly accessible): operated within the control area of the controller; location: Germany/EU.

Purpose: Provision, operation, and security of the service. Legal basis: Article 6(1)(f) GDPR (legitimate interest in reliable and secure service provision); where processing supports contract performance, additionally Article 6(1)(b) GDPR. Data Processing Agreement: A data processing agreement under Article 28 GDPR is in place with the hosting service provider. Both servers are located in Germany/EU; no transfer to a third country occurs in the context of hosting not. Storage period: See the respective processing and section 19.

5. Server logs

When accessing our website, the edge server automatically collects information transmitted by your browser. These include in particular:

• IP address (fully recorded — used for attack prevention and automatically blocked; a shortened address would be useless for this purpose). Stored for 7 to 14 days, then automatically deleted via daily rotation.
• Date and time of access,
• Retrieved resource / status code,
• amount of data transferred,
• Referrer (if transmitted) and User-Agent (browser type/version, operating system).

Logging minimisation (technical protection measure): Our logs inherently contain none decryption keys, none URL fragments, none one-time codes, and none plaintext content. This explicitly applies to the Convenience Mode (Clause 6.3): the key transmitted there is processed exclusively temporarily in memory and is neither written to access logs nor application logs.

Purpose: Ensuring uninterrupted operation, fault diagnosis, IT security, and attack detection. Legal basis: Article 6(1)(f) GDPR (legitimate interest in operational security and attack prevention). Storage period: Server and application logs are typically automatically deleted or rotated within 7 to 14 days, unless required for investigating a specific security incident.

6. Core function: Secure data exchange (content and attachment)

6.1 Message content

Processed data: the encrypted ciphertext of the message, as encrypted in your browser. We do not receive the plaintext when using the user interface. Purpose: encrypted temporary storage for transmission of the message to the recipient you specified. Legal basis: Article 6(1)(b) GDPR (performance of the transmission process you have instructed). Storage location: exclusively on the Vault Server, additionally encrypted at rest. Storage period:

• Plain message (no attachment): deletion immediately after successful retrieval (view).
• If the message is not retrieved, it is deleted when the period selected by the sender expires. The default is 48 hours in Free and Pro and 7 days in Business. In Pro and Business, the sender can choose 24, 48 or 72 hours, or no later than 7 days.

6.2 Attachments

Processed data: the encrypted ciphertext of an optional attachment (Free up to 2 MB, Pro up to 50 MB, Business up to 100 MB). Attachments may contain personal data of third parties – however, these are also only stored as unreadable ciphertext for us. Purpose: encrypted transmission of the file attachment. Legal basis: Article 6(1)(b) GDPR. Storage location: as an encrypted file object on the Vault Server (not in the database). Storage period (special rule):

• When a message with attachment is retrieved, the attachment is delivered together with the message; after that, it exists solely in the recipient's browser. It remains on our server for up to up to 10 minutes after the first retrieval, after which it is permanently deleted. This is a deletion deadline, not a guarantee of availability: The recipient's copy already resides in their browser — if they close or reload the page, it will no longer be there. There is no second retrieval.
• If the attachment is not retrieved, it is deleted when the same period as the message expires (default: 48 hours in Free and Pro and 7 days in Business; no longer than 7 days).

Note on server blindness: Content and attachments exist on the Vault server exclusively as ciphertext. Technically enforced is our lack of knowledge in security mode and in the E2E passphrase secure inbox. For other secure inbox levels, separate, time-limited processing applies per Section 6.3(c). Final, time-controlled deletion is enforced by our Janitor process, independent of access.

6.3 Sending method and handling of the decryption key

When sending via our send form, you select before sending how the retrieval link reaches the recipient. This choice determines whether we ever see the decryption key. We clearly separate the options here because they imply different levels of confidentiality towards us as provider. Letter c describes the special case of submission via a receiving secure inbox; there, the protection level chosen by the owner during setup determines the key and retrieval path

a) Security mode ("Secure"): When creating it, we send no advance email to the recipient . You send the retrieval link including the key yourself via a channel separate from us (e.g. messenger, SMS, personal). Only when the recipient opens this link and requests a one-time code will we send the code to their email address. Immediately after creation, the person sending the message receives a neutral shipping confirmation with the specific expiry time, but without retrieval link, key or message content. For a logged in account, it goes to the account email address; if sent anonymously to the sender address provided separately. Processed data: no key. The key reaches our servers using this shipping method at at no point in time ; The zero-knowledge property is unrestricted in this respect.

b) Comfort Mode ("Simple", default): You expressly instruct us to send the completed retrieval link, including the key, by email to the recipient you specify. Processed data: the key fragment used to assemble the retrieval link. Purpose: carrying out the transmission you instructed. Legal basis: Article 6(1)(b) GDPR (performance of the instructed transmission). Processing location: exclusively and temporarily in the Edge server’s working memory. The key leaves the Edge server by only one route—as part of the retrieval link in the notification email sent through the delivery channel described in Section 9 to the recipient’s inbox; that is precisely the purpose you instructed. A transfer to the Vault server, where the ciphertext resides, does not take place; ciphertext and key are therefore never combined. Storage period: none—the key is neither stored in the database nor logged and is discarded after the email has been sent.

c) Submission via a receiving secure inbox: When you send via another user's secure inbox address (/i/<nutzer-nummer>/<name>), your content is always encrypted with AES-256-GCM in your browser. Additional information you entered regarding sender name and subject is intentionally not part of the encrypted content: They appear in the notification email sent to the holder and in the holder’s inbox overview (Section 14.2), so the holder can identify who the submission is from and what it concerns. The secure-inbox holder may determine whether the sender name and/or subject is required for submissions through that secure inbox. The form displays the applicable setting before submission; otherwise the fields may be left blank. For the Code, Passkey, Code plus Passkey and Code plus second-factor levels, the random key is sent to the holder as part of the notification link. To allow the holder to open the same submission directly from the logged-in inbox, we additionally store the URL fragment on the Edge server using AES-256-GCM encryption. The server key used for this is root-protected outside the database, separate from the ciphertext on the Vault server, is not included in logs or application backups, and the copy is removed upon retrieval, expiry or hiding. The credentials required to open the submission still depend on the chosen level; the dashboard button bypasses neither code nor Passkey. With E2E passphrase, the holder’s browser generates a key pair; the submitter encrypts against the public key, and the private key exists only in passphrase-encrypted form. The key fragment does not reach us at this level. Processed data: the ciphertext; depending on the level, either the encrypted, temporarily stored key fragment or public ECDH key data; the secure-inbox holder's email address; and, where applicable, the holder's public Passkey login details. Purpose: delivery and secure retrieval of the submission. Legal basis: Article 6(1)(b) GDPR.

Templates and personalised forms (Business): The secure-inbox holder may activate provider-supplied or user-created input templates. Values entered by a submitter into template fields are combined into a message block in the browser and encrypted together with the message; they are not transferred to us as readable individual values. For user-created templates, we process the following configuration data: the name, description and instructions, placeholders, field labels, field types, selectable options, required/optional status, creation and modification times, and activation and assignment to the relevant secure inbox. We store the definition in the account database using AES-256-GCM encryption; the key is root-protected outside the database. Because our server must decrypt and deliver an enabled definition to the public form, this protects against an isolated database leak and does not constitute technically enforced provider blindness. The parts of the configuration intended for the form are displayed in every public secure-inbox form for which the template is enabled and must therefore contain no secrets or confidential personal data. Purpose and legal basis: provision of the Business feature configured by the account holder, Article 6(1)(b) GDPR. Storage period: until the template is deleted, and no longer than until account deletion; activation and required-field assignments additionally end when the relevant secure inbox is deleted.

Additionally, the owner can prepare a randomly addressed, revocable form link for a specific person. Processed configuration data: internal designation, pre-filled name and pre-filled email address, a personal introduction, a neutral subject and the selected template. We store these defaults in AES-256-GCM encrypted form in the account database; The key used for this is root-protected outside the database. Since our server needs to provide the pre-populating for the public form page, this is a protection against isolated database drain, not technically enforced vendor blindness. The public address contains only a random 128-bit identifier, none of this information. Anyone who has the complete personal link can see the pre-assignment prepared for it; the owner is therefore responsible for secure distribution. Purpose and legal basis: Preparation and simplified implementation of the ordered secure transmission, Art. 6 Para. 1 lit. b GDPR. Storage period: until the personalization is revoked, the secure inbox or the account is deleted. When sending, the information in this section and section 9 also apply to the name, email address and subject.

Transparency notice regarding letters b and c: In comfort mode and for secure-inbox levels without a personal E2E key pair, keys and ciphertext—although processed for different purposes and never combined—pass through our systems. Confidentiality from us is not technically enforced in these cases but relies on the safeguards described: no storage or logging in comfort mode; encrypted, separate and time-limited storage for secure inboxes, without including the server key in application backups. With E2E passphrase, server blindness is technically enforced; however, a forgotten passphrase cannot be reset.

6.3.1 Receiving secure inbox embedded on a customer website

The owner of a business receipt secure inbox can integrate its submission form as iframe on their own website. The embedding points to a randomly generated, revocable identifier at /embed/… that is assigned to exactly one receiving secure inbox. This identifier is publicly usable and is neither a login secret nor a decryption key. The secure inbox owner also provides the exact HTTPS origin of the website on which the form may appear. Technical browser rules only allow display as an embedded form on this origin; There is no release for arbitrary websites.

Processed data: the embed identifier, its assignment to the receiving secure inbox, the authorised HTTPS origin, where applicable the random identifier of a personalised form, and the technical connection data described in Section 5. When the form is loaded, the sender's browser establishes the connection to schluesselbot.de required to provide it. For a submission, Sections 6.1, 6.2, 6.3(c) and 6.4 continue to apply to content, attachments and accompanying data: the message, template values and attachments are encrypted in the sender's browser before transmission. Purpose: to provide the submission form requested by the secure-inbox holder, assign the submission correctly, and prevent unauthorised embedding and automated abuse. Legal basis: Article 6(1)(b) GDPR for provision of the contracted feature and Article 6(1)(f) GDPR for origin validation and abuse prevention. Storage period: Configuration data and revoked identifiers are retained for the lifetime of the associated receiving secure inbox, and no longer than until the account is deleted; the retention periods for submissions and log data are governed by Sections 5, 6 and 19.

Cookie-free and without third-party resources: The embedded form neither sets nor reads cookies and uses neither localStorage nor sessionStorage. It contains no analytics or fingerprinting and does not load third-party fonts, scripts, CAPTCHA services or CDN content. Spam protection consists solely of self-hosted, data-minimising measures such as a browser-based computational challenge (proof of work), a hidden honeypot field and rate limits. The embedded form therefore does not, by itself, trigger a need for consent to cookies or tracking. Whether the surrounding customer website requires consent management because of other services is determined and remains the sole responsibility of its operator.

Roles and information duties: The operator of the embedding website determines the purpose and legal basis of data collection and remains the controller under Article 4(7) GDPR. The operator must provide the sender with clear information under Article 13 GDPR, describe the SchlüsselBot embed in their own privacy notice and ensure a legal basis under Article 6 and, where special categories of data are involved, additionally under Article 9 GDPR. A checkbox or the embed itself does not replace that assessment. The form visibly links to SchlüsselBot's Privacy Policy and Legal Notice. Where SchlüsselBot processes personal data on the customer's behalf, the Business plan and a data processing agreement under Article 28 GDPR are required; Section 6.4 additionally applies to holders of professional secrecy.

6.4 Special categories of personal data (Art. 9 GDPR)

The service is explicitly offered to professional groups where the exchange may involve special categories of personal data under Art. 9 para. 1 GDPR — particularly Health data (doctors’ and dentists’ practices, therapy, care) as well as indirect data revealing religious, philosophical, trade union, or sexual life information (counselling services, law firms). We therefore clarify:

• Role distribution. If you use SchlüsselBot for professional or business purposes to transmit data about your patients, clients, applicants or employees, You are the responsible controller under Article 4(7) GDPR; we act as processor under Article 28 GDPR. Whether processing of special categories is permitted depends on a lawful basis in your sphere (e.g. Article 9(2)(a), (h) or (f) GDPR, § 22 BDSG). We do not assess this and cannot assess it.
• A Data Processing Agreement is a prerequisite. For this use, you need a contract under Article 28(3) GDPR. It is included in the Business plan and can be generated directly in your account; it is not available in the Free and Pro plans. Without it, you may not use the service professionally for personal data of third parties.
• Holder of professional secrecy, § 203 StGB. Anyone subject to professional secrecy under § 203(1) StGB may only involve supporting persons under the conditions set out in § 203(3) StGB. We provide a separate declaration of obligation under § 203(4) StGB in the Business plan, which you can download together with the data processing agreement from your account.
• The content is unreadable to us – the accompanying data is not. The message and any attachment are only available to us as ciphertext (Sections 6.1 and 6.2). Readable by us are, however, partly stored unencrypted and partly encrypted with a key we hold ourselves: sender and recipient email addresses, a Subject, a Sender name (Section 6.3(c)), the Name of a receiving secure inbox, and publicly displayed names, descriptions, instructions, placeholders, field labels and selectable options of user-created templates. These details alone may already constitute data under Article 9 GDPR. We therefore expressly recommend not including any information on diagnosis, treatment, subject of the procedure or reason for consultation – a neutral subject such as “Documents” or “Receipts” is sufficient because the content is encrypted. Depending on the configuration, sender name and subject may be optional or required; the secure-inbox name always forms part of the public address.
• No profiling, no analysis. No evaluation, categorisation, or automated decision-making based on content takes place, and this is technically not possible for us (Clause 2, Clause 20.1).
• Deletion. For special categories, no longer retention periods apply, but the same short periods as for all content (Clause 6.1, 6.2, Clause 19); deletion occurs immediately after retrieval.

7. Recipient email address (mandatory)

Processed data: the recipient's email address you provided. Purpose: In comfort mode, delivery of the retrieval link and, upon request by the recipient, the one-time code; In security mode, the one-time code is only delivered after the recipient has opened the link received elsewhere and requested the code themselves. When creating a shipment in security mode, the recipient will not receive an email from us. The recipient address is constitutive of the service: without it, the transmission process you have ordered cannot be carried out. Legal basis: towards the sending person Art. 6 Para. 1 lit. b GDPR (implementation of the commissioned transmission process); towards the recipient who is not themselves a party to the contract, Art. 6 Para. 1 lit. f GDPR (legitimate interest in the delivery of the message intended for them and in secure access control). You have the right to object to this processing under Article 21 GDPR (clause 21); a message to our abuse address is sufficient, after which we will no longer send you anything. Storage period: until delivery/retrieval, but no longer than the period selected by the sender (default in Free and Pro: 48 hours, Business 7 days; no longer than 7 days) if the secret is not retrieved; after a successful retrieval, it is deleted together with the secret (for attachments, after the 10-minute window has elapsed). Purpose limitation: It takes place none Creation of distributors, none Use for advertising purposes only; no reuse for other purposes than those specified here. Exception: Delivery blocklist: If the recipient's mail server explicitly rejects an address (SMTP code 5.1.x) or a misuse complaint is received, we record the address along with the reason and timestamp in a blocklist and send nothing more to it. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in ensuring our mail server's deliverability and protecting third parties from unwanted deliveries). Storage period: 180 days (only entries resulting from delivery failures; an objection under Article 21 GDPR is retained indefinitely because otherwise we could not honour it permanently, Article 17(3)(e) GDPR). You can request removal from the suppression list at any time using the address in the legal notice.

If the sender requests a delivery receipt, it includes the original recipient address, the transaction identifier and the retrieval time. It is sent only to the receipt address specified by the sender and contains neither message content nor keys. The recipient address identifies the corresponding message; server-side deletion periods remain unchanged.

8. Sender email address

In comfort mode, providing a sender email address voluntary is only required if you would like proof of delivery. In secure mode, a sender address is required for shipping confirmation: For a logged in account, we use the confirmed account email address; If sending anonymously, please enter the address separately.

Purpose: In security mode we send a neutral confirmation of successful creation and the specific expiry time. It does not contain any retrieval link, key or message content. Only if you also choose proof of delivery will we later notify this address of the retrieval. Legal basis: Art. 6 Para. 1 lit. b GDPR (implementation of the selected transmission process). Storage period: An anonymous address entered exclusively for shipping confirmation is not included in the message data record; Technical shipping protocols are subject to the deadlines set out in paragraphs 5 and 9. An address used for the optional proof of delivery will be deleted together with the associated secret (immediately upon retrieval or upon expiry of the selected deadline, default Free and Pro 48 hours, Business 7 days; maximum 7 days). The deadlines for the customer account apply to the account email address.

9. Sending of notification and code emails

Which emails we send depends on the shipping method selected:

• Comfort mode (“Simple”): The recipient receives a neutral notification email with the retrieval link when it is created and later, when they request it, the one-time code.
• Security Mode ("Secure"): The recipient does not receive an email when it is created. After he has opened the link provided by the sender and requested a code, we only send him the one-time code. Instead, the sender receives the neutral shipping confirmation with expiry time described in section 8.
• Content of the recipient notification: The actual message content is never in the email, but only encrypted behind the retrieval link. If a recipient notification is sent, it can contain two freely selectable by the sender information: a Sender names (up to 60 or 80 characters, depending on the sending method, appears in the subject and on the retrieval page) and a short personal message (up to 500 characters, appears in the body of the email). Both can remain empty. Purpose: The recipient should be able to recognize who and what it is about; Without this information, a notification looks like a phishing attempt. Legal basis: Art. 6 Para. 1 lit. b GDPR towards the sender, Art. 6 Para. 1 lit. f GDPR towards the recipient. Storage period: The sender name is stored until the associated message is retrieved, withdrawn or expires and then removed from the sending log. The personal message is not saved in this log. An automatic filter removes Internet and e-mail addresses from both fields so that the notification cannot be misused as a carrier of third-party references; there is no examination of the content. For submissions via receiving secure inboxes, the notification contains a subject (up to 80 characters) instead of the personal message; The sender name and subject can be configured by the owner as required or optional (section 6.3 letter c). The same rules apply to the programming interface and MCP connection in the business plan.
• Processed data: Recipient email address and - depending on the shipping method - retrieval link or one-time code as well as, in security mode, the sender address and expiry time for the shipping confirmation. In comfort mode ("Simple") and for secure inbox levels without their own E2E key pair, the retrieval link sent in the email also contains the key fragment. In security mode ("Securer"), no email we send contains a retrieval link or key fragment.

Purpose: Delivery of the retrieval link, shipping confirmation and one-time code as well as ensuring that only the owner of the recipient secure inbox has access to the cipher. Legal basis: Art. 6 Para. 1 lit. b GDPR (implementation of the transfer process); With regard to the one-time code, additionally Art. 6 Para. 1 lit. f GDPR (legitimate interest in secure delivery and protection against misuse). Storage period: The recipient address and code reference are deleted together with the secret (see numbers 6, 7 and 10); Section 8 applies to the sender address.

Delivery route: Email delivery is carried out via a own mail server ( server.messingerdesign.de ), operated by the provider in Germany. No external transactional email service provider is used; therefore, no data is transferred to third parties and no international data transfer occurs.

10. One-time code (proof that the inbox is reachable)

The one-time code serves as proof that the recipient controls the specified inbox and protects against unauthorised access through simple forwarding or interception of the link.

Processed data: the one-time code; on the server, it is stored exclusively as a cryptographic hash, never in plain text. Purpose: secure delivery of the ciphertext tied to the specific secret and recipient; protection against leaked links, forwarding and automated attacks. Legal basis: Article 6(1)(b) GDPR (part of secure delivery) in conjunction with Article 6(1)(f) GDPR (legitimate interest in security and preventing misuse). Technical protection measures (Art. 32 GDPR): hash-only storage, constant-time comparison (protection against timing attacks), sufficient key length, brute-force protection through rate limits and an attempt counter, one-time use, and binding to the relevant secret. Storage period: together with the associated secret (immediately upon retrieval or when the selected period expires; default: 48 hours in Free and Pro and 7 days in Business; no longer than 7 days).

11. Security, abuse prevention and Captcha

11.1 IP addresses for rate limiting and abuse prevention

Processed data: IP address (fully, exclusively used as a counter key; automatically deleted after at most 24 hours) of the accessing device, and optionally a counter for sending activities. Purpose: Protection against brute-force attacks, spam, mass sending, and overload (DoS); ensuring service availability and integrity. Legal basis: Article 6(1)(f) GDPR (legitimate interest in security, availability, and misuse prevention; see recital 49 GDPR). IP addresses are considered personal data under the case law of the ECJ (Case C-582/14, "Breyer"). Balancing of interests: The risk of misuse of an anonymous-accessible transmission service is significant; processing is necessary for prevention, and is data-minimal: the address is used only as a counter key, is not linked to any account, and is deleted after at most 24 hours, remaining short-lived and without profiling or correlation with content. Your protected interests therefore do not outweigh this. Storage period: Within short-lived rate-limiting windows (minutes); for misuse correlation, up to 24 hours, after which deletion occurs.

11.2 Captcha (bot protection)

To protect against automated abuse during sending, we use a privacy-friendly, preferably EU/self-hosted protection mechanism: a self-run computational task (Proof-of-Work) solved in the browser.

Purpose: Protection against automated spam and mass distribution. Legal basis: Article 6(1)(f) GDPR (legitimate interest in preventing abuse). Storage period: Only for the duration of validating the respective challenge.

Note: Should a third-party captcha provider (e.g. Cloudflare Turnstile, hCaptcha) be used in the future that processes data outside the EU, it will be disclosed as a processor in Section 17, including location and third-country safeguards. Where required, consent will be obtained. No external captcha service will be integrated; no data will be transmitted to third parties.

12. Audience measurement / analytics

First-party, reviewed code only: For consent-based analytics, SchlüsselBot loads only its own sb-analytics.js script from schluesselbot.de. The browser does not connect to a third-party analytics provider or directly to meinKI. Google Analytics and comparable third-party services are not used.

Pages and inputs deliberately excluded: The script is included only on public information and marketing pages. In particular, it does not run on retrieval pages (/r/…), receiving-secure-inbox pages (/i/…), embedded secure-inbox forms (/embed/…), or login, account, admin, payment and API pages. The homepage contains the optional secure-send form. The locally served analytics code neither reads nor serialises its input fields or files; in addition, the server endpoint is technically unable to accept such fields because it uses a closed allowlist.

12.1 Internal daily statistics and service usage

For internal operational overview, SchlüsselBot additionally generates a deliberately coarse daily summary. This is based on the server logs described in point 5; no additional request is triggered by your browser, no cookie or browser storage is used, and no additional identifier is set. Known bots and technical testing programs are filtered out. IP address and browser identifier are used solely during processing to prevent repeated requests on the same calendar day from being counted multiple times as visitors. These details, and any checksum derived from them, remain only in memory and are not included in the statistics. Only the calendar day, number of visitors, and number of page views are stored. Thus, recognition across different days is not possible.

Daily statistics only include public information, registration, and sign-up pages. Access pages ( /r/… ), inbox folders ( /i/… ), APIs, and logged-in areas are excluded. Therefore, the sum over multiple days is the sum of daily visitors, not a count of uniquely identifiable individuals.

SchlüsselBot also records only the delivery path (direct send or secure inbox), sign-in context (without sign-in, from an account, or legacy data that can no longer be attributed unambiguously), size of the already encrypted data package, attachment yes/no and timestamp for each successfully saved secure message. Where an event is attributed to a sender account or a receiving secure inbox, the account or company attribution is added; this attribution is removed when an account is deleted. The abstract sign-in context remains available for aggregated usage statistics, but does not identify an account or a person. Message content, recipient address, subject and file name are not recorded. For a confirmed self-registration, the statistics only distinguish between direct registration and social sign-in; invitations and accounts created by the operator do not count as conversions.

For newly created transmissions, we also briefly record whether the encrypted one-time item was technically retrieved, withdrawn before retrieval, securely discarded, could not be determined unambiguously, or remained unretrieved until it expired. We store only a keyed checksum of the random transaction identifier, the transmission type, an abstract sign-in context, the creation and expiry times, the status and, where applicable, the exact technical retrieval and completion times. The separate checksum prevents an immediate database match using the transaction identifier. At low volumes, the time and transaction type may nevertheless suggest a statistical association with a usage event. We therefore retain this status only briefly and expose it in the admin area solely as daily totals. This dataset contains no recipient address, account or company identifier, or content. A technical retrieval proves that the ciphertext was delivered successfully, not that a person actually read or understood its contents. No values are estimated retrospectively for transmissions sent before this tracking began.

Purpose: daily reach, usage and conversion analysis, capacity planning and improvement of the service's delivery reliability. Conversion is a purely statistical comparison of daily totals; SchlüsselBot does not track which specific person later sends a message or creates an account. Legal basis: Article 6(1)(f) GDPR (legitimate interest in privacy-conscious performance measurement and economical, secure operation); for account-related usage events, additionally Article 6(1)(b) GDPR for providing and billing the selected plan. Storage period: aggregated daily totals and content-free usage events are deleted automatically after 25 months. For direct transmissions, the short-lived retrieval status is deleted 30 days after expiry; for secure inbox submissions, it is deleted just 30 days after receipt. This makes it possible to compare two complete years without retaining an unlimited usage history. Independently of this, the underlying server logs are deleted after just 7 to 14 days.

12.2 Enhanced analytics with meinKI — only with consent

If you expressly agree in the notice, the local script sends measurement events only to an address on schluesselbot.de (same origin). A closed server-side allowlist discards all unknown fields and maps the remaining data to fixed categories. Only then does the SchlüsselBot server forward the minimised data set through a private, encrypted WireGuard connection to the controller’s own meinKI instance. This separates the browser from meinKI; the analytics address and access key remain on the server. No data is disclosed to another company or transferred to a third country.

Only the following data is transmitted: a fixed, broad page category, German or English language, a coarse screen-size class, a coarse time-on-page bucket, scroll level (0, 25, 50, 75, or 100 percent), and predefined event categories. Events distinguish only between a link to a selected reputable source, a download category, and successful use of the free secure-send feature. Once you have consented, a random session identifier is generated solely to associate events within one open browser tab.

The following data is not transmitted to meinKI: form values, messages, files, email addresses, raw URLs or URLs read from the browser, query parameters, URL fragments, referrers, page titles read from the browser, link text, filenames, account or company identifiers, your IP address, or your browser’s user agent. For technical compatibility with meinKI, the server maps each permitted page category only to a fixed URL and title label; these labels contain no address, parameter, or heading from the browser. The ‘secure send successful’ category reveals neither the recipient nor the content, size, attachment status, or account. Your IP address necessarily reaches the SchlüsselBot endpoint, where it is immediately replaced with a keyed digest for abuse-rate limiting and retained for no more than 24 hours in a limiter database isolated from login and sending. SchlüsselBot forwards neither the address nor the digest to meinKI. Access logging is also disabled for this endpoint.

Purpose: to understand which public content is helpful, where usability can be improved, and how often the free secure-send feature is used. Legal basis: your consent under Article 6(1)(a) GDPR in conjunction with Section 25(1) TDDDG. Consent is voluntary and may be withdrawn at any time with future effect through ‘Privacy settings’ in the footer; SchlüsselBot remains fully usable without consent.

Storage period: Individual page views and events are automatically deleted from meinKI after 13 months; only aggregated monthly figures with no personal reference remain thereafter. Information about currently active visits is removed 15 minutes after the last signal. The random session identifier exists only in the browser’s session storage and expires when the tab is closed.

13. Cookies, local storage, and consent management

SchlüsselBot uses no cookies for analytics. If you consent to enhanced analytics, the browser stores the random session identifier only in sessionStorage; it expires when the tab is closed. Your ‘allow’ or ‘do not allow’ choice is stored in localStorage so that SchlüsselBot does not ask again on every page view. The choice remains stored until you change it through ‘Privacy settings’ in the footer or clear the website data in your browser.

Before you consent, no analytics identifier is stored and no measurement event is transmitted to meinKI. Refusing is as easy as consenting and has no adverse consequences. Withdrawal stops enhanced analytics immediately; it does not affect the lawfulness of processing carried out before withdrawal.

Technically necessary storage operations for secure account sessions, your selected language, and short-lived security states during one-time retrieval serve only the function you expressly requested and do not require consent under Section 25(2)(2) TDDDG.

Unlike those functions, the embedded secure-inbox form under /embed/… no cookies or browser storage at all. It also contains no audience measurement or other analytics functionality; see Section 6.3.1 for details.

14. Account and login (paid plans, optional)

Core usage of SchlüsselBot is without account. An account is only required for paid plans (e.g. higher limits, personal receiving secure inboxes, contact management) and is fully optional.

Important: An account grants no access to encrypted content. The account is used solely for managing and controlling usage limits; the service architecture remains unaffected (the decryption key is not derived from account data nor stored in the account; the distinction by delivery method in clause 6.3 remains unchanged).

Processed data: email address, password (stored exclusively as Argon2id hash, never in plaintext), and upon activation of two-factor authentication, a 2FA secret or passkey data; optionally, a profile/subject ID when using social login (see Clause 15). Purpose: provision and management of the paid account (registration, management, higher limits, security). Legal basis: Article 6(1)(b) GDPR (performance of the user agreement). Technical protection measures (Art. 32 GDPR): password hashing with Argon2id, optional or mandatory two-factor authentication (TOTP/passkey), revocable sessions. Storage period: for the duration of the account’s existence. After cancellation or deletion of the account, the data will be deleted or anonymised, unless legal retention obligations apply (see Clause 16 for billing-relevant data).

14.1 Two-factor authentication (2FA)

Passkeys (WebAuthn): When logging in with a passkey, biometric data (e.g. fingerprint, facial features) remain exclusively on your endpoint device and are never transmitted to us. Our server stores only a public key and a random identifier; identification or tracking across other services is therefore not possible.

Processed data: TOTP secret and/or Passkey/WebAuthn login data, and optionally Argon2id-hashed recovery codes. Purpose: Securing account access against unauthorised login and phishing. Legal basis: Article 6(1)(b) GDPR (necessary for contract performance) or Article 6(1)(f) GDPR (legitimate interest in account security). Storage period: For the duration of the account or until the function is deactivated.

14.2 Address book and inbox overview in customer area

Address book and sending preferences: You may store email addresses along with optional names in the signed-in area to select them during sending. You may also define a general sending default for your account and different preferences for individual contacts: the retention period, the sender name displayed in the recipient email, and whether a delivery receipt to your account address is enabled by default. Contact preferences take precedence over the account default; you can still visibly deviate from them in the individual sending form. The security-relevant delivery mode and personal message text are expressly not stored as automatic preferences. In the Business plan, an API key explicitly granted contacts:read or contacts:write permissions may read or manage the names and email addresses of the same contacts; these convenience preferences are not disclosed through that API. Processed data: the names and email addresses you enter and, where configured, the sending preferences described above. All of these details are encrypted in the database using AES-256-GCM. Names and addresses are decrypted only for your authenticated session or an API request you have expressly authorised; sending preferences are decrypted exclusively for your authenticated session. The key used for this is stored separately from the database and web root. The checksum for duplicate detection is bound to a secret key and unique per account, so a database dump cannot link identical contacts across different accounts. Purpose: Ease of use when sending and customer-selected software integration. Legal basis: Article 6(1)(b) GDPR. Storage period: contact preferences until the relevant contact is deleted; account defaults no longer than until the account is deleted. No matching with other data sets, enrichment or transfer to third parties occurs.

Overview of incoming secure inboxes: If a submission is received via one of your receiving inboxes, we will make an entry in your customer area. Processed data: the already public process identifier of the retrieval link, the affected inbox, the time of receipt, information as to whether an attachment is included, and - if specified when sending, regardless of whether optional or configured as required by the owner - sender name and subject (the same information that is also in the notification email). For inboxes without an E2E passphrase, the encrypted copy of the URL fragment described in Section 6.3 c is added until it is retrieved, expired or hidden. Content is not saved in the inbox. The submission itself remains encrypted on the separate Vault server; For inboxes with their own key pair, it is technically impossible for us to take note of the contents. Purpose: Overview and direct retrieval, which is still protected by the selected protection level, regardless of the notification email. Legal basis: Art. 6 Paragraph 1 Letter b GDPR. Storage period: Metadata 30 days from receipt; the encrypted fragment copy only until retrieval, expiration or hiding, i.e. a maximum of 7 days for submissions that have not been accessed. The submission itself will be deleted regardless of this in accordance with Section 6.

15. Social login (optional)

If offered and selected by you, you may optionally register and log in via an external identity provider (Identity Provider, IdP). This use is strictly voluntary (Opt-in) and does not affect core service usage without an account. Only the profile data required for login (typically your email address and a subject ID) will be processed.

Common legal framework for all social logins: Purpose: fast account creation and login. Legal basis: Article 6(1)(b) GDPR (performance of the account contract) and Article 6(1)(a) GDPR (consent to integration of the respective provider). Consent may be withdrawn at any time with effect for the future. Third country transfer: The providers listed below are based in the USA or process data in the USA. As such, a third-country transfer takes place. The basis for the transfer is — where the respective provider is certified — the EU-US Data Privacy Framework (DPF) pursuant to the EU Commission's adequacy decision, otherwise Standard Contractual Clauses (SCCs) under Article 46(2)(c) GDPR, together with additional safeguards. Technical note: The key required for decryption never depends on the identity provider; the service's security promise remains unaffected.

15.1 Microsoft login

Provider: Microsoft Corporation, One Microsoft Way, Redmond, WA 98052, USA. Third-country transfer to the USA based on DPF/SCC (see above). Privacy notice: https://privacy.microsoft.com/de-de/privacystatement.

15.2 Google login

Provider: Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Ireland, or Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA. Third-country transfer to the USA based on DPF/SCC (see above). Privacy notice: https://policies.google.com/privacy.

15.3 Apple login

Provider: Apple Inc., One Apple Park Way, Cupertino, CA 95014, USA. Third-country transfer to the USA based on DPF/SCC (see above). Privacy notice: https://www.apple.com/legal/privacy/de-ww/.

Note: The actual availability of the options listed above may vary. Unavailable options do not trigger any processing. As of today, registration via Microsoft, Google and Apple is disabled — the buttons on the login page are greyed out. No data is transmitted to these providers. This section applies only from the point in time when the feature is enabled.

16. Payment processing (paid plans)

Payment for paid plans is processed by PayPal (Europe) S.à r.l. et Cie, S.C.A., Luxembourg. PayPal is a pure payment service provider. The contractual partner, invoice issuer, and VAT debtor remains MessingerDesign GbR; the invoice and VAT certificate are issued by us. We transmit to PayPal only the data required for payment (amount, subscription ID, email address). Legal basis: Article 6(1)(b) GDPR.

Data processed by SchlüsselBot: billing-relevant master data (e.g. name, billing address, subscribed plan, requested and effective location changes, transaction/invoice reference) – none complete payment details. Purpose: Processing and billing of the paid subscription, as well as compliance with tax and commercial legal obligations. Legal basis: Art. 6 para. 1 lit. b DSGVO (contractual performance) and Art. 6 para. 1 lit. c DSGVO (fulfilment of statutory record retention obligations). Accounting: SchlüsselBot transmits customer name, billing address, email address, document, tax and transaction data to Lexware Office (Haufe-Lexware GmbH & Co. KG, Freiburg) so that invoices and invoice corrections can be recorded and retained in financial accounting. Message content, attachments, contacts and secure inbox data are not transferred to Lexware Office. Third country transfer: Payment processing is carried out via PayPal (Europe) S.à r.l. et Cie, S.C.A., Luxembourg. PayPal may process data in third countries within its corporate structure. Lexware Office is used under a data processing agreement and utilises the sub-processors listed in section 17; the safeguards specified there apply in case of potential international access. Storage period: Invoice and accounting data are stored in accordance with statutory retention periods 8 years (§ 147 para. 3 AO, § 257 para. 4 HGB, § 14b para. 1 UStG; commercial books, inventories and annual financial statements: 10 years). Other account data are deleted in accordance with section 14.

Proof of location for billing addresses outside the EU: To prevent SchlüsselBot from solely deriving the tax location from a freely chosen country field, SchlüsselBot cross-checks the country in the full invoice address with the origin country of the IP address used at checkout. Geolocation is performed exclusively locally on the SchlüsselBot server; the IP address is not transmitted to any external geolocation service. The IP is encrypted using a separately stored key and stored alongside the two country codes, timestamp, database version, and a tamper-proof signature. If the two countries do not match or no proof is available, automatic tax-free billing for third countries will not occur. Purpose and legal basis: Determination and verification of the tax location, Article 6(1)(c) GDPR in conjunction with Articles 24b and 24f of Regulation (EU) No 282/2011. Storage period: 8 years, stored together with the invoice record. Used geodata: IP geolocation by DB-IP (Country Lite, CC BY 4.0; local monthly file).

17. Data processors and recipients (Art. 28 GDPR)

We use carefully selected service providers who process personal data exclusively on our instructions and under a contract for processing data in accordance with Art. 28 GDPR. Data will only be transferred to other recipients if necessary for service delivery or if a legal basis exists.

The free core service runs exclusively within the EU and without transfer to third countries. Paid plans may involve third-country processing, where PayPal transfers data internally within the group or a contractually approved sub-processor of Lexware Office Support gains access. Message contents are not transmitted to any of these providers. The optional social login is currently disabled.

The processors and other recipients used are netcup GmbH (server infrastructure, Germany), CrowdSec SAS (attack detection, France), PayPal (Europe) S.à r.l. et Cie, S.C.A. (payment processing, Luxembourg), and Haufe-Lexware GmbH & Co. KG with Lexware Office (accounting, Germany). Their purposes and locations are shown in the table above. meinKI is not an external recipient but the same controller’s own instance.

18. International data transfers – general notes

Where we transfer data to recipients in a third country (in particular the USA), as specified in detail in this statement, this is only done

• Based on an adequacy decision by the European Commission, particularly the EU-US Data Privacy Framework (DPF), provided the recipient is certified, or
• Based on appropriate safeguards under Art. 46 GDPR, particularly the Standard Contractual Clauses (SCCs) issued by the European Commission, supplemented by an assessment of the effectiveness of additional protective measures (Transfer Impact Assessment).

You can request a copy of the respective guarantees from the controller.

19. Overview of data retention periods

Introduction to backups. The following deadlines apply to ongoing operations. Additionally, systems are backed up daily to enable service recovery after a failure. A deleted data record may still be present in these backups until the backup retention period expires (daily 7, weekly 4, monthly 12 generations). Backups are encrypted and stored on a separate, non-publicly accessible system. Message contents remain unreadable within them — the key for this is not stored anywhere. Accompanying notes (particularly sender and recipient addresses) are also encrypted, but the necessary key material is located within the same backup set. A request to delete under Art. 17 GDPR is processed immediately during normal operation; backups then expire automatically according to schedule.

The short deletion periods are technically enforced by a time-triggered, automated deletion process (Janitor) and are not dependent on retrieval.

19a. Additional data processing in your account (as of August 2026)

The following functions were added after the initial version of this statement. They are fully listed here to ensure the statement reflects the current status.

a) failed login protection protocol

After each failed login, confirmation, or retrieval attempt, we store Timepoint, type of event, and IP address in a dedicated log file. This helps prevent repeated automated attacks at the network level. We use fail2ban (entirely local, analysing only this file of failed attempts) and CrowdSec, which additionally evaluates the general access log and shares detected attack patterns with the provider's community network — see point 17.

Purpose: Protection against attacks on accounts and ensuring service availability. Legal basis: Article 6(1)(f) GDPR. Storage period: 7 days, after which automatic deletion occurs through daily rotation. A network block is automatically lifted after one hour.

b) Integration and MCP keys (API/MCP)

In the Business plan, you can generate keys for the API. These are stored with a freely chosen label, a non-secret username, a key checksum (never the key itself), individually assigned permissions, optional allowed browser origins (HTTPS origins), the creation timestamp, the last usage timestamp, and any revocation status.

You can also create a time-limited MCP connection for Claude, ChatGPT or another MCP client of your choice. Here too, only the label, non-secret identifier, checksum, tightly limited permissions, creation date, expiry date, last use and any revocation are stored. The connection link, shown once, contains the complete secret and must be treated like a password. SchlüsselBot removes this secret from its web server logs. MCP cannot read secure inbox contents or received messages, modify contacts or attach files.

Data transfer to your chosen AI provider: When you use the MCP server through an AI assistant, that provider processes your input and the data returned by the tool. A contact search may include names and email addresses from your own address book. With convenient sending via MCP, the AI provider sees the message text. The text then reaches SchlüsselBot briefly in readable form, is encrypted in memory and is not stored as plaintext. This workflow is therefore not zero-knowledge. SchlüsselBot does not send data to an AI provider on its own: you choose and connect the client yourself. Before using it, make sure you are permitted to share the relevant data with that provider. To send data without disclosing it to a provider, use the browser workflow and do not give plaintext to an AI assistant.

For safely repeatable send requests, customer software can submit an Idempotency-Key. SchlüsselBot stores this identifier, a keyed checksum of the request content that cannot be verified using the database alone, the processing status and the response for no more than 24 hours. The response may contain a one-time retrieval link and is therefore protected with authenticated encryption using a key stored outside the database. The request content itself is not stored.

Purpose: Authenticating requests from your own software or an MCP client connected by the customer, limiting access to required functions, providing secure browser integration and preventing duplicate sends after network errors. Legal basis: Article 6(1)(b) GDPR. Storage period: Metadata for standard API keys is retained until revocation or account deletion; metadata for time-limited MCP connections is retained for up to 30 days after expiry or revocation, but no longer than until account deletion; retry data is retained for no more than 24 hours.

c) Webhooks — transmission to a system specified by the customer

Business plan customers can set a custom internet address to which SchlüsselBot sends notifications about key creation, retrieval, withdrawal, expiry, or failed email delivery. The transmitted data includes Event and transaction number, timestamp, delivery status, and indication of whether an attachment was included — no content and no recipient or contact addresses. Delivery is signed with a secret and only sent to publicly accessible https addresses. The signing secret is stored by SchlüsselBot, encrypted with a key kept outside the database.

To ensure no event is lost if the target system is temporarily unavailable, each delivery is stored in a queue and repeatedly checked before the first network request. Event type and ID, empty JSON body, attempt counter, next attempt time, response status, and error text are stored.

Recipient: The target system designated by the customer. The customer defines it themselves and is responsible for its compliance with data protection regulations. Purpose: Reliable integration with the customer’s own software. Legal basis: Art. 6 para. 1 lit. b GDPR. Storage period: Recipient address and encrypted signature secret until webhook or account deletion; completed or permanently failed delivery logs retained for up to 30 days.

d) Team memberships in the Business plan

A Business account can add further accounts as members. The group admin sees for each member E-Mail address, name, date of joining, and time of last login — never messages, secure inboxes, or contacts of the members. Open invitations are stored with the target address and expiry date.

Purpose: Management of booked user slots. Legal basis: Article 6(1)(b) GDPR; if the customer uses the service for employees, they are responsible for their data (§ 26 BDSG). Storage period: Until departure from the team; invitations are retained for 14 days.

e) proof of generated order processing agreements

When a customer in the account enters into a contract under Article 28 of the GDPR, we record Contract number, company, address, named representative, version of the contract text, timestamp, and IP address. These entries are not altered or deleted while the contract remains in force — they serve as proof of when each version was concluded.

Purpose: Demonstrable compliance with supervisory authorities for both parties. Legal basis: Article 6(1)(c) in conjunction with Article 28(9) GDPR. Storage period: For the duration of the contract and subsequently at least six years from the end of the year in which the contract ended (§ 147(1) no. 2 in conjunction with (3) AO). Deletion occurs once the evidentiary purpose no longer applies; upon deletion of your account, we remove company name, address, authorised representative, and IP address, retaining only the contract number, version, and timestamp — evidence under Article 28 GDPR is specifically required for the period after the contract ends.

f) Cancellation logs

Each cancellation declaration submitted via the cancellation button is recorded with Address, name, contract reference, type of cancellation, voluntary reason, preferred date, date of receipt and IP address.

Purpose: Proof of receipt, content, and timing as required by § 312k(4) BGB. Legal basis: Article 6(1)(c) GDPR. Storage period: at least six years from the end of the year of termination (§ 147(1) no. 2 AO; the termination confirmation also serves as evidence under § 312k(4) BGB). Upon deletion of your account, we remove name, reason, desired termination date, and IP address; your email address is replaced with a hash. It is no longer plaintext but still allows us to identify the account in a dispute — therefore, we retain it within the framework of statutory evidentiary obligations; only the fact that termination was requested and confirmed at a specific point in time remains.

g2) Request for the Business plan (request form)

Processed data: Company or practice name, your name (voluntary), email address, phone number (voluntary), desired number of seats, call-back request, and a voluntary message (up to 1,000 characters). Purpose: To provide you with the requested offer and subsequently activate the chosen plan. Legal basis: Article 6(1)(b) GDPR (actions taken in response to your request, prior to contract conclusion). Storage: The information is not permanently stored in our database. For up to 25 hours, your address is stored there as a counter against misuse — to prevent anyone from using the form as a mass-sending tool; after that, it is automatically deleted. The data is transmitted exclusively by email to our inbox office@messingerdesign.de, where it is processed; an acknowledgement of receipt is sent to the email address you provided. Recipient: This inbox is operated by a hosting service provider in Germany; they act as a data processor under Article 28 GDPR. Storage period: Until final processing of your request, up to 12 months; if a contract is concluded, the commercial and tax retention periods apply (Section 16). Voluntary: Mandatory fields are only company and email address — without them, we cannot provide an offer. Phone number and message are voluntary; if no phone number is provided, we will contact you by email. No advertising: We use this information solely to respond to your request and will not send you any marketing material without your explicit consent (§ 7 UWG).

g) Processing of incoming spam messages

We operate an email address that is specifically designed for automated address harvesters and is not visible to humans. All messages received there are classified as unwanted and used to train our own spam filter.

Purpose: Protection of our own email infrastructure against unwanted messages. Legal basis: Article 6(1)(f) GDPR. No information to senders under Article 14 GDPR is provided, as this would target senders of unwanted mass mailings and would involve disproportionate effort (Article 14(5)(b) GDPR).

20. Your rights as a data subject (Art. 12–22 GDPR)

You have the following rights regarding your personal data, as the data subject:

• Right of access (Article 15 GDPR),
• Correction (Article 16 GDPR),
• Deletion (Art. 17 DSGVO),
• Restriction of processing (Art. 18 GDPR),
• Data portability (Art. 20 GDPR),
• Objection to processing (Art. 21 GDPR, see clause 21),
• Withdrawal of consent with effect for the future (Art. 7 para. 3 GDPR).

To exercise your rights, a non-formal communication to the contact details listed under point 1 is sufficient.

20.1 Special consideration for server-blind service (Art. 11 GDPR)

For unencrypted data (in particular recipient email address, account and payment details), we provide access, correction, and deletion within the legal scope.

For encrypted content and attachments, there is a conceptually inherent limitation: With the "Secure" sending method and the E2E passphrase secure inbox, we technically lack the decryption key entirely; thus, we cannot provide content-based access or corrections (Art. 11 GDPR). In all other secure inbox levels, ciphertext and encrypted fragment copy are separated both organisationally and technically, but the process is clearly assigned to the registered secure inbox holder. We process data subject requests there based on available metadata; no content decryption occurs as part of standard service.

You still retain full control: You can trigger the Deletion of a specific encrypted process at any time via its identifier or link; regardless, our Janitor process automatically deletes every process no later than 48 hours after transmission (or according to the chosen period in paid plans, up to seven days), or immediately after retrieval.

21. Right to object (Art. 21 GDPR)

You have the right to object, at any time, to the processing of your personal data that is based on Article 6(1)(f) of the GDPR, on grounds relating to your particular situation.

This applies in particular to the Delivery of notifications to a recipient address supplied by a sender (point 7), maintenance of the delivery-block list (point 7), processing of IP addresses to prevent abuse (point 11.1), server logs, and the internal daily statistics under point 12.1. Enhanced meinKI analytics, by contrast, is based solely on your consent and may be stopped with future effect through Privacy settings. If you object, we will cease processing the data concerned unless we can demonstrate compelling legitimate grounds that override your interests, rights, and freedoms, or the processing is necessary for the establishment, exercise, or defence of legal claims. In addition, for delivery to a recipient address: we neither investigate nor balance interests; a message to our abuse address is sufficient, and we will permanently stop sending to you. We do not automatically delete this entry (Article 17(3)(e) GDPR); we remove it only at your request.

22. Right to lodge a complaint with a supervisory authority

Without prejudice to any other administrative or judicial remedy, you have the right to lodge a complaint with a data protection supervisory authority (Article 77 GDPR), in particular in the Member State of your habitual residence, place of work, or the place of the alleged infringement.

The supervisory authority responsible for the data controller is:

Berlin Commissioner for Data Protection and Freedom of Information Alt-Moabit 59–61, 10555 Berlin Phone: +49 30 13889 -0 Email: mailbox@datenschutz-berlin.de

23. Obligation to provide data

Providing the Recipient email address is required for using the core functionality: without it, we cannot carry out the transmission process you have instructed. There is no legal or contractual obligation to provide it; however, you will only miss out on using the feature — there are no other disadvantages.

In comfort mode, providing a Sender address is voluntary. In security mode, it is required for neutral shipping confirmation: For an account, we use its confirmed email address; for anonymous shipping, a separate sender address must be provided. Without this address, security mode cannot be used. There is no legal obligation to provide it. The creation of a Accounts as well as the use of Social login and paid functions remain voluntary.

For submissions through a receiving secure inbox, its holder may mark the sender name, subject and individual template fields as required. This creates no statutory obligation towards us. Without a required sender name or subject, that particular form cannot be submitted. Template fields marked as required are requested once the submitter enters information in that template; a completely unused template can be skipped and a free-form message sent instead. Values entered into template fields reach us only as ciphertext (Section 6.3(c)).

24. No automated decision-making / no profiling

A decision based solely on automated processing — including profiling — that has legal effect on you or significantly affects you in a similar way does not take place. Automated processing occurs only in the case of adding an email address to our delivery blocklist when the recipient’s mail server permanently rejects it, and in the case of a temporary network block after repeated failed attempts. Both relate solely to technical deliverability, not to any assessment of your person; you may have the entry removed at any time by contacting the address listed in Clause 1. We will review your request manually. The security measures we use (e.g. rate limiting) serve exclusively to prevent abuse and do not result in profiling of your person.

25. Data security (technical and organisational measures, Art. 32 GDPR)

We implement appropriate technical and organisational measures to protect your data, in particular:

• Client-side end-to-end-like encryption (except for plaintext transfer via the programming interface, see clause 6.3) of the content; technically enforced server blindness in security mode and in E2E passphrase secure inbox,
• for other secure-inbox levels, an AES-256-GCM-encrypted, time-limited fragment copy on the Edge server, with a root-protected server key kept separate from the database, Vault server and application backups,
• when sending via our send form, the option to choose a sending method where we never receive the key (security mode ("Secure"), section 6.3)
• Separation into edge and vault servers, encryption of content even at rest (at-rest),
• Exclusive hash storage of one-time codes and comparison in constant time,
• Password hashing with Argon2id and two-factor authentication,
• Rate limiting and abuse prevention,
• strict logging minimisation (no keys, one-time codes, URL fragments or plaintext content in logs),
• Time-based, final deletion (Janitor process, "Crypto-Shredding"); for continued existence in encrypted backups, see the introductory note to clause 19,
• TLS encryption of data transfer.

26. Changes to this privacy policy

We reserve the right to update this privacy policy to align with changes in legislation or modifications to the service and data processing activities. The version available at the time of your visit will apply. You can find the current version at the beginning of this statement.

As of: September 18, 2026