{"success":true,"data":{"id":"01a11f24-e05a-7104-af9f-08fb323c72b1","group":"emx-terms","locale":"en","slug":"emx-terms","version":"1.1","title":"EMX Terms of Service","description":"Terms for EMX, the hosted business mail service, including the data processing agreement, the sub-processors and the implemented technical measures.","body_markdown":"# EMX Terms of Service\n\n**Version:** 1.1\n**In effect from:** 9 October 2026\n**Provider:** Krauss Software, sole proprietorship of Samuel Krauss, Im Ländli 18, 6315 Oberägeri ZG, Switzerland, trading as Elchi Studios (\"EMX by Elchi Studios\")\n**Contact:** legal@elchi.dev; support at contact@elchi.dev; reports of abuse to abuse@emxmail.ch\n**Applies to:** EMX, the hosted business mail service: the web client and the\nAPI at mail.emxmail.app, the mail server mx.emxmail.ch, and the use of the\nservice through mail apps and the programs published for EMX\n\nThe version in effect and every earlier one are published at legal.elchi.dev/en/emx-terms.\n\n---\n\n## 1. Who these terms are between\n\n1.1 These terms govern the use of EMX, a hosted mail service operated by\n**Krauss Software** (\"we\", \"us\"), the sole proprietorship of Samuel Krauss,\nseated in Oberägeri, Canton of Zug, Switzerland. Krauss Software is not\nentered in the commercial register. Samuel Krauss, as its owner, is\npersonally liable for its obligations. Elchi Studios is the name under which\nthe service is presented.\n\n1.2 The \"customer\" is the business that creates an organisation in EMX: a\nlegal entity, or a natural person acting in their trade or profession. EMX is\noffered only to businesses and only for their business purposes, on every\nplan including the free one. It is not offered to consumers.\n\n1.3 The person who creates the organisation and accepts these terms confirms\nthat they are authorised to bind the customer. If that authority is missing,\nthey are liable to us as the law provides for a person acting without\nauthority.\n\n1.4 \"People\" are the natural persons to whom the customer gives a mailbox or\naccess to EMX. They use EMX on the customer's behalf, and the customer is\nresponsible for their use of it as for its own. People sign in through EAuth,\nour sign-in service; what that involves is described in Annex A.\n\n1.5 These terms alone govern EMX. The general terms and conditions of Elchi\nStudios for software, websites and hosting and the EAuth Terms of Service do\nnot apply to EMX, and\nneither do terms of the customer. Where we and the customer sign a separate\nwritten contract for EMX, such as for the Enterprise plan, that contract\nprevails over these terms where it differs.\n\n---\n\n## 2. The service\n\n2.1 EMX is mail on the customer's own domains: mailboxes for its people,\nshared mailboxes, groups and aliases; a web client; IMAP and SMTP submission\nfor mail apps such as Outlook, Apple Mail and Thunderbird, including the\nshared mailboxes a person is a member of; automatic replies, forwarding and\nrules that file mail on the server; a filter for spam on incoming and outgoing\nmail, which refuses attachments that are programs, also inside archives; an\nAPI and webhooks; and an export of the mail. A scan for known viruses runs\nonly while a virus scanner is connected to EMX. At the time of this version\nnone is, because the platform EMX runs on does not offer one yet (Annex B,\nB.6). An automatic reply goes only to a sender whose domain passes SPF or\nDMARC, with the subject the person set or a fixed one, and counts against the\nsending limits in 6.3. The documentation at docs.elchi.dev/emx describes the\nservice as it is.\n\n2.2 EMX does not include, at the time of this version: calendar and contacts\n(CalDAV and CardDAV), Exchange ActiveSync, a mobile app of its own, signed\ninstallers for the desktop app, or an archive that meets the requirements of\nthe Swiss ordinance on the keeping of business records (GeBüV). We make no\npromise as to whether or when any of these will be offered.\n\n2.3 We develop EMX further and may change it. We give at least 30 days'\nnotice by email before we remove a feature the customer uses to a material\nextent, and the customer may then end the contract with effect from the day\nof the change. Changes to the API follow the versioning rule in the API\nreference.\n\n2.4 **Sealed mailboxes.** Where the organisation allows it, a person can seal\ntheir own mailbox. By default only an organisation of one person allows it;\nits owners can change that (Section 9.3). From then on, each message,\nincluding its subject, its sender and its recipients, is stored encrypted to a\nkey of the person's. We keep that key only encrypted to the person's recovery\ncode and to a passkey or a passphrase of theirs, none of which we ever see.\nMail that was in the mailbox before it was sealed is not sealed and stays\nreadable as before. Neither the customer nor we can open a sealed message. Our\nservers handle a message in clear only while it is being received or sent. A\nsealed mailbox cannot be read in a mail app, its mail cannot be searched on\nthe server, it sends no automatic replies and forwards nothing, and of its\nrules only those on the size of a message apply. If the person loses their\nrecovery code and every passkey and passphrase, the sealed mail cannot be\nrecovered by anyone. Annex B, B.1, says exactly what is encrypted and what is\nnot.\n\n2.5 **The customer's own Resend account.** For a domain, the customer may\nchoose to send its outgoing mail through its own account at Resend, Inc.\ninstead of through EMX's own mail servers. EMX then hands that domain's\noutgoing mail to Resend with the customer's key. Resend acts under the\ncustomer's own contract with Resend, as the customer's provider and not as\nours. Otherwise EMX sends all mail through its own mail servers and uses no\nthird party to send it.\n\n---\n\n## 3. Sign-up, plans and payment\n\n3.1 The contract is concluded when the person signing up creates the\norganisation in EMX and accepts these terms. We record the version accepted\nand the time. Where we create the organisation for the customer, the contract\nis concluded instead by a written contract signed by both parties.\n\n3.2 The plans are Private (free of charge, for one mailbox on one domain),\nTeam (charged per mailbox and month) and Enterprise (on request, under a\nseparate written contract). Their scope and limits are those in Section 6\nand in the documentation. There is no trial period.\n\n3.3 The Team plan is a subscription taken out through Stripe Checkout. The\nprice per mailbox and month, and any value added tax, are those shown at\ncheckout before the customer pays and on the invoice. Prices are stated in\nSwiss francs.\n\n3.4 The subscription is charged monthly in advance, to the payment method the\ncustomer gives Stripe. The number of mailboxes charged follows the personal\nmailboxes in the organisation; when it changes, Stripe charges or credits the\ndifference pro rata. Invoices are available in the billing portal, which\nadministrators open from the administration of the organisation in EMX.\n\n3.5 If a payment fails, Stripe tries again. If the Team subscription ends,\nbecause it was cancelled in the billing portal or because payment remains\noutstanding, and the organisation has not been cancelled, EMX suspends the\norganisation at the end of the billing period already paid: it can no longer\nsend mail, but it still receives mail, and its people can still read and\nexport their mail. EMX tells the organisation's owners. If within 30 days the\nsubscription is neither taken out again nor the organisation cancelled, EMX\ncancels the organisation, and Sections 4.2 and 8.5 apply from then on.\n\n3.6 We may change prices with 30 days' notice by email. A change applies from\nthe first billing period that starts after the notice period. The customer\nmay cancel before then under Section 4.2.\n\n3.7 Stripe (Stripe Payments Europe, Limited, Ireland) processes the payment\ndata under its own terms, as an independent party. We do not receive or store\nfull card details.\n\n---\n\n## 4. Term and ending the contract\n\n4.1 The contract runs for an indefinite period. A Team subscription renews\neach month.\n\n4.2 The customer may end the contract at any time by cancelling the\norganisation in EMX, which only an owner of the organisation can do. The\ncontract ends at that moment: from then on the organisation sends and receives\nno mail, and Section 8.5 applies. During the 30 days in Section 8.5 an owner\ncan undo the cancellation, and the contract then continues.\n\n4.3 Cancelling the organisation also ends a Team subscription, at the end of\nthe monthly billing period already paid. Fees for a billing period that has\nstarted are not refunded. Ending only the Team subscription, in the billing\nportal, does not end the contract; Section 3.5 then applies.\n\n4.4 We may end the contract with three months' notice to the end of a\ncalendar month. If we discontinue EMX as a whole, we give every customer at\nleast twelve months' notice.\n\n4.5 Either party may end the contract with immediate effect for good cause,\nin particular if the other party seriously or repeatedly breaches these terms\nand does not remedy the breach within a reasonable period after a written\nwarning, unless a warning would be pointless.\n\n4.6 Section 8.5 governs what happens to the data when the contract ends.\n\n4.7 If the only person of an organisation asks for their EAuth account to be\ndeleted, we cancel the organisation for them that day; it is deleted when the\naccount is, 30 days after the request. Until then Section 8.5 applies, and if\nthe person keeps the account, we undo the cancellation. Where other people\nwork in an organisation, deleting the account ends only that person's access;\nthe customer decides about their mailbox under Section 9.\n\n---\n\n## 5. Availability and support\n\n5.1 **We give no availability commitment.** There is no service level\nagreement, no availability figure we promise, and no credit for downtime. We\nwould rather say so than publish a figure we cannot yet stand behind.\n\n5.2 What we do instead is described in Annex B, B.5: EMX runs on two\napplication servers at two providers in two countries, every database write\nis confirmed on three servers, and the stored messages are copied every night\nto a second provider.\n\n5.3 While EMX cannot be reached, servers sending mail to the customer\nnormally keep it and try again, usually for several days; how long is decided\nby the sending server and not by us. EMX tries to deliver outgoing mail for\nfive days and then returns it to the sender as undeliverable.\n\n5.4 We carry out maintenance so that it interrupts the service as little as\npossible.\n\n5.5 Support is given in German and English through the console at\npanel.elchi.dev or at contact@elchi.dev. We aim to answer within one working\nday (Monday to Friday, except public holidays in the Canton of Zug). This is\nan aim, not a commitment.\n\n---\n\n## 6. Acceptable use and limits\n\n6.1 The customer and its people must not use EMX to:\n\n- send unsolicited mass advertising, or mail to addresses that were bought,\n  harvested or otherwise obtained without the recipients' consent;\n- send malware, or links to it;\n- send phishing, or otherwise deceive recipients about who is writing, such\n  as by forging senders or imitating another organisation;\n- send, store or make available content whose sending or possession is\n  unlawful, in particular depictions of sexual abuse of children, content\n  that incites violence or hatred, and content that infringes the rights of\n  others;\n- harass or threaten people;\n- relay mail for third parties, or resell EMX without a separate written\n  agreement;\n- circumvent the limits in 6.3, probe or test the security of EMX without\n  our written permission, or impair the service for others.\n\n6.2 Newsletters and other mail to many recipients are permitted only to\nrecipients who have consented, with a working way to unsubscribe, and within\nthe limits in 6.3. EMX is not a mass mailing service.\n\n6.3 These limits apply:\n\n| Limit | Private | Team |\n|---|---|---|\n| Recipients outside EMX per person and hour | 300 | 300 |\n| Recipients per person and calendar day (counted from midnight Swiss time) | 200 | 1,000 |\n| Recipients per organisation and calendar month | 1,000 | 30,000 |\n| Storage per mailbox | 10 GB | 50 GB |\n| Size of one message, attachments included | 50 MB | 50 MB |\n| Recipients of one message | 100 | 100 |\n| Mailboxes and domains | one each | no limit |\n| Requests to the API | 600 per minute and token | 600 per minute and token |\n\nA message that would go over a sending limit is refused. Going over a limit\nonly refuses that message; it does not stop the person's sending. Outgoing\nmail is checked by the filter in Annex B, B.6, as incoming mail is (Section\n7.5). Receiving mail is limited only by the size of a message and the storage\nof the mailbox; while a mailbox is full, EMX asks the sending servers to try\nagain later. On the Enterprise plan the limits are those of the contract.\n\n6.4 We may lower a limit with 30 days' notice. To stop abuse we may, at once\nand for as long as needed, lower the daily limit of one person or stop their\nsending (Section 7).\n\n6.5 Abuse is reported to abuse@emxmail.ch. How we handle reports is described\nat docs.elchi.dev/emx-abuse.\n\n---\n\n## 7. Suspension\n\n7.1 We may suspend the sending of mail, or access to EMX, for a person, a\nmailbox or the whole organisation, if:\n\n- there are concrete indications of use contrary to 6.1;\n- an account appears to be compromised;\n- mail sent from the organisation endangers the delivery of other customers'\n  mail, for instance by putting our servers on block lists;\n- an authority or a court orders it; or\n- the Team subscription has ended while the organisation has not been\n  cancelled (Section 3.5).\n\n7.2 Where the situation permits, we warn the customer first and give it\nreasonable time to remedy the problem. Where it does not, we suspend first\nand inform the customer's administrators within one working day, with the\nreason, unless the law or an order forbids it.\n\n7.3 We choose the least restrictive measure that is effective, such as\nstopping the sending of one person, or lowering their daily limit, rather than\nsuspending the whole organisation, and lift it as soon as its cause has been\nremoved. Suspension never deletes data.\n\n7.4 A justified suspension gives no claim to damages or to a reduction of\nfees.\n\n7.5 **Automatic stop.** If a person's outgoing messages are refused repeatedly\nas spam or because they carry malware, EMX stops that person's sending on its\nown. Only such refusals stop a person; a message refused for going over a\nlimit in 6.3 does not. A stopped person's mail is refused until an\nadministrator of the organisation, or we, lift the stop. The administrators\nsee the stop and its reason in the administration of the organisation, and it\nis recorded in the organisation's audit log.\n\n---\n\n## 8. Data, export and deletion\n\n8.1 The customer's mail and data belong to the customer. We claim no rights\nto them and process them only to provide EMX, as Annex A describes.\n\n8.2 The customer can take its mail out at any time without asking us: each\nperson can export their mailbox, and the shared mailboxes they may read, as\na file in the web client; mail apps read all of it over IMAP; and the API\ngives access to every message.\n\n8.3 When the customer removes a person, that person's access ends at once.\nWhen removing them, or during the following 30 days, an administrator can turn\nthe person's mailbox into a shared mailbox, or hand its mail to a colleague,\nwho can then read and export it. Sealed messages stay unreadable to everyone\n(Section 9.3). A mailbox that is not handed on in one of these ways is deleted\nafter 30 days. Administrators cannot export another person's mailbox directly.\n\n8.4 When the customer removes a domain, EMX stops accepting and delivering\nmail for it at once and stops signing mail with its keys. Mail already\nreceived stays in the mailboxes.\n\n8.5 **When the contract ends** (Section 4.2), the organisation sends and\nreceives no mail any more, and EMX keeps its data for 30 days. During that\ntime its people can still sign in, read their own mail and export it, and its\nowners can export all mailboxes of the organisation. The billing portal is\nclosed while the organisation is cancelled. An owner can undo the cancellation\nduring the 30 days. If the Team subscription had ended by then, the undo\nleaves at least 7 days to take it out again before the cancellation under\nSection 3.5 starts again. After 30 days we delete the mailboxes with their\nmessages, the people, the domains and the rest of the organisation's data. On\nrequest we confirm the deletion in writing.\n\n8.6 Deleted data also disappears from the copies of the message bodies\nwithin a few days, and from the database backups when they are replaced in\nthe normal backup cycle. We restore from backups only to recover the service\nafter a failure, never to bring back a customer's data that was deleted.\nRecords we must keep by law, such as invoices (Art. 958f OR), are kept for as\nlong as the law requires.\n\n8.7 The export of a sealed mailbox contains its messages as they are stored:\nencrypted. The person can open them with their key, for instance with their\nrecovery code and the age tool.\n\n8.8 EMX is not an archive. Where the customer must keep business records,\nsuch as under Art. 958f OR and the GeBüV, it is responsible for doing so,\nfor example by exporting the mail it must keep.\n\n---\n\n## 9. The mail of people who leave, and access by the organisation\n\n9.1 The customer is the controller of the mail in its organisation. It\ndecides, within the law, who may read a person's mailbox when that person\nleaves or is absent. It must observe the protection of its employees'\npersonal data (Art. 328b OR) and the applicable data protection law, and\ninform its people of its rules in advance.\n\n9.2 EMX gives administrators no way to read or export the mailbox of a person\nwho is active in the organisation. One thing they do see: where the\norganisation chooses to hold suspected spam in a quarantine instead of filing\nit in the person's junk folder, its administrators see the sender, the\nrecipients and the subject of each held message, so that they can release or\ndelete it. When the customer removes a person, its administrators can deal\nwith that person's mailbox only as Section 8.3 describes. Every such step is\nrecorded in the organisation's audit log.\n\n9.3 Mail in a sealed mailbox cannot be opened by anyone other than the person\nwho sealed it: not by the organisation and not by us. If that person leaves\nwithout making their mail available, the organisation cannot read it, and it\nis not handed on with the rest of the mailbox. The owners of the organisation\ndecide whether its people may seal their mailboxes; by default only an\norganisation of one person allows it. Turning sealing off does not unseal a\nmailbox that is already sealed. The customer should agree with its people\nwhether business mail may be kept in a sealed mailbox.\n\n9.4 We do not open a person's mail on behalf of the customer. The functions\nof EMX described here are the way to reach it. Section A.11 of Annex A\ngoverns requests from authorities.\n\n---\n\n## 10. The customer's responsibilities\n\n10.1 The customer keeps the details of the organisation and its billing\ncontact accurate.\n\n10.2 The customer ensures that its people keep their sign-in details and app\npasswords secret, and that a lost device's app password is revoked. We\nrecommend a second factor for every person. A suspected compromise is\nreported without undue delay to security@elchi.dev.\n\n10.3 The customer may only add domains it is entitled to use, and is\nresponsible for their DNS records. Mail for a domain reaches EMX only once\nthe domain's MX record points to it.\n\n10.4 The customer ensures that its people comply with Section 6, informs them\nabout EMX and the processing of their data, and answers the requests of data\nsubjects whose data is in its mail, with the tools of EMX and our help under\nAnnex A.\n\n---\n\n## 11. Data protection\n\n11.1 For the personal data in the customer's mail and in the accounts of its\npeople, the customer is the controller and we are its processor. Annex A is\nthe data processing agreement and forms part of these terms.\n\n11.2 For our own purposes, namely concluding and performing the contract,\nbilling, contact with the customer, the security of the service and handling\nabuse, we are the controller. For these purposes we process the details of\nthe organisation and its billing contact, the administrators' contact\ndetails and the logs described in Annex B, B.7.\n\n---\n\n## 12. Liability\n\n12.1 We are liable without limitation for damage caused intentionally or by\ngross negligence (Art. 100 para. 1 OR), for personal injury, and wherever\nelse the law does not permit liability to be limited in advance. Nothing in\nthese terms limits that liability.\n\n12.2 For slight negligence, our liability is limited to direct damage and, in\ntotal for all claims arising in a calendar year, to the greater of the fees\nthe customer paid for EMX in the twelve months before the event causing the\ndamage and CHF 500. Liability for indirect and consequential damage, in\nparticular lost profit, is excluded for slight negligence.\n\n12.3 If mail or data is lost for a reason for which we are responsible, we\nrestore it from the most recent copy available and bear the cost. Further\nclaims for the loss exist only under 12.1 and 12.2.\n\n12.4 We are not liable for the content of mail sent or received by the\ncustomer, for the loss of sealed mail whose keys were lost (Section 2.4), for\nthe services of the customer's own Resend account (Section 2.5), for other\nservers that refuse or delay mail or file it as spam, or for events beyond our\nreasonable control.\n\n12.5 We are liable for the people we engage, including our sub-processors,\nas for our own conduct.\n\n12.6 The customer indemnifies us against claims of third parties arising from\nuse of EMX contrary to these terms by the customer or its people, unless we\nare responsible for the claim.\n\n---\n\n## 13. Changes to these terms\n\n13.1 We give at least 30 days' notice of a change to these terms by email to\nthe organisation's administrators and its billing contact.\n\n13.2 If the customer does not agree, it may end the contract before the change\ntakes effect, under Section 4.2. Otherwise the new version applies from the\nday stated. A change required by law, or needed at once to protect the\nsecurity of the service, may take effect sooner; we say so in the notice.\n\n13.3 Every version of these terms remains published, with its date, so that\nit can be seen what applied when.\n\n---\n\n## 14. Final provisions\n\n14.1 Swiss law applies, excluding its conflict of laws rules and the United\nNations Convention on Contracts for the International Sale of Goods.\n\n14.2 The exclusive place of jurisdiction is Zug, Switzerland. We may also\nbring proceedings at the customer's seat.\n\n14.3 If a provision of these terms is invalid, the rest remains in force, and\nthe invalid provision is replaced by a valid one that comes as close as\npossible to what it intended.\n\n14.4 These terms are published in German and in English with the same\ncontent. If the two versions differ, the German version prevails.\n\n14.5 Notices to the customer go by email to the addresses in the\norganisation's administration. Notices to us go to legal@elchi.dev.\n\n14.6 The customer may transfer the contract only with our written consent.\nWe may transfer it to a company that continues the business of Krauss\nSoftware, with notice by email; the customer may then end the contract with\neffect from the transfer.\n\n---\n\n## Annex A: Data Processing Agreement\n\nThis annex is the agreement on the processing of personal data on behalf of\nthe customer required by Art. 9 of the Swiss Federal Act on Data Protection\n(revDSG) and by Art. 28 of the General Data Protection Regulation (GDPR),\nwhere that applies. It forms part of these terms and needs no separate\nsignature. Terms not defined here have the meaning given in the revDSG and\nthe GDPR.\n\n### A.1 Subject matter and duration\n\nWe process personal data for the customer in order to provide EMX, for as\nlong as the contract runs and until the deletion described in A.15.\n\n### A.2 Nature and purpose\n\nReceiving, filtering incoming and outgoing mail for spam and harmful\nattachments, storing, indexing for search, displaying, synchronising, sending\nand exporting mail; managing the organisation's people, mailboxes, domains and\nrights; recording security and access events; and making the backups and\ncopies described in Annex B.\n\n### A.3 Data subjects\n\nThe customer's people; the people who write to them or receive mail from\nthem; and the people named in that mail.\n\n### A.4 Categories of personal data\n\n- Account data: names, addresses, roles, the identifier of the person's\n  sign-in, preferences, signatures, and digests of app passwords and tokens.\n- The content of messages and attachments, of any kind.\n- Message data: sender, recipients, subject, times, size, flags and folder.\n- The full-text search index of mailboxes that are not sealed.\n- The senders a person has allowed or blocked.\n- Logs: sign-ins, administrative actions and IP addresses, as described in\n  Annex B, B.7.\n- Push subscriptions of browsers in which a person has turned on\n  notifications.\n\nMail can contain sensitive personal data in the sense of Art. 5 lit. c\nrevDSG and Art. 9 and 10 GDPR, such as health data. EMX processes such data\nlike any other mail. Whether the customer may send and keep it by mail is the\ncustomer's decision and responsibility.\n\n### A.5 Instructions\n\nWe process the data only on the customer's documented instructions. These\nterms and the customer's settings in EMX are those instructions. If we\nconsider that an instruction infringes data protection law, we tell the\ncustomer and may suspend carrying it out until it is clarified. We process\nthe data for other purposes only where the law obliges us to, as described\nin A.11.\n\n### A.6 Confidentiality\n\nEveryone we authorise to process the data is bound by a written duty of\nconfidentiality that continues after their engagement ends. We do not read\nthe customer's mail. Where looking at a message is unavoidable, such as for\na message a person sends us to resolve a problem, we look at it only as far\nas necessary.\n\n### A.7 Security\n\nWe take the technical and organisational measures in Annex B. We may change\na measure, but not in a way that lowers the overall level of protection.\n\n### A.8 Sub-processors\n\nThe customer gives general authorisation for the sub-processors listed here:\n\n| Company | What it does for EMX | What it sees | Where |\n|---|---|---|---|\n| Infomaniak Network SA | Runs an application server (web client, API and mail ports), the object storage for the message bodies, and the server that watches the others | Everything EMX processes; message bodies are stored there only encrypted (Annex B, B.1) | Geneva, Switzerland |\n| Tavuru | Runs the primary database server; outgoing mail leaves through its address | The database (Annex B, B.1 says what in it is not encrypted); outgoing mail in transit, encrypted where the receiving server supports TLS | Frankfurt, Germany |\n| Hetzner Online GmbH | Runs a database replica and one of the two edge proxies, where HTTPS ends | The database; the requests of the web client and the API in transit | Nuremberg and Falkenstein, Germany |\n| Scaleway SAS | Runs an application server, a database replica, the nightly copy of the message bodies and an encrypted copy of the database backups | Everything EMX processes, as for Infomaniak and Tavuru | Amsterdam, Netherlands, and Paris, France |\n| UpCloud Oy | Runs the second edge proxy, where HTTPS ends | The requests of the web client and the API in transit | Amsterdam, Netherlands |\n| ClouDNS Ltd. | Answers the DNS name behind every host with the edge proxies that are healthy | DNS queries only, no message or account content | Sofia, Bulgaria |\n| Spamhaus Technology Ltd, through its Data Query Service (DQS) | Answers whether the IP address of a server sending mail to EMX, or a domain a message links to, is on the Spamhaus block lists | Those IP addresses and domains; no message content | United Kingdom; its name servers also elsewhere (A.9) |\n| Resend, Inc. | Sends the mails of the sign-in service EAuth to the customer's people, such as confirmations of their address and password resets | The recipient's address and the subject and text of those mails | Sent from its European Union region, stored in the United States |\n\nResend does not send the customer's mail. EMX sends it through its own mail\nservers, except for a domain for which the customer has chosen its own Resend\naccount (Section 2.5).\n\nThese are not sub-processors and receive no content of mail: Stripe, which\nprocesses payment data as an independent party (Section 3.7); Cloudflare,\nwhich holds the DNS zones of our domains; and the push services of browser\nmakers, which carry a notification, encrypted end to end to the browser, only\nto a browser in which a person has turned notifications on.\n\nWe give at least 30 days' notice by email before adding or replacing a\nsub-processor. If the customer objects on reasonable data protection grounds\nwithin that period and we cannot accommodate the objection, the customer may\nend the contract with effect from the change. Every sub-processor is bound\nby data protection obligations no weaker than this annex, and we remain\nliable to the customer for them.\n\n### A.9 Transfers abroad\n\nThe data is processed in Switzerland and in Germany, the Netherlands, France\nand Bulgaria, and Spamhaus Technology Ltd is in the United Kingdom. These\nstates, the United Kingdom included, provide adequate protection under Annex 1\nof the Swiss Data Protection Ordinance (DSV), and the European Commission has\nfound Switzerland and the United Kingdom adequate (Art. 45 GDPR). The name\nservers through which Spamhaus answers the questions in A.8 can also be in\nother states; a question carries only the IP address of a sending server or a\ndomain a message links to, and no content of mail.\n\nOne transfer goes outside both: Resend, Inc. stores the mails of the sign-in\nservice in the United States. For data from Switzerland it rests on the\nstandard contractual clauses in Resend's data processing agreement, as\nadapted for Swiss law (Art. 16 para. 2 lit. d revDSG). For data subject to\nthe GDPR it rests on Resend's certification under the EU-U.S. Data Privacy\nFramework (Art. 45 GDPR), with those clauses in addition (Art. 46 para. 2\nlit. c GDPR).\n\nData held by a provider in another state can be reached by that state's\nauthorities under its law, through the provider. Message bodies held by our\nproviders are encrypted with a key that is not kept with the stored data; the\ndatabase is not encrypted in that way (Annex B, B.1).\n\nIf the customer sends through its own Resend account (Section 2.5), that\ntransfer is the customer's.\n\n### A.10 Data subject rights\n\nIf a data subject asks us to exercise their rights, we forward the request\nto the customer without undue delay and do not answer it ourselves. EMX\ngives the customer the tools to answer: export, correction and deletion.\nWhere these are not enough, we help the customer at no charge.\n\n### A.11 Requests from authorities\n\nWe disclose the customer's data to an authority only where Swiss law\nobliges us to, on an order of a competent Swiss authority. Requests from\nforeign authorities must go through Swiss mutual legal assistance. We tell\nthe customer about a request without delay, unless the law or the order\nforbids it. How we handle requests, and what data exists, is described at\ndocs.elchi.dev/emx-authorities.\n\n### A.12 Assistance\n\nWe help the customer, taking into account the nature of the processing and\nthe information available to us, with the security of the processing, with\nnotifying breaches of data security, and with data protection impact\nassessments and prior consultations (Art. 22 to 24 revDSG, Art. 32 to 36\nGDPR).\n\n### A.13 Breaches of data security\n\nWe notify the customer of a breach of data security that affects its data\nwithout undue delay, and in any case within 72 hours of becoming aware of\nit. The notice describes the nature of the breach, as far as known the\ncategories and approximate number of data subjects and records concerned,\nthe likely consequences, and the measures taken or proposed. We notify the\ncustomer even where we are not certain that the breach affects it, because\nthat judgement is the customer's.\n\n### A.14 Audits\n\nThe customer may request the information needed to show that this annex is\ncomplied with once per calendar year, and after a breach affecting its data.\nNo certification or independent audit of EMX exists; we say so rather than\nlet the customer assume otherwise. An audit on site requires 30 days'\nnotice, must not disrupt the service or disclose other customers' data, and\nis at the customer's cost.\n\n### A.15 Deletion and return\n\nWhen the contract ends, the customer can make a final export for 30 days, as\nSection 8.5 describes. We then delete the data, as Sections 8.5 and 8.6\ndescribe, unless the law requires us to keep it. On request we confirm the\ndeletion in writing.\n\n---\n\n## Annex B: Technical and organisational measures\n\nThese are the measures in place, not a general list. Where something is not\nprotected, this annex says so.\n\n### B.1 Encryption\n\n- **Message bodies.** Every message, with its attachments, is compressed and\n  encrypted with AES-256-GCM under a master key before it is stored in the\n  object storage. The object storage and its nightly copy hold only\n  ciphertext.\n- **The master key** is held in the platform's secret store and in the\n  operator's password manager, and is not part of any backup.\n- **What is not encrypted in this way:** the database. It holds, for\n  mailboxes that are not sealed, the sender, recipients, subject, times,\n  flags and folder of each message, a short preview, and the full-text index\n  for search built from the subject, the people and the text. It also holds\n  the account data of Annex A, A.4.\n- **Secrets** are encrypted with the master key: the private keys for DKIM,\n  the stored tokens of the sign-in service, the keys of the customer's own\n  Resend accounts, the secrets of webhooks, the passwords given for importing\n  mail, and the account and keys for the certificate of the mail server.\n- **App passwords, API tokens and session tokens** are stored only as SHA-256\n  digests. An app password is 100 random bits and is shown once.\n- **Sealed mailboxes.** Each message, including its subject, sender and\n  recipients, is encrypted with age (X25519) to the mailbox's public key as\n  soon as it is received or sent. The private key is kept on the server only\n  encrypted to the person's recovery code and to a passkey or a passphrase,\n  none of which the server sees. Mail that was in the mailbox before it was\n  sealed is not encrypted in this way. What stays readable to the server is\n  the time a message arrived, its size, its folder and its flags, and for mail\n  sent to other servers the delivery record in B.7. Sealed messages are not\n  indexed for search on the server, and IMAP is not available for them. While\n  a message is being received or sent, the server handles it in clear.\n- **In transit.** The web client and the API are served over HTTPS only.\n  HTTPS ends at our edge proxies, and from there requests travel over our own\n  encrypted network between the servers. The mail ports use TLS 1.2 or newer;\n  passwords are accepted only after TLS has been established. Outgoing mail\n  is sent with TLS whenever the receiving server offers it, and only with TLS\n  where the receiving domain requires it through MTA-STS. Whether mail\n  travels encrypted between other servers and EMX also depends on the other\n  side.\n\n### B.2 Access control\n\n- People sign in through EAuth, with OpenID Connect; a second factor is\n  available. Mail apps use one app password per device, which can be revoked\n  on its own.\n- Rights are set per mailbox (read, write, delete, send as, send on behalf,\n  manage) and checked on every request. A token never has more rights than the\n  person it belongs to. EMX has no function by which an administrator reads or\n  exports the mailbox of an active person. Where the organisation holds\n  suspected spam in a quarantine, its administrators see the sender, the\n  recipients and the subject of each held message, and why it was held, but\n  not its content.\n- A removed person's mail reaches a colleague only when an administrator turns\n  the mailbox into a shared mailbox or hands it on (Section 8.3); both are\n  recorded in the audit log.\n- Failed sign-ins are counted per IP address and per account; too many lock\n  further attempts for a period.\n- Access to the servers, the database and the master key is limited to the\n  people who operate EMX and the platform it runs on. With that access, mail\n  that is not sealed could technically be read; it is used only as Annex A,\n  A.6, allows.\n\n### B.3 Separation\n\nEvery record belongs to one organisation, and each request is checked\nagainst the rights of the person making it. Organisations share servers and\nthe database; the separation is logical.\n\n### B.4 Integrity\n\n- Incoming mail is checked with SPF, DKIM and DMARC; outgoing mail is signed\n  with DKIM.\n- Administrative actions are recorded in the organisation's audit log, with\n  the person, the action and the time.\n- A message is stored in the object storage before the database refers to\n  it, so an interruption cannot leave a reference to half a message.\n\n### B.5 Availability and resilience\n\n- Two application servers, at two providers in two countries, each accept\n  mail and serve the web client and the API.\n- Every database write is confirmed on three servers at three providers in\n  two countries. The database is backed up weekly in full, daily by\n  difference and continuously by its write-ahead log, which allows a restore\n  to a point in time; an encrypted copy of the backups is kept at a second\n  provider.\n- The message bodies are copied every night to a second provider, from which\n  they are read if the first fails.\n- Connections and sign-ins to the mail ports are limited per address and in\n  total, and sending is limited as Section 6.3 states.\n\n### B.6 Filtering\n\n- Incoming and outgoing mail is checked for spam before it is filed or sent,\n  using the checks in B.4, the sending server's name and address, the content,\n  block lists, and a classifier per organisation that learns from what its\n  people file as junk.\n- The block lists of Spamhaus, through its Data Query Service, are asked about\n  the IP address of the sending server and about the domains a message links\n  to. They receive no content of mail.\n- Attachments that are programs are refused, also when they are inside an\n  archive.\n- A scan for known viruses runs only while a virus scanner is connected to\n  EMX. At the time of this version none is, because the platform EMX runs on\n  does not offer one yet; until then mail is not scanned for known viruses.\n- Mail filed as junk, or held in quarantine where the organisation chose that,\n  is deleted after the organisation's retention period, 30 days unless it set\n  another.\n\n### B.7 Logs\n\n- The security and access logs record sign-ins, administrative actions and the\n  IP address they came from. After 90 days, IP addresses in these logs are\n  shortened to their network: an IPv4 address to its first 24 bits, an IPv6\n  address to its first 48.\n- The operating logs of the servers record connections to the mail ports with\n  their IP address, and the sender of each message sent; they are used only\n  to run the service and to handle abuse.\n- The delivery record of each outgoing message (sender, recipient, time and\n  outcome) is kept for a week after delivery, so that a person can see where\n  their mail went.\n- Counters of failed sign-ins are kept in memory for the length of their\n  window only.\n\n### B.8 Organisational measures\n\n- Secrets are given to the service through the platform's environment and are\n  never committed to source control.\n- Every release is built from a reviewed commit and passes the automated\n  tests first.\n- No independent security audit of EMX has been performed. When one is, we\n  will publish the result regardless of its outcome.\n\n---\n\n## Annex C: Version history\n\n| Version | In effect from | Change |\n|---|---|---|\n| 1.1 | 9 October 2026 | Section 4.7 says what happens to an organisation when a person has their EAuth account deleted. Section 1.5 names the general terms and conditions of Elchi Studios by their name, without \"agency\". Every version is published at legal.elchi.dev. In effect without the notice in Section 13.1, since on that day no organisation outside Elchi Studios was affected. |\n| 1.0 | 6 October 2026 | First published version. |\n","body_html":"\u003ch1 id=\"emx-terms-of-service\"\u003eEMX Terms of Service\u003c/h1\u003e\n\u003cp\u003e\u003cstrong\u003eVersion:\u003c/strong\u003e 1.1\u003cbr /\u003e\n\u003cstrong\u003eIn effect from:\u003c/strong\u003e 9 October 2026\u003cbr /\u003e\n\u003cstrong\u003eProvider:\u003c/strong\u003e Krauss Software, sole proprietorship of Samuel Krauss, Im Ländli 18, 6315 Oberägeri ZG, Switzerland, trading as Elchi Studios (\u0026quot;EMX by Elchi Studios\u0026quot;)\u003cbr /\u003e\n\u003cstrong\u003eContact:\u003c/strong\u003e \u003ca href=\"mailto:legal@elchi.dev\"\u003elegal@elchi.dev\u003c/a\u003e; support at \u003ca href=\"mailto:contact@elchi.dev\"\u003econtact@elchi.dev\u003c/a\u003e; reports of abuse to \u003ca href=\"mailto:abuse@emxmail.ch\"\u003eabuse@emxmail.ch\u003c/a\u003e\u003cbr /\u003e\n\u003cstrong\u003eApplies to:\u003c/strong\u003e EMX, the hosted business mail service: the web client and the\u003cbr /\u003e\nAPI at mail.emxmail.app, the mail server mx.emxmail.ch, and the use of the\u003cbr /\u003e\nservice through mail apps and the programs published for EMX\u003c/p\u003e\n\u003cp\u003eThe version in effect and every earlier one are published at legal.elchi.dev/en/emx-terms.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"1-who-these-terms-are-between\"\u003e1. Who these terms are between\u003c/h2\u003e\n\u003cp\u003e1.1 These terms govern the use of EMX, a hosted mail service operated by\u003cbr /\u003e\n\u003cstrong\u003eKrauss Software\u003c/strong\u003e (\u0026quot;we\u0026quot;, \u0026quot;us\u0026quot;), the sole proprietorship of Samuel Krauss,\u003cbr /\u003e\nseated in Oberägeri, Canton of Zug, Switzerland. Krauss Software is not\u003cbr /\u003e\nentered in the commercial register. Samuel Krauss, as its owner, is\u003cbr /\u003e\npersonally liable for its obligations. Elchi Studios is the name under which\u003cbr /\u003e\nthe service is presented.\u003c/p\u003e\n\u003cp\u003e1.2 The \u0026quot;customer\u0026quot; is the business that creates an organisation in EMX: a\u003cbr /\u003e\nlegal entity, or a natural person acting in their trade or profession. EMX is\u003cbr /\u003e\noffered only to businesses and only for their business purposes, on every\u003cbr /\u003e\nplan including the free one. It is not offered to consumers.\u003c/p\u003e\n\u003cp\u003e1.3 The person who creates the organisation and accepts these terms confirms\u003cbr /\u003e\nthat they are authorised to bind the customer. If that authority is missing,\u003cbr /\u003e\nthey are liable to us as the law provides for a person acting without\u003cbr /\u003e\nauthority.\u003c/p\u003e\n\u003cp\u003e1.4 \u0026quot;People\u0026quot; are the natural persons to whom the customer gives a mailbox or\u003cbr /\u003e\naccess to EMX. They use EMX on the customer's behalf, and the customer is\u003cbr /\u003e\nresponsible for their use of it as for its own. People sign in through EAuth,\u003cbr /\u003e\nour sign-in service; what that involves is described in Annex A.\u003c/p\u003e\n\u003cp\u003e1.5 These terms alone govern EMX. The general terms and conditions of Elchi\u003cbr /\u003e\nStudios for software, websites and hosting and the EAuth Terms of Service do\u003cbr /\u003e\nnot apply to EMX, and\u003cbr /\u003e\nneither do terms of the customer. Where we and the customer sign a separate\u003cbr /\u003e\nwritten contract for EMX, such as for the Enterprise plan, that contract\u003cbr /\u003e\nprevails over these terms where it differs.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"2-the-service\"\u003e2. The service\u003c/h2\u003e\n\u003cp\u003e2.1 EMX is mail on the customer's own domains: mailboxes for its people,\u003cbr /\u003e\nshared mailboxes, groups and aliases; a web client; IMAP and SMTP submission\u003cbr /\u003e\nfor mail apps such as Outlook, Apple Mail and Thunderbird, including the\u003cbr /\u003e\nshared mailboxes a person is a member of; automatic replies, forwarding and\u003cbr /\u003e\nrules that file mail on the server; a filter for spam on incoming and outgoing\u003cbr /\u003e\nmail, which refuses attachments that are programs, also inside archives; an\u003cbr /\u003e\nAPI and webhooks; and an export of the mail. A scan for known viruses runs\u003cbr /\u003e\nonly while a virus scanner is connected to EMX. At the time of this version\u003cbr /\u003e\nnone is, because the platform EMX runs on does not offer one yet (Annex B,\u003cbr /\u003e\nB.6). An automatic reply goes only to a sender whose domain passes SPF or\u003cbr /\u003e\nDMARC, with the subject the person set or a fixed one, and counts against the\u003cbr /\u003e\nsending limits in 6.3. The documentation at docs.elchi.dev/emx describes the\u003cbr /\u003e\nservice as it is.\u003c/p\u003e\n\u003cp\u003e2.2 EMX does not include, at the time of this version: calendar and contacts\u003cbr /\u003e\n(CalDAV and CardDAV), Exchange ActiveSync, a mobile app of its own, signed\u003cbr /\u003e\ninstallers for the desktop app, or an archive that meets the requirements of\u003cbr /\u003e\nthe Swiss ordinance on the keeping of business records (GeBüV). We make no\u003cbr /\u003e\npromise as to whether or when any of these will be offered.\u003c/p\u003e\n\u003cp\u003e2.3 We develop EMX further and may change it. We give at least 30 days'\u003cbr /\u003e\nnotice by email before we remove a feature the customer uses to a material\u003cbr /\u003e\nextent, and the customer may then end the contract with effect from the day\u003cbr /\u003e\nof the change. Changes to the API follow the versioning rule in the API\u003cbr /\u003e\nreference.\u003c/p\u003e\n\u003cp\u003e2.4 \u003cstrong\u003eSealed mailboxes.\u003c/strong\u003e Where the organisation allows it, a person can seal\u003cbr /\u003e\ntheir own mailbox. By default only an organisation of one person allows it;\u003cbr /\u003e\nits owners can change that (Section 9.3). From then on, each message,\u003cbr /\u003e\nincluding its subject, its sender and its recipients, is stored encrypted to a\u003cbr /\u003e\nkey of the person's. We keep that key only encrypted to the person's recovery\u003cbr /\u003e\ncode and to a passkey or a passphrase of theirs, none of which we ever see.\u003cbr /\u003e\nMail that was in the mailbox before it was sealed is not sealed and stays\u003cbr /\u003e\nreadable as before. Neither the customer nor we can open a sealed message. Our\u003cbr /\u003e\nservers handle a message in clear only while it is being received or sent. A\u003cbr /\u003e\nsealed mailbox cannot be read in a mail app, its mail cannot be searched on\u003cbr /\u003e\nthe server, it sends no automatic replies and forwards nothing, and of its\u003cbr /\u003e\nrules only those on the size of a message apply. If the person loses their\u003cbr /\u003e\nrecovery code and every passkey and passphrase, the sealed mail cannot be\u003cbr /\u003e\nrecovered by anyone. Annex B, B.1, says exactly what is encrypted and what is\u003cbr /\u003e\nnot.\u003c/p\u003e\n\u003cp\u003e2.5 \u003cstrong\u003eThe customer's own Resend account.\u003c/strong\u003e For a domain, the customer may\u003cbr /\u003e\nchoose to send its outgoing mail through its own account at Resend, Inc.\u003cbr /\u003e\ninstead of through EMX's own mail servers. EMX then hands that domain's\u003cbr /\u003e\noutgoing mail to Resend with the customer's key. Resend acts under the\u003cbr /\u003e\ncustomer's own contract with Resend, as the customer's provider and not as\u003cbr /\u003e\nours. Otherwise EMX sends all mail through its own mail servers and uses no\u003cbr /\u003e\nthird party to send it.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"3-sign-up-plans-and-payment\"\u003e3. Sign-up, plans and payment\u003c/h2\u003e\n\u003cp\u003e3.1 The contract is concluded when the person signing up creates the\u003cbr /\u003e\norganisation in EMX and accepts these terms. We record the version accepted\u003cbr /\u003e\nand the time. Where we create the organisation for the customer, the contract\u003cbr /\u003e\nis concluded instead by a written contract signed by both parties.\u003c/p\u003e\n\u003cp\u003e3.2 The plans are Private (free of charge, for one mailbox on one domain),\u003cbr /\u003e\nTeam (charged per mailbox and month) and Enterprise (on request, under a\u003cbr /\u003e\nseparate written contract). Their scope and limits are those in Section 6\u003cbr /\u003e\nand in the documentation. There is no trial period.\u003c/p\u003e\n\u003cp\u003e3.3 The Team plan is a subscription taken out through Stripe Checkout. The\u003cbr /\u003e\nprice per mailbox and month, and any value added tax, are those shown at\u003cbr /\u003e\ncheckout before the customer pays and on the invoice. Prices are stated in\u003cbr /\u003e\nSwiss francs.\u003c/p\u003e\n\u003cp\u003e3.4 The subscription is charged monthly in advance, to the payment method the\u003cbr /\u003e\ncustomer gives Stripe. The number of mailboxes charged follows the personal\u003cbr /\u003e\nmailboxes in the organisation; when it changes, Stripe charges or credits the\u003cbr /\u003e\ndifference pro rata. Invoices are available in the billing portal, which\u003cbr /\u003e\nadministrators open from the administration of the organisation in EMX.\u003c/p\u003e\n\u003cp\u003e3.5 If a payment fails, Stripe tries again. If the Team subscription ends,\u003cbr /\u003e\nbecause it was cancelled in the billing portal or because payment remains\u003cbr /\u003e\noutstanding, and the organisation has not been cancelled, EMX suspends the\u003cbr /\u003e\norganisation at the end of the billing period already paid: it can no longer\u003cbr /\u003e\nsend mail, but it still receives mail, and its people can still read and\u003cbr /\u003e\nexport their mail. EMX tells the organisation's owners. If within 30 days the\u003cbr /\u003e\nsubscription is neither taken out again nor the organisation cancelled, EMX\u003cbr /\u003e\ncancels the organisation, and Sections 4.2 and 8.5 apply from then on.\u003c/p\u003e\n\u003cp\u003e3.6 We may change prices with 30 days' notice by email. A change applies from\u003cbr /\u003e\nthe first billing period that starts after the notice period. The customer\u003cbr /\u003e\nmay cancel before then under Section 4.2.\u003c/p\u003e\n\u003cp\u003e3.7 Stripe (Stripe Payments Europe, Limited, Ireland) processes the payment\u003cbr /\u003e\ndata under its own terms, as an independent party. We do not receive or store\u003cbr /\u003e\nfull card details.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"4-term-and-ending-the-contract\"\u003e4. Term and ending the contract\u003c/h2\u003e\n\u003cp\u003e4.1 The contract runs for an indefinite period. A Team subscription renews\u003cbr /\u003e\neach month.\u003c/p\u003e\n\u003cp\u003e4.2 The customer may end the contract at any time by cancelling the\u003cbr /\u003e\norganisation in EMX, which only an owner of the organisation can do. The\u003cbr /\u003e\ncontract ends at that moment: from then on the organisation sends and receives\u003cbr /\u003e\nno mail, and Section 8.5 applies. During the 30 days in Section 8.5 an owner\u003cbr /\u003e\ncan undo the cancellation, and the contract then continues.\u003c/p\u003e\n\u003cp\u003e4.3 Cancelling the organisation also ends a Team subscription, at the end of\u003cbr /\u003e\nthe monthly billing period already paid. Fees for a billing period that has\u003cbr /\u003e\nstarted are not refunded. Ending only the Team subscription, in the billing\u003cbr /\u003e\nportal, does not end the contract; Section 3.5 then applies.\u003c/p\u003e\n\u003cp\u003e4.4 We may end the contract with three months' notice to the end of a\u003cbr /\u003e\ncalendar month. If we discontinue EMX as a whole, we give every customer at\u003cbr /\u003e\nleast twelve months' notice.\u003c/p\u003e\n\u003cp\u003e4.5 Either party may end the contract with immediate effect for good cause,\u003cbr /\u003e\nin particular if the other party seriously or repeatedly breaches these terms\u003cbr /\u003e\nand does not remedy the breach within a reasonable period after a written\u003cbr /\u003e\nwarning, unless a warning would be pointless.\u003c/p\u003e\n\u003cp\u003e4.6 Section 8.5 governs what happens to the data when the contract ends.\u003c/p\u003e\n\u003cp\u003e4.7 If the only person of an organisation asks for their EAuth account to be\u003cbr /\u003e\ndeleted, we cancel the organisation for them that day; it is deleted when the\u003cbr /\u003e\naccount is, 30 days after the request. Until then Section 8.5 applies, and if\u003cbr /\u003e\nthe person keeps the account, we undo the cancellation. Where other people\u003cbr /\u003e\nwork in an organisation, deleting the account ends only that person's access;\u003cbr /\u003e\nthe customer decides about their mailbox under Section 9.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"5-availability-and-support\"\u003e5. Availability and support\u003c/h2\u003e\n\u003cp\u003e5.1 \u003cstrong\u003eWe give no availability commitment.\u003c/strong\u003e There is no service level\u003cbr /\u003e\nagreement, no availability figure we promise, and no credit for downtime. We\u003cbr /\u003e\nwould rather say so than publish a figure we cannot yet stand behind.\u003c/p\u003e\n\u003cp\u003e5.2 What we do instead is described in Annex B, B.5: EMX runs on two\u003cbr /\u003e\napplication servers at two providers in two countries, every database write\u003cbr /\u003e\nis confirmed on three servers, and the stored messages are copied every night\u003cbr /\u003e\nto a second provider.\u003c/p\u003e\n\u003cp\u003e5.3 While EMX cannot be reached, servers sending mail to the customer\u003cbr /\u003e\nnormally keep it and try again, usually for several days; how long is decided\u003cbr /\u003e\nby the sending server and not by us. EMX tries to deliver outgoing mail for\u003cbr /\u003e\nfive days and then returns it to the sender as undeliverable.\u003c/p\u003e\n\u003cp\u003e5.4 We carry out maintenance so that it interrupts the service as little as\u003cbr /\u003e\npossible.\u003c/p\u003e\n\u003cp\u003e5.5 Support is given in German and English through the console at\u003cbr /\u003e\npanel.elchi.dev or at \u003ca href=\"mailto:contact@elchi.dev\"\u003econtact@elchi.dev\u003c/a\u003e. We aim to answer within one working\u003cbr /\u003e\nday (Monday to Friday, except public holidays in the Canton of Zug). This is\u003cbr /\u003e\nan aim, not a commitment.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"6-acceptable-use-and-limits\"\u003e6. Acceptable use and limits\u003c/h2\u003e\n\u003cp\u003e6.1 The customer and its people must not use EMX to:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003esend unsolicited mass advertising, or mail to addresses that were bought,\u003cbr /\u003e\nharvested or otherwise obtained without the recipients' consent;\u003c/li\u003e\n\u003cli\u003esend malware, or links to it;\u003c/li\u003e\n\u003cli\u003esend phishing, or otherwise deceive recipients about who is writing, such\u003cbr /\u003e\nas by forging senders or imitating another organisation;\u003c/li\u003e\n\u003cli\u003esend, store or make available content whose sending or possession is\u003cbr /\u003e\nunlawful, in particular depictions of sexual abuse of children, content\u003cbr /\u003e\nthat incites violence or hatred, and content that infringes the rights of\u003cbr /\u003e\nothers;\u003c/li\u003e\n\u003cli\u003eharass or threaten people;\u003c/li\u003e\n\u003cli\u003erelay mail for third parties, or resell EMX without a separate written\u003cbr /\u003e\nagreement;\u003c/li\u003e\n\u003cli\u003ecircumvent the limits in 6.3, probe or test the security of EMX without\u003cbr /\u003e\nour written permission, or impair the service for others.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e6.2 Newsletters and other mail to many recipients are permitted only to\u003cbr /\u003e\nrecipients who have consented, with a working way to unsubscribe, and within\u003cbr /\u003e\nthe limits in 6.3. EMX is not a mass mailing service.\u003c/p\u003e\n\u003cp\u003e6.3 These limits apply:\u003c/p\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eLimit\u003c/th\u003e\n\u003cth\u003ePrivate\u003c/th\u003e\n\u003cth\u003eTeam\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eRecipients outside EMX per person and hour\u003c/td\u003e\n\u003ctd\u003e300\u003c/td\u003e\n\u003ctd\u003e300\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eRecipients per person and calendar day (counted from midnight Swiss time)\u003c/td\u003e\n\u003ctd\u003e200\u003c/td\u003e\n\u003ctd\u003e1,000\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eRecipients per organisation and calendar month\u003c/td\u003e\n\u003ctd\u003e1,000\u003c/td\u003e\n\u003ctd\u003e30,000\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eStorage per mailbox\u003c/td\u003e\n\u003ctd\u003e10 GB\u003c/td\u003e\n\u003ctd\u003e50 GB\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSize of one message, attachments included\u003c/td\u003e\n\u003ctd\u003e50 MB\u003c/td\u003e\n\u003ctd\u003e50 MB\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eRecipients of one message\u003c/td\u003e\n\u003ctd\u003e100\u003c/td\u003e\n\u003ctd\u003e100\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eMailboxes and domains\u003c/td\u003e\n\u003ctd\u003eone each\u003c/td\u003e\n\u003ctd\u003eno limit\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eRequests to the API\u003c/td\u003e\n\u003ctd\u003e600 per minute and token\u003c/td\u003e\n\u003ctd\u003e600 per minute and token\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eA message that would go over a sending limit is refused. Going over a limit\u003cbr /\u003e\nonly refuses that message; it does not stop the person's sending. Outgoing\u003cbr /\u003e\nmail is checked by the filter in Annex B, B.6, as incoming mail is (Section\u003cbr /\u003e\n7.5). Receiving mail is limited only by the size of a message and the storage\u003cbr /\u003e\nof the mailbox; while a mailbox is full, EMX asks the sending servers to try\u003cbr /\u003e\nagain later. On the Enterprise plan the limits are those of the contract.\u003c/p\u003e\n\u003cp\u003e6.4 We may lower a limit with 30 days' notice. To stop abuse we may, at once\u003cbr /\u003e\nand for as long as needed, lower the daily limit of one person or stop their\u003cbr /\u003e\nsending (Section 7).\u003c/p\u003e\n\u003cp\u003e6.5 Abuse is reported to \u003ca href=\"mailto:abuse@emxmail.ch\"\u003eabuse@emxmail.ch\u003c/a\u003e. How we handle reports is described\u003cbr /\u003e\nat docs.elchi.dev/emx-abuse.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"7-suspension\"\u003e7. Suspension\u003c/h2\u003e\n\u003cp\u003e7.1 We may suspend the sending of mail, or access to EMX, for a person, a\u003cbr /\u003e\nmailbox or the whole organisation, if:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ethere are concrete indications of use contrary to 6.1;\u003c/li\u003e\n\u003cli\u003ean account appears to be compromised;\u003c/li\u003e\n\u003cli\u003email sent from the organisation endangers the delivery of other customers'\u003cbr /\u003e\nmail, for instance by putting our servers on block lists;\u003c/li\u003e\n\u003cli\u003ean authority or a court orders it; or\u003c/li\u003e\n\u003cli\u003ethe Team subscription has ended while the organisation has not been\u003cbr /\u003e\ncancelled (Section 3.5).\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e7.2 Where the situation permits, we warn the customer first and give it\u003cbr /\u003e\nreasonable time to remedy the problem. Where it does not, we suspend first\u003cbr /\u003e\nand inform the customer's administrators within one working day, with the\u003cbr /\u003e\nreason, unless the law or an order forbids it.\u003c/p\u003e\n\u003cp\u003e7.3 We choose the least restrictive measure that is effective, such as\u003cbr /\u003e\nstopping the sending of one person, or lowering their daily limit, rather than\u003cbr /\u003e\nsuspending the whole organisation, and lift it as soon as its cause has been\u003cbr /\u003e\nremoved. Suspension never deletes data.\u003c/p\u003e\n\u003cp\u003e7.4 A justified suspension gives no claim to damages or to a reduction of\u003cbr /\u003e\nfees.\u003c/p\u003e\n\u003cp\u003e7.5 \u003cstrong\u003eAutomatic stop.\u003c/strong\u003e If a person's outgoing messages are refused repeatedly\u003cbr /\u003e\nas spam or because they carry malware, EMX stops that person's sending on its\u003cbr /\u003e\nown. Only such refusals stop a person; a message refused for going over a\u003cbr /\u003e\nlimit in 6.3 does not. A stopped person's mail is refused until an\u003cbr /\u003e\nadministrator of the organisation, or we, lift the stop. The administrators\u003cbr /\u003e\nsee the stop and its reason in the administration of the organisation, and it\u003cbr /\u003e\nis recorded in the organisation's audit log.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"8-data-export-and-deletion\"\u003e8. Data, export and deletion\u003c/h2\u003e\n\u003cp\u003e8.1 The customer's mail and data belong to the customer. We claim no rights\u003cbr /\u003e\nto them and process them only to provide EMX, as Annex A describes.\u003c/p\u003e\n\u003cp\u003e8.2 The customer can take its mail out at any time without asking us: each\u003cbr /\u003e\nperson can export their mailbox, and the shared mailboxes they may read, as\u003cbr /\u003e\na file in the web client; mail apps read all of it over IMAP; and the API\u003cbr /\u003e\ngives access to every message.\u003c/p\u003e\n\u003cp\u003e8.3 When the customer removes a person, that person's access ends at once.\u003cbr /\u003e\nWhen removing them, or during the following 30 days, an administrator can turn\u003cbr /\u003e\nthe person's mailbox into a shared mailbox, or hand its mail to a colleague,\u003cbr /\u003e\nwho can then read and export it. Sealed messages stay unreadable to everyone\u003cbr /\u003e\n(Section 9.3). A mailbox that is not handed on in one of these ways is deleted\u003cbr /\u003e\nafter 30 days. Administrators cannot export another person's mailbox directly.\u003c/p\u003e\n\u003cp\u003e8.4 When the customer removes a domain, EMX stops accepting and delivering\u003cbr /\u003e\nmail for it at once and stops signing mail with its keys. Mail already\u003cbr /\u003e\nreceived stays in the mailboxes.\u003c/p\u003e\n\u003cp\u003e8.5 \u003cstrong\u003eWhen the contract ends\u003c/strong\u003e (Section 4.2), the organisation sends and\u003cbr /\u003e\nreceives no mail any more, and EMX keeps its data for 30 days. During that\u003cbr /\u003e\ntime its people can still sign in, read their own mail and export it, and its\u003cbr /\u003e\nowners can export all mailboxes of the organisation. The billing portal is\u003cbr /\u003e\nclosed while the organisation is cancelled. An owner can undo the cancellation\u003cbr /\u003e\nduring the 30 days. If the Team subscription had ended by then, the undo\u003cbr /\u003e\nleaves at least 7 days to take it out again before the cancellation under\u003cbr /\u003e\nSection 3.5 starts again. After 30 days we delete the mailboxes with their\u003cbr /\u003e\nmessages, the people, the domains and the rest of the organisation's data. On\u003cbr /\u003e\nrequest we confirm the deletion in writing.\u003c/p\u003e\n\u003cp\u003e8.6 Deleted data also disappears from the copies of the message bodies\u003cbr /\u003e\nwithin a few days, and from the database backups when they are replaced in\u003cbr /\u003e\nthe normal backup cycle. We restore from backups only to recover the service\u003cbr /\u003e\nafter a failure, never to bring back a customer's data that was deleted.\u003cbr /\u003e\nRecords we must keep by law, such as invoices (Art. 958f OR), are kept for as\u003cbr /\u003e\nlong as the law requires.\u003c/p\u003e\n\u003cp\u003e8.7 The export of a sealed mailbox contains its messages as they are stored:\u003cbr /\u003e\nencrypted. The person can open them with their key, for instance with their\u003cbr /\u003e\nrecovery code and the age tool.\u003c/p\u003e\n\u003cp\u003e8.8 EMX is not an archive. Where the customer must keep business records,\u003cbr /\u003e\nsuch as under Art. 958f OR and the GeBüV, it is responsible for doing so,\u003cbr /\u003e\nfor example by exporting the mail it must keep.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"9-the-mail-of-people-who-leave-and-access-by-the-organisation\"\u003e9. The mail of people who leave, and access by the organisation\u003c/h2\u003e\n\u003cp\u003e9.1 The customer is the controller of the mail in its organisation. It\u003cbr /\u003e\ndecides, within the law, who may read a person's mailbox when that person\u003cbr /\u003e\nleaves or is absent. It must observe the protection of its employees'\u003cbr /\u003e\npersonal data (Art. 328b OR) and the applicable data protection law, and\u003cbr /\u003e\ninform its people of its rules in advance.\u003c/p\u003e\n\u003cp\u003e9.2 EMX gives administrators no way to read or export the mailbox of a person\u003cbr /\u003e\nwho is active in the organisation. One thing they do see: where the\u003cbr /\u003e\norganisation chooses to hold suspected spam in a quarantine instead of filing\u003cbr /\u003e\nit in the person's junk folder, its administrators see the sender, the\u003cbr /\u003e\nrecipients and the subject of each held message, so that they can release or\u003cbr /\u003e\ndelete it. When the customer removes a person, its administrators can deal\u003cbr /\u003e\nwith that person's mailbox only as Section 8.3 describes. Every such step is\u003cbr /\u003e\nrecorded in the organisation's audit log.\u003c/p\u003e\n\u003cp\u003e9.3 Mail in a sealed mailbox cannot be opened by anyone other than the person\u003cbr /\u003e\nwho sealed it: not by the organisation and not by us. If that person leaves\u003cbr /\u003e\nwithout making their mail available, the organisation cannot read it, and it\u003cbr /\u003e\nis not handed on with the rest of the mailbox. The owners of the organisation\u003cbr /\u003e\ndecide whether its people may seal their mailboxes; by default only an\u003cbr /\u003e\norganisation of one person allows it. Turning sealing off does not unseal a\u003cbr /\u003e\nmailbox that is already sealed. The customer should agree with its people\u003cbr /\u003e\nwhether business mail may be kept in a sealed mailbox.\u003c/p\u003e\n\u003cp\u003e9.4 We do not open a person's mail on behalf of the customer. The functions\u003cbr /\u003e\nof EMX described here are the way to reach it. Section A.11 of Annex A\u003cbr /\u003e\ngoverns requests from authorities.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"10-the-customers-responsibilities\"\u003e10. The customer's responsibilities\u003c/h2\u003e\n\u003cp\u003e10.1 The customer keeps the details of the organisation and its billing\u003cbr /\u003e\ncontact accurate.\u003c/p\u003e\n\u003cp\u003e10.2 The customer ensures that its people keep their sign-in details and app\u003cbr /\u003e\npasswords secret, and that a lost device's app password is revoked. We\u003cbr /\u003e\nrecommend a second factor for every person. A suspected compromise is\u003cbr /\u003e\nreported without undue delay to \u003ca href=\"mailto:security@elchi.dev\"\u003esecurity@elchi.dev\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e10.3 The customer may only add domains it is entitled to use, and is\u003cbr /\u003e\nresponsible for their DNS records. Mail for a domain reaches EMX only once\u003cbr /\u003e\nthe domain's MX record points to it.\u003c/p\u003e\n\u003cp\u003e10.4 The customer ensures that its people comply with Section 6, informs them\u003cbr /\u003e\nabout EMX and the processing of their data, and answers the requests of data\u003cbr /\u003e\nsubjects whose data is in its mail, with the tools of EMX and our help under\u003cbr /\u003e\nAnnex A.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"11-data-protection\"\u003e11. Data protection\u003c/h2\u003e\n\u003cp\u003e11.1 For the personal data in the customer's mail and in the accounts of its\u003cbr /\u003e\npeople, the customer is the controller and we are its processor. Annex A is\u003cbr /\u003e\nthe data processing agreement and forms part of these terms.\u003c/p\u003e\n\u003cp\u003e11.2 For our own purposes, namely concluding and performing the contract,\u003cbr /\u003e\nbilling, contact with the customer, the security of the service and handling\u003cbr /\u003e\nabuse, we are the controller. For these purposes we process the details of\u003cbr /\u003e\nthe organisation and its billing contact, the administrators' contact\u003cbr /\u003e\ndetails and the logs described in Annex B, B.7.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"12-liability\"\u003e12. Liability\u003c/h2\u003e\n\u003cp\u003e12.1 We are liable without limitation for damage caused intentionally or by\u003cbr /\u003e\ngross negligence (Art. 100 para. 1 OR), for personal injury, and wherever\u003cbr /\u003e\nelse the law does not permit liability to be limited in advance. Nothing in\u003cbr /\u003e\nthese terms limits that liability.\u003c/p\u003e\n\u003cp\u003e12.2 For slight negligence, our liability is limited to direct damage and, in\u003cbr /\u003e\ntotal for all claims arising in a calendar year, to the greater of the fees\u003cbr /\u003e\nthe customer paid for EMX in the twelve months before the event causing the\u003cbr /\u003e\ndamage and CHF 500. Liability for indirect and consequential damage, in\u003cbr /\u003e\nparticular lost profit, is excluded for slight negligence.\u003c/p\u003e\n\u003cp\u003e12.3 If mail or data is lost for a reason for which we are responsible, we\u003cbr /\u003e\nrestore it from the most recent copy available and bear the cost. Further\u003cbr /\u003e\nclaims for the loss exist only under 12.1 and 12.2.\u003c/p\u003e\n\u003cp\u003e12.4 We are not liable for the content of mail sent or received by the\u003cbr /\u003e\ncustomer, for the loss of sealed mail whose keys were lost (Section 2.4), for\u003cbr /\u003e\nthe services of the customer's own Resend account (Section 2.5), for other\u003cbr /\u003e\nservers that refuse or delay mail or file it as spam, or for events beyond our\u003cbr /\u003e\nreasonable control.\u003c/p\u003e\n\u003cp\u003e12.5 We are liable for the people we engage, including our sub-processors,\u003cbr /\u003e\nas for our own conduct.\u003c/p\u003e\n\u003cp\u003e12.6 The customer indemnifies us against claims of third parties arising from\u003cbr /\u003e\nuse of EMX contrary to these terms by the customer or its people, unless we\u003cbr /\u003e\nare responsible for the claim.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"13-changes-to-these-terms\"\u003e13. Changes to these terms\u003c/h2\u003e\n\u003cp\u003e13.1 We give at least 30 days' notice of a change to these terms by email to\u003cbr /\u003e\nthe organisation's administrators and its billing contact.\u003c/p\u003e\n\u003cp\u003e13.2 If the customer does not agree, it may end the contract before the change\u003cbr /\u003e\ntakes effect, under Section 4.2. Otherwise the new version applies from the\u003cbr /\u003e\nday stated. A change required by law, or needed at once to protect the\u003cbr /\u003e\nsecurity of the service, may take effect sooner; we say so in the notice.\u003c/p\u003e\n\u003cp\u003e13.3 Every version of these terms remains published, with its date, so that\u003cbr /\u003e\nit can be seen what applied when.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"14-final-provisions\"\u003e14. Final provisions\u003c/h2\u003e\n\u003cp\u003e14.1 Swiss law applies, excluding its conflict of laws rules and the United\u003cbr /\u003e\nNations Convention on Contracts for the International Sale of Goods.\u003c/p\u003e\n\u003cp\u003e14.2 The exclusive place of jurisdiction is Zug, Switzerland. We may also\u003cbr /\u003e\nbring proceedings at the customer's seat.\u003c/p\u003e\n\u003cp\u003e14.3 If a provision of these terms is invalid, the rest remains in force, and\u003cbr /\u003e\nthe invalid provision is replaced by a valid one that comes as close as\u003cbr /\u003e\npossible to what it intended.\u003c/p\u003e\n\u003cp\u003e14.4 These terms are published in German and in English with the same\u003cbr /\u003e\ncontent. If the two versions differ, the German version prevails.\u003c/p\u003e\n\u003cp\u003e14.5 Notices to the customer go by email to the addresses in the\u003cbr /\u003e\norganisation's administration. Notices to us go to \u003ca href=\"mailto:legal@elchi.dev\"\u003elegal@elchi.dev\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003e14.6 The customer may transfer the contract only with our written consent.\u003cbr /\u003e\nWe may transfer it to a company that continues the business of Krauss\u003cbr /\u003e\nSoftware, with notice by email; the customer may then end the contract with\u003cbr /\u003e\neffect from the transfer.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"annex-a-data-processing-agreement\"\u003eAnnex A: Data Processing Agreement\u003c/h2\u003e\n\u003cp\u003eThis annex is the agreement on the processing of personal data on behalf of\u003cbr /\u003e\nthe customer required by Art. 9 of the Swiss Federal Act on Data Protection\u003cbr /\u003e\n(revDSG) and by Art. 28 of the General Data Protection Regulation (GDPR),\u003cbr /\u003e\nwhere that applies. It forms part of these terms and needs no separate\u003cbr /\u003e\nsignature. Terms not defined here have the meaning given in the revDSG and\u003cbr /\u003e\nthe GDPR.\u003c/p\u003e\n\u003ch3 id=\"a1-subject-matter-and-duration\"\u003eA.1 Subject matter and duration\u003c/h3\u003e\n\u003cp\u003eWe process personal data for the customer in order to provide EMX, for as\u003cbr /\u003e\nlong as the contract runs and until the deletion described in A.15.\u003c/p\u003e\n\u003ch3 id=\"a2-nature-and-purpose\"\u003eA.2 Nature and purpose\u003c/h3\u003e\n\u003cp\u003eReceiving, filtering incoming and outgoing mail for spam and harmful\u003cbr /\u003e\nattachments, storing, indexing for search, displaying, synchronising, sending\u003cbr /\u003e\nand exporting mail; managing the organisation's people, mailboxes, domains and\u003cbr /\u003e\nrights; recording security and access events; and making the backups and\u003cbr /\u003e\ncopies described in Annex B.\u003c/p\u003e\n\u003ch3 id=\"a3-data-subjects\"\u003eA.3 Data subjects\u003c/h3\u003e\n\u003cp\u003eThe customer's people; the people who write to them or receive mail from\u003cbr /\u003e\nthem; and the people named in that mail.\u003c/p\u003e\n\u003ch3 id=\"a4-categories-of-personal-data\"\u003eA.4 Categories of personal data\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eAccount data: names, addresses, roles, the identifier of the person's\u003cbr /\u003e\nsign-in, preferences, signatures, and digests of app passwords and tokens.\u003c/li\u003e\n\u003cli\u003eThe content of messages and attachments, of any kind.\u003c/li\u003e\n\u003cli\u003eMessage data: sender, recipients, subject, times, size, flags and folder.\u003c/li\u003e\n\u003cli\u003eThe full-text search index of mailboxes that are not sealed.\u003c/li\u003e\n\u003cli\u003eThe senders a person has allowed or blocked.\u003c/li\u003e\n\u003cli\u003eLogs: sign-ins, administrative actions and IP addresses, as described in\u003cbr /\u003e\nAnnex B, B.7.\u003c/li\u003e\n\u003cli\u003ePush subscriptions of browsers in which a person has turned on\u003cbr /\u003e\nnotifications.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eMail can contain sensitive personal data in the sense of Art. 5 lit. c\u003cbr /\u003e\nrevDSG and Art. 9 and 10 GDPR, such as health data. EMX processes such data\u003cbr /\u003e\nlike any other mail. Whether the customer may send and keep it by mail is the\u003cbr /\u003e\ncustomer's decision and responsibility.\u003c/p\u003e\n\u003ch3 id=\"a5-instructions\"\u003eA.5 Instructions\u003c/h3\u003e\n\u003cp\u003eWe process the data only on the customer's documented instructions. These\u003cbr /\u003e\nterms and the customer's settings in EMX are those instructions. If we\u003cbr /\u003e\nconsider that an instruction infringes data protection law, we tell the\u003cbr /\u003e\ncustomer and may suspend carrying it out until it is clarified. We process\u003cbr /\u003e\nthe data for other purposes only where the law obliges us to, as described\u003cbr /\u003e\nin A.11.\u003c/p\u003e\n\u003ch3 id=\"a6-confidentiality\"\u003eA.6 Confidentiality\u003c/h3\u003e\n\u003cp\u003eEveryone we authorise to process the data is bound by a written duty of\u003cbr /\u003e\nconfidentiality that continues after their engagement ends. We do not read\u003cbr /\u003e\nthe customer's mail. Where looking at a message is unavoidable, such as for\u003cbr /\u003e\na message a person sends us to resolve a problem, we look at it only as far\u003cbr /\u003e\nas necessary.\u003c/p\u003e\n\u003ch3 id=\"a7-security\"\u003eA.7 Security\u003c/h3\u003e\n\u003cp\u003eWe take the technical and organisational measures in Annex B. We may change\u003cbr /\u003e\na measure, but not in a way that lowers the overall level of protection.\u003c/p\u003e\n\u003ch3 id=\"a8-sub-processors\"\u003eA.8 Sub-processors\u003c/h3\u003e\n\u003cp\u003eThe customer gives general authorisation for the sub-processors listed here:\u003c/p\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCompany\u003c/th\u003e\n\u003cth\u003eWhat it does for EMX\u003c/th\u003e\n\u003cth\u003eWhat it sees\u003c/th\u003e\n\u003cth\u003eWhere\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003eInfomaniak Network SA\u003c/td\u003e\n\u003ctd\u003eRuns an application server (web client, API and mail ports), the object storage for the message bodies, and the server that watches the others\u003c/td\u003e\n\u003ctd\u003eEverything EMX processes; message bodies are stored there only encrypted (Annex B, B.1)\u003c/td\u003e\n\u003ctd\u003eGeneva, Switzerland\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eTavuru\u003c/td\u003e\n\u003ctd\u003eRuns the primary database server; outgoing mail leaves through its address\u003c/td\u003e\n\u003ctd\u003eThe database (Annex B, B.1 says what in it is not encrypted); outgoing mail in transit, encrypted where the receiving server supports TLS\u003c/td\u003e\n\u003ctd\u003eFrankfurt, Germany\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eHetzner Online GmbH\u003c/td\u003e\n\u003ctd\u003eRuns a database replica and one of the two edge proxies, where HTTPS ends\u003c/td\u003e\n\u003ctd\u003eThe database; the requests of the web client and the API in transit\u003c/td\u003e\n\u003ctd\u003eNuremberg and Falkenstein, Germany\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eScaleway SAS\u003c/td\u003e\n\u003ctd\u003eRuns an application server, a database replica, the nightly copy of the message bodies and an encrypted copy of the database backups\u003c/td\u003e\n\u003ctd\u003eEverything EMX processes, as for Infomaniak and Tavuru\u003c/td\u003e\n\u003ctd\u003eAmsterdam, Netherlands, and Paris, France\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eUpCloud Oy\u003c/td\u003e\n\u003ctd\u003eRuns the second edge proxy, where HTTPS ends\u003c/td\u003e\n\u003ctd\u003eThe requests of the web client and the API in transit\u003c/td\u003e\n\u003ctd\u003eAmsterdam, Netherlands\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eClouDNS Ltd.\u003c/td\u003e\n\u003ctd\u003eAnswers the DNS name behind every host with the edge proxies that are healthy\u003c/td\u003e\n\u003ctd\u003eDNS queries only, no message or account content\u003c/td\u003e\n\u003ctd\u003eSofia, Bulgaria\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eSpamhaus Technology Ltd, through its Data Query Service (DQS)\u003c/td\u003e\n\u003ctd\u003eAnswers whether the IP address of a server sending mail to EMX, or a domain a message links to, is on the Spamhaus block lists\u003c/td\u003e\n\u003ctd\u003eThose IP addresses and domains; no message content\u003c/td\u003e\n\u003ctd\u003eUnited Kingdom; its name servers also elsewhere (A.9)\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003eResend, Inc.\u003c/td\u003e\n\u003ctd\u003eSends the mails of the sign-in service EAuth to the customer's people, such as confirmations of their address and password resets\u003c/td\u003e\n\u003ctd\u003eThe recipient's address and the subject and text of those mails\u003c/td\u003e\n\u003ctd\u003eSent from its European Union region, stored in the United States\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eResend does not send the customer's mail. EMX sends it through its own mail\u003cbr /\u003e\nservers, except for a domain for which the customer has chosen its own Resend\u003cbr /\u003e\naccount (Section 2.5).\u003c/p\u003e\n\u003cp\u003eThese are not sub-processors and receive no content of mail: Stripe, which\u003cbr /\u003e\nprocesses payment data as an independent party (Section 3.7); Cloudflare,\u003cbr /\u003e\nwhich holds the DNS zones of our domains; and the push services of browser\u003cbr /\u003e\nmakers, which carry a notification, encrypted end to end to the browser, only\u003cbr /\u003e\nto a browser in which a person has turned notifications on.\u003c/p\u003e\n\u003cp\u003eWe give at least 30 days' notice by email before adding or replacing a\u003cbr /\u003e\nsub-processor. If the customer objects on reasonable data protection grounds\u003cbr /\u003e\nwithin that period and we cannot accommodate the objection, the customer may\u003cbr /\u003e\nend the contract with effect from the change. Every sub-processor is bound\u003cbr /\u003e\nby data protection obligations no weaker than this annex, and we remain\u003cbr /\u003e\nliable to the customer for them.\u003c/p\u003e\n\u003ch3 id=\"a9-transfers-abroad\"\u003eA.9 Transfers abroad\u003c/h3\u003e\n\u003cp\u003eThe data is processed in Switzerland and in Germany, the Netherlands, France\u003cbr /\u003e\nand Bulgaria, and Spamhaus Technology Ltd is in the United Kingdom. These\u003cbr /\u003e\nstates, the United Kingdom included, provide adequate protection under Annex 1\u003cbr /\u003e\nof the Swiss Data Protection Ordinance (DSV), and the European Commission has\u003cbr /\u003e\nfound Switzerland and the United Kingdom adequate (Art. 45 GDPR). The name\u003cbr /\u003e\nservers through which Spamhaus answers the questions in A.8 can also be in\u003cbr /\u003e\nother states; a question carries only the IP address of a sending server or a\u003cbr /\u003e\ndomain a message links to, and no content of mail.\u003c/p\u003e\n\u003cp\u003eOne transfer goes outside both: Resend, Inc. stores the mails of the sign-in\u003cbr /\u003e\nservice in the United States. For data from Switzerland it rests on the\u003cbr /\u003e\nstandard contractual clauses in Resend's data processing agreement, as\u003cbr /\u003e\nadapted for Swiss law (Art. 16 para. 2 lit. d revDSG). For data subject to\u003cbr /\u003e\nthe GDPR it rests on Resend's certification under the EU-U.S. Data Privacy\u003cbr /\u003e\nFramework (Art. 45 GDPR), with those clauses in addition (Art. 46 para. 2\u003cbr /\u003e\nlit. c GDPR).\u003c/p\u003e\n\u003cp\u003eData held by a provider in another state can be reached by that state's\u003cbr /\u003e\nauthorities under its law, through the provider. Message bodies held by our\u003cbr /\u003e\nproviders are encrypted with a key that is not kept with the stored data; the\u003cbr /\u003e\ndatabase is not encrypted in that way (Annex B, B.1).\u003c/p\u003e\n\u003cp\u003eIf the customer sends through its own Resend account (Section 2.5), that\u003cbr /\u003e\ntransfer is the customer's.\u003c/p\u003e\n\u003ch3 id=\"a10-data-subject-rights\"\u003eA.10 Data subject rights\u003c/h3\u003e\n\u003cp\u003eIf a data subject asks us to exercise their rights, we forward the request\u003cbr /\u003e\nto the customer without undue delay and do not answer it ourselves. EMX\u003cbr /\u003e\ngives the customer the tools to answer: export, correction and deletion.\u003cbr /\u003e\nWhere these are not enough, we help the customer at no charge.\u003c/p\u003e\n\u003ch3 id=\"a11-requests-from-authorities\"\u003eA.11 Requests from authorities\u003c/h3\u003e\n\u003cp\u003eWe disclose the customer's data to an authority only where Swiss law\u003cbr /\u003e\nobliges us to, on an order of a competent Swiss authority. Requests from\u003cbr /\u003e\nforeign authorities must go through Swiss mutual legal assistance. We tell\u003cbr /\u003e\nthe customer about a request without delay, unless the law or the order\u003cbr /\u003e\nforbids it. How we handle requests, and what data exists, is described at\u003cbr /\u003e\ndocs.elchi.dev/emx-authorities.\u003c/p\u003e\n\u003ch3 id=\"a12-assistance\"\u003eA.12 Assistance\u003c/h3\u003e\n\u003cp\u003eWe help the customer, taking into account the nature of the processing and\u003cbr /\u003e\nthe information available to us, with the security of the processing, with\u003cbr /\u003e\nnotifying breaches of data security, and with data protection impact\u003cbr /\u003e\nassessments and prior consultations (Art. 22 to 24 revDSG, Art. 32 to 36\u003cbr /\u003e\nGDPR).\u003c/p\u003e\n\u003ch3 id=\"a13-breaches-of-data-security\"\u003eA.13 Breaches of data security\u003c/h3\u003e\n\u003cp\u003eWe notify the customer of a breach of data security that affects its data\u003cbr /\u003e\nwithout undue delay, and in any case within 72 hours of becoming aware of\u003cbr /\u003e\nit. The notice describes the nature of the breach, as far as known the\u003cbr /\u003e\ncategories and approximate number of data subjects and records concerned,\u003cbr /\u003e\nthe likely consequences, and the measures taken or proposed. We notify the\u003cbr /\u003e\ncustomer even where we are not certain that the breach affects it, because\u003cbr /\u003e\nthat judgement is the customer's.\u003c/p\u003e\n\u003ch3 id=\"a14-audits\"\u003eA.14 Audits\u003c/h3\u003e\n\u003cp\u003eThe customer may request the information needed to show that this annex is\u003cbr /\u003e\ncomplied with once per calendar year, and after a breach affecting its data.\u003cbr /\u003e\nNo certification or independent audit of EMX exists; we say so rather than\u003cbr /\u003e\nlet the customer assume otherwise. An audit on site requires 30 days'\u003cbr /\u003e\nnotice, must not disrupt the service or disclose other customers' data, and\u003cbr /\u003e\nis at the customer's cost.\u003c/p\u003e\n\u003ch3 id=\"a15-deletion-and-return\"\u003eA.15 Deletion and return\u003c/h3\u003e\n\u003cp\u003eWhen the contract ends, the customer can make a final export for 30 days, as\u003cbr /\u003e\nSection 8.5 describes. We then delete the data, as Sections 8.5 and 8.6\u003cbr /\u003e\ndescribe, unless the law requires us to keep it. On request we confirm the\u003cbr /\u003e\ndeletion in writing.\u003c/p\u003e\n\u003chr /\u003e\n\u003ch2 id=\"annex-b-technical-and-organisational-measures\"\u003eAnnex B: Technical and organisational measures\u003c/h2\u003e\n\u003cp\u003eThese are the measures in place, not a general list. Where something is not\u003cbr /\u003e\nprotected, this annex says so.\u003c/p\u003e\n\u003ch3 id=\"b1-encryption\"\u003eB.1 Encryption\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eMessage bodies.\u003c/strong\u003e Every message, with its attachments, is compressed and\u003cbr /\u003e\nencrypted with AES-256-GCM under a master key before it is stored in the\u003cbr /\u003e\nobject storage. The object storage and its nightly copy hold only\u003cbr /\u003e\nciphertext.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThe master key\u003c/strong\u003e is held in the platform's secret store and in the\u003cbr /\u003e\noperator's password manager, and is not part of any backup.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWhat is not encrypted in this way:\u003c/strong\u003e the database. It holds, for\u003cbr /\u003e\nmailboxes that are not sealed, the sender, recipients, subject, times,\u003cbr /\u003e\nflags and folder of each message, a short preview, and the full-text index\u003cbr /\u003e\nfor search built from the subject, the people and the text. It also holds\u003cbr /\u003e\nthe account data of Annex A, A.4.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSecrets\u003c/strong\u003e are encrypted with the master key: the private keys for DKIM,\u003cbr /\u003e\nthe stored tokens of the sign-in service, the keys of the customer's own\u003cbr /\u003e\nResend accounts, the secrets of webhooks, the passwords given for importing\u003cbr /\u003e\nmail, and the account and keys for the certificate of the mail server.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eApp passwords, API tokens and session tokens\u003c/strong\u003e are stored only as SHA-256\u003cbr /\u003e\ndigests. An app password is 100 random bits and is shown once.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSealed mailboxes.\u003c/strong\u003e Each message, including its subject, sender and\u003cbr /\u003e\nrecipients, is encrypted with age (X25519) to the mailbox's public key as\u003cbr /\u003e\nsoon as it is received or sent. The private key is kept on the server only\u003cbr /\u003e\nencrypted to the person's recovery code and to a passkey or a passphrase,\u003cbr /\u003e\nnone of which the server sees. Mail that was in the mailbox before it was\u003cbr /\u003e\nsealed is not encrypted in this way. What stays readable to the server is\u003cbr /\u003e\nthe time a message arrived, its size, its folder and its flags, and for mail\u003cbr /\u003e\nsent to other servers the delivery record in B.7. Sealed messages are not\u003cbr /\u003e\nindexed for search on the server, and IMAP is not available for them. While\u003cbr /\u003e\na message is being received or sent, the server handles it in clear.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIn transit.\u003c/strong\u003e The web client and the API are served over HTTPS only.\u003cbr /\u003e\nHTTPS ends at our edge proxies, and from there requests travel over our own\u003cbr /\u003e\nencrypted network between the servers. The mail ports use TLS 1.2 or newer;\u003cbr /\u003e\npasswords are accepted only after TLS has been established. Outgoing mail\u003cbr /\u003e\nis sent with TLS whenever the receiving server offers it, and only with TLS\u003cbr /\u003e\nwhere the receiving domain requires it through MTA-STS. Whether mail\u003cbr /\u003e\ntravels encrypted between other servers and EMX also depends on the other\u003cbr /\u003e\nside.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"b2-access-control\"\u003eB.2 Access control\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003ePeople sign in through EAuth, with OpenID Connect; a second factor is\u003cbr /\u003e\navailable. Mail apps use one app password per device, which can be revoked\u003cbr /\u003e\non its own.\u003c/li\u003e\n\u003cli\u003eRights are set per mailbox (read, write, delete, send as, send on behalf,\u003cbr /\u003e\nmanage) and checked on every request. A token never has more rights than the\u003cbr /\u003e\nperson it belongs to. EMX has no function by which an administrator reads or\u003cbr /\u003e\nexports the mailbox of an active person. Where the organisation holds\u003cbr /\u003e\nsuspected spam in a quarantine, its administrators see the sender, the\u003cbr /\u003e\nrecipients and the subject of each held message, and why it was held, but\u003cbr /\u003e\nnot its content.\u003c/li\u003e\n\u003cli\u003eA removed person's mail reaches a colleague only when an administrator turns\u003cbr /\u003e\nthe mailbox into a shared mailbox or hands it on (Section 8.3); both are\u003cbr /\u003e\nrecorded in the audit log.\u003c/li\u003e\n\u003cli\u003eFailed sign-ins are counted per IP address and per account; too many lock\u003cbr /\u003e\nfurther attempts for a period.\u003c/li\u003e\n\u003cli\u003eAccess to the servers, the database and the master key is limited to the\u003cbr /\u003e\npeople who operate EMX and the platform it runs on. With that access, mail\u003cbr /\u003e\nthat is not sealed could technically be read; it is used only as Annex A,\u003cbr /\u003e\nA.6, allows.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"b3-separation\"\u003eB.3 Separation\u003c/h3\u003e\n\u003cp\u003eEvery record belongs to one organisation, and each request is checked\u003cbr /\u003e\nagainst the rights of the person making it. Organisations share servers and\u003cbr /\u003e\nthe database; the separation is logical.\u003c/p\u003e\n\u003ch3 id=\"b4-integrity\"\u003eB.4 Integrity\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eIncoming mail is checked with SPF, DKIM and DMARC; outgoing mail is signed\u003cbr /\u003e\nwith DKIM.\u003c/li\u003e\n\u003cli\u003eAdministrative actions are recorded in the organisation's audit log, with\u003cbr /\u003e\nthe person, the action and the time.\u003c/li\u003e\n\u003cli\u003eA message is stored in the object storage before the database refers to\u003cbr /\u003e\nit, so an interruption cannot leave a reference to half a message.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"b5-availability-and-resilience\"\u003eB.5 Availability and resilience\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eTwo application servers, at two providers in two countries, each accept\u003cbr /\u003e\nmail and serve the web client and the API.\u003c/li\u003e\n\u003cli\u003eEvery database write is confirmed on three servers at three providers in\u003cbr /\u003e\ntwo countries. The database is backed up weekly in full, daily by\u003cbr /\u003e\ndifference and continuously by its write-ahead log, which allows a restore\u003cbr /\u003e\nto a point in time; an encrypted copy of the backups is kept at a second\u003cbr /\u003e\nprovider.\u003c/li\u003e\n\u003cli\u003eThe message bodies are copied every night to a second provider, from which\u003cbr /\u003e\nthey are read if the first fails.\u003c/li\u003e\n\u003cli\u003eConnections and sign-ins to the mail ports are limited per address and in\u003cbr /\u003e\ntotal, and sending is limited as Section 6.3 states.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"b6-filtering\"\u003eB.6 Filtering\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eIncoming and outgoing mail is checked for spam before it is filed or sent,\u003cbr /\u003e\nusing the checks in B.4, the sending server's name and address, the content,\u003cbr /\u003e\nblock lists, and a classifier per organisation that learns from what its\u003cbr /\u003e\npeople file as junk.\u003c/li\u003e\n\u003cli\u003eThe block lists of Spamhaus, through its Data Query Service, are asked about\u003cbr /\u003e\nthe IP address of the sending server and about the domains a message links\u003cbr /\u003e\nto. They receive no content of mail.\u003c/li\u003e\n\u003cli\u003eAttachments that are programs are refused, also when they are inside an\u003cbr /\u003e\narchive.\u003c/li\u003e\n\u003cli\u003eA scan for known viruses runs only while a virus scanner is connected to\u003cbr /\u003e\nEMX. At the time of this version none is, because the platform EMX runs on\u003cbr /\u003e\ndoes not offer one yet; until then mail is not scanned for known viruses.\u003c/li\u003e\n\u003cli\u003eMail filed as junk, or held in quarantine where the organisation chose that,\u003cbr /\u003e\nis deleted after the organisation's retention period, 30 days unless it set\u003cbr /\u003e\nanother.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"b7-logs\"\u003eB.7 Logs\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eThe security and access logs record sign-ins, administrative actions and the\u003cbr /\u003e\nIP address they came from. After 90 days, IP addresses in these logs are\u003cbr /\u003e\nshortened to their network: an IPv4 address to its first 24 bits, an IPv6\u003cbr /\u003e\naddress to its first 48.\u003c/li\u003e\n\u003cli\u003eThe operating logs of the servers record connections to the mail ports with\u003cbr /\u003e\ntheir IP address, and the sender of each message sent; they are used only\u003cbr /\u003e\nto run the service and to handle abuse.\u003c/li\u003e\n\u003cli\u003eThe delivery record of each outgoing message (sender, recipient, time and\u003cbr /\u003e\noutcome) is kept for a week after delivery, so that a person can see where\u003cbr /\u003e\ntheir mail went.\u003c/li\u003e\n\u003cli\u003eCounters of failed sign-ins are kept in memory for the length of their\u003cbr /\u003e\nwindow only.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"b8-organisational-measures\"\u003eB.8 Organisational measures\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eSecrets are given to the service through the platform's environment and are\u003cbr /\u003e\nnever committed to source control.\u003c/li\u003e\n\u003cli\u003eEvery release is built from a reviewed commit and passes the automated\u003cbr /\u003e\ntests first.\u003c/li\u003e\n\u003cli\u003eNo independent security audit of EMX has been performed. When one is, we\u003cbr /\u003e\nwill publish the result regardless of its outcome.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr /\u003e\n\u003ch2 id=\"annex-c-version-history\"\u003eAnnex C: Version history\u003c/h2\u003e\n\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eVersion\u003c/th\u003e\n\u003cth\u003eIn effect from\u003c/th\u003e\n\u003cth\u003eChange\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.1\u003c/td\u003e\n\u003ctd\u003e9 October 2026\u003c/td\u003e\n\u003ctd\u003eSection 4.7 says what happens to an organisation when a person has their EAuth account deleted. Section 1.5 names the general terms and conditions of Elchi Studios by their name, without \u0026quot;agency\u0026quot;. Every version is published at legal.elchi.dev. In effect without the notice in Section 13.1, since on that day no organisation outside Elchi Studios was affected.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd\u003e1.0\u003c/td\u003e\n\u003ctd\u003e6 October 2026\u003c/td\u003e\n\u003ctd\u003eFirst published version.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\n","body_json":{"meta":{"scope":"EMX, hosted business mail, on every plan. Business customers only.","venue":"Zug, Switzerland","contact":"legal@elchi.dev","version":"1.1","document":"EMX Terms of Service","language":"en","provider":"Krauss Software, sole proprietorship of Samuel Krauss (trading as Elchi Studios, \"EMX by Elchi Studios\")","applies_to":["mail.emxmail.app (web client and API)","mx.emxmail.ch (mail server)","mail apps connected to EMX","the programs published for EMX"],"entity_form":"Einzelunternehmen, not entered in the commercial register","legal_basis":["Art. 9 revDSG (processing on behalf)","Art. 28 GDPR (processor obligations)","Art. 100 OR (limitation of liability)","Art. 2 lit. c and Art. 27 BÜPF (derived communication services)"],"jurisdiction":"CH","legal_entity":"Krauss Software, sole proprietorship of Samuel Krauss","governing_law":"Swiss law","effective_from":"2026-10-09"},"summary":{"law":"Swiss law; exclusive venue Zug.","price":"Team: the price per mailbox and month shown at Stripe Checkout, charged monthly in advance. Private: free. Enterprise: separate contract. No trial.","changes":"30 days' notice by email.","deletion":"A removed person's mailbox can be turned into a shared mailbox or handed to a colleague; otherwise it is deleted after 30 days. After the contract ends the organisation sends and receives nothing; 30 days to read and export, then deletion.","customers":"Businesses only, for their business purposes; the person signing up confirms they may bind the organisation.","liability":"Unlimited for intent and gross negligence (Art. 100 para. 1 OR); for slight negligence limited to the greater of twelve months' fees and CHF 500.","availability":"No availability commitment and no service level agreement.","cancellation":"An owner ends the contract by cancelling the organisation in EMX, and can undo that within 30 days; the billing portal is closed meanwhile, and if the subscription had ended, an undo leaves at least 7 days to renew it. If only the Team subscription ends, in the billing portal or unpaid, sending is suspended at the end of the period paid, and EMX cancels the organisation if within 30 days it is neither renewed nor cancelled. We may end the contract with three months' notice, and give twelve months' notice if EMX is discontinued.","legal_entity":"Krauss Software, the sole proprietorship of Samuel Krauss in Oberägeri ZG, trading as Elchi Studios. Not entered in the commercial register.","breach_notice":"Without undue delay, within 72 hours of becoming aware.","data_location":"Switzerland, Germany, the Netherlands, France and Bulgaria. Mails of the sign-in service EAuth are sent through Resend, Inc., which stores them in the United States. EMX sends the customer's mail through its own mail servers. Spamhaus is asked about the IP addresses of sending servers and the domains messages link to, never about content.","data_ownership":"The customer owns its mail and data; export at any time without asking.","processor_role":"Krauss Software is the processor; the customer is the controller (Annex A).","organisation_access":"The organisation is the controller. Administrators can neither read nor export an active person's mailbox, and can hand a removed person's mailbox to a colleague. Nobody, neither the organisation nor we, can open a sealed mailbox."},"sections":[{"text":"1.1 These terms govern the use of EMX, a hosted mail service operated by **Krauss Software** (\"we\", \"us\"), the sole proprietorship of Samuel Krauss, seated in Oberägeri, Canton of Zug, Switzerland. Krauss Software is not entered in the commercial register. Samuel Krauss, as its owner, is personally liable for its obligations. Elchi Studios is the name under which the service is presented. 1.2 The \"customer\" is the business that creates an organisation in EMX: a legal entity, or a natural person acting in their trade or profession. EMX is offered only to businesses and only for their business purposes, on every plan including the free one. It is not offered to consumers. 1.3 The person who creates the organisation and accepts these terms confirms that they are authorised to bind the customer. If that authority is missing, they are liable to us as the law provides for a person acting without authority. 1.4 \"People\" are the natural persons to whom the customer gives a mailbox or access to EMX. They use EMX on the customer's behalf, and the customer is responsible for their use of it as for its own. People sign in through EAuth, our sign-in service; what that involves is described in Annex A. 1.5 These terms alone govern EMX. The general terms and conditions of Elchi Studios for software, websites and hosting and the EAuth Terms of Service do not apply to EMX, and neither do terms of the customer. Where we and the customer sign a separate written contract for EMX, such as for the Enterprise plan, that contract prevails over these terms where it differs.","heading":"1. Who these terms are between"},{"text":"2.1 EMX is mail on the customer's own domains: mailboxes for its people, shared mailboxes, groups and aliases; a web client; IMAP and SMTP submission for mail apps such as Outlook, Apple Mail and Thunderbird, including the shared mailboxes a person is a member of; automatic replies, forwarding and rules that file mail on the server; a filter for spam on incoming and outgoing mail, which refuses attachments that are programs, also inside archives; an API and webhooks; and an export of the mail. A scan for known viruses runs only while a virus scanner is connected to EMX. At the time of this version none is, because the platform EMX runs on does not offer one yet (Annex B, B.6). An automatic reply goes only to a sender whose domain passes SPF or DMARC, with the subject the person set or a fixed one, and counts against the sending limits in 6.3. The documentation at docs.elchi.dev/emx describes the service as it is. 2.2 EMX does not include, at the time of this version: calendar and contacts (CalDAV and CardDAV), Exchange ActiveSync, a mobile app of its own, signed installers for the desktop app, or an archive that meets the requirements of the Swiss ordinance on the keeping of business records (GeBüV). We make no promise as to whether or when any of these will be offered. 2.3 We develop EMX further and may change it. We give at least 30 days' notice by email before we remove a feature the customer uses to a material extent, and the customer may then end the contract with effect from the day of the change. Changes to the API follow the versioning rule in the API reference. 2.4 **Sealed mailboxes.** Where the organisation allows it, a person can seal their own mailbox. By default only an organisation of one person allows it; its owners can change that (Section 9.3). From then on, each message, including its subject, its sender and its recipients, is stored encrypted to a key of the person's. We keep that key only encrypted to the person's recovery code and to a passkey or a passphrase of theirs, none of which we ever see. Mail that was in the mailbox before it was sealed is not sealed and stays readable as before. Neither the customer nor we can open a sealed message. Our servers handle a message in clear only while it is being received or sent. A sealed mailbox cannot be read in a mail app, its mail cannot be searched on the server, it sends no automatic replies and forwards nothing, and of its rules only those on the size of a message apply. If the person loses their recovery code and every passkey and passphrase, the sealed mail cannot be recovered by anyone. Annex B, B.1, says exactly what is encrypted and what is not. 2.5 **The customer's own Resend account.** For a domain, the customer may choose to send its outgoing mail through its own account at Resend, Inc. instead of through EMX's own mail servers. EMX then hands that domain's outgoing mail to Resend with the customer's key. Resend acts under the customer's own contract with Resend, as the customer's provider and not as ours. Otherwise EMX sends all mail through its own mail servers and uses no third party to send it.","heading":"2. The service"},{"text":"3.1 The contract is concluded when the person signing up creates the organisation in EMX and accepts these terms. We record the version accepted and the time. Where we create the organisation for the customer, the contract is concluded instead by a written contract signed by both parties. 3.2 The plans are Private (free of charge, for one mailbox on one domain), Team (charged per mailbox and month) and Enterprise (on request, under a separate written contract). Their scope and limits are those in Section 6 and in the documentation. There is no trial period. 3.3 The Team plan is a subscription taken out through Stripe Checkout. The price per mailbox and month, and any value added tax, are those shown at checkout before the customer pays and on the invoice. Prices are stated in Swiss francs. 3.4 The subscription is charged monthly in advance, to the payment method the customer gives Stripe. The number of mailboxes charged follows the personal mailboxes in the organisation; when it changes, Stripe charges or credits the difference pro rata. Invoices are available in the billing portal, which administrators open from the administration of the organisation in EMX. 3.5 If a payment fails, Stripe tries again. If the Team subscription ends, because it was cancelled in the billing portal or because payment remains outstanding, and the organisation has not been cancelled, EMX suspends the organisation at the end of the billing period already paid: it can no longer send mail, but it still receives mail, and its people can still read and export their mail. EMX tells the organisation's owners. If within 30 days the subscription is neither taken out again nor the organisation cancelled, EMX cancels the organisation, and Sections 4.2 and 8.5 apply from then on. 3.6 We may change prices with 30 days' notice by email. A change applies from the first billing period that starts after the notice period. The customer may cancel before then under Section 4.2. 3.7 Stripe (Stripe Payments Europe, Limited, Ireland) processes the payment data under its own terms, as an independent party. We do not receive or store full card details.","heading":"3. Sign-up, plans and payment"},{"text":"4.1 The contract runs for an indefinite period. A Team subscription renews each month. 4.2 The customer may end the contract at any time by cancelling the organisation in EMX, which only an owner of the organisation can do. The contract ends at that moment: from then on the organisation sends and receives no mail, and Section 8.5 applies. During the 30 days in Section 8.5 an owner can undo the cancellation, and the contract then continues. 4.3 Cancelling the organisation also ends a Team subscription, at the end of the monthly billing period already paid. Fees for a billing period that has started are not refunded. Ending only the Team subscription, in the billing portal, does not end the contract; Section 3.5 then applies. 4.4 We may end the contract with three months' notice to the end of a calendar month. If we discontinue EMX as a whole, we give every customer at least twelve months' notice. 4.5 Either party may end the contract with immediate effect for good cause, in particular if the other party seriously or repeatedly breaches these terms and does not remedy the breach within a reasonable period after a written warning, unless a warning would be pointless. 4.6 Section 8.5 governs what happens to the data when the contract ends. 4.7 If the only person of an organisation asks for their EAuth account to be deleted, we cancel the organisation for them that day; it is deleted when the account is, 30 days after the request. Until then Section 8.5 applies, and if the person keeps the account, we undo the cancellation. Where other people work in an organisation, deleting the account ends only that person's access; the customer decides about their mailbox under Section 9.","heading":"4. Term and ending the contract"},{"text":"5.1 **We give no availability commitment.** There is no service level agreement, no availability figure we promise, and no credit for downtime. We would rather say so than publish a figure we cannot yet stand behind. 5.2 What we do instead is described in Annex B, B.5: EMX runs on two application servers at two providers in two countries, every database write is confirmed on three servers, and the stored messages are copied every night to a second provider. 5.3 While EMX cannot be reached, servers sending mail to the customer normally keep it and try again, usually for several days; how long is decided by the sending server and not by us. EMX tries to deliver outgoing mail for five days and then returns it to the sender as undeliverable. 5.4 We carry out maintenance so that it interrupts the service as little as possible. 5.5 Support is given in German and English through the console at panel.elchi.dev or at contact@elchi.dev. We aim to answer within one working day (Monday to Friday, except public holidays in the Canton of Zug). This is an aim, not a commitment.","heading":"5. Availability and support"},{"text":"6.1 The customer and its people must not use EMX to: - send unsolicited mass advertising, or mail to addresses that were bought, harvested or otherwise obtained without the recipients' consent; - send malware, or links to it; - send phishing, or otherwise deceive recipients about who is writing, such as by forging senders or imitating another organisation; - send, store or make available content whose sending or possession is unlawful, in particular depictions of sexual abuse of children, content that incites violence or hatred, and content that infringes the rights of others; - harass or threaten people; - relay mail for third parties, or resell EMX without a separate written agreement; - circumvent the limits in 6.3, probe or test the security of EMX without our written permission, or impair the service for others. 6.2 Newsletters and other mail to many recipients are permitted only to recipients who have consented, with a working way to unsubscribe, and within the limits in 6.3. EMX is not a mass mailing service. 6.3 These limits apply: | Limit | Private | Team | |---|---|---| | Recipients outside EMX per person and hour | 300 | 300 | | Recipients per person and calendar day (counted from midnight Swiss time) | 200 | 1,000 | | Recipients per organisation and calendar month | 1,000 | 30,000 | | Storage per mailbox | 10 GB | 50 GB | | Size of one message, attachments included | 50 MB | 50 MB | | Recipients of one message | 100 | 100 | | Mailboxes and domains | one each | no limit | | Requests to the API | 600 per minute and token | 600 per minute and token | A message that would go over a sending limit is refused. Going over a limit only refuses that message; it does not stop the person's sending. Outgoing mail is checked by the filter in Annex B, B.6, as incoming mail is (Section 7.5). Receiving mail is limited only by the size of a message and the storage of the mailbox; while a mailbox is full, EMX asks the sending servers to try again later. On the Enterprise plan the limits are those of the contract. 6.4 We may lower a limit with 30 days' notice. To stop abuse we may, at once and for as long as needed, lower the daily limit of one person or stop their sending (Section 7). 6.5 Abuse is reported to abuse@emxmail.ch. How we handle reports is described at docs.elchi.dev/emx-abuse.","heading":"6. Acceptable use and limits"},{"text":"7.1 We may suspend the sending of mail, or access to EMX, for a person, a mailbox or the whole organisation, if: - there are concrete indications of use contrary to 6.1; - an account appears to be compromised; - mail sent from the organisation endangers the delivery of other customers' mail, for instance by putting our servers on block lists; - an authority or a court orders it; or - the Team subscription has ended while the organisation has not been cancelled (Section 3.5). 7.2 Where the situation permits, we warn the customer first and give it reasonable time to remedy the problem. Where it does not, we suspend first and inform the customer's administrators within one working day, with the reason, unless the law or an order forbids it. 7.3 We choose the least restrictive measure that is effective, such as stopping the sending of one person, or lowering their daily limit, rather than suspending the whole organisation, and lift it as soon as its cause has been removed. Suspension never deletes data. 7.4 A justified suspension gives no claim to damages or to a reduction of fees. 7.5 **Automatic stop.** If a person's outgoing messages are refused repeatedly as spam or because they carry malware, EMX stops that person's sending on its own. Only such refusals stop a person; a message refused for going over a limit in 6.3 does not. A stopped person's mail is refused until an administrator of the organisation, or we, lift the stop. The administrators see the stop and its reason in the administration of the organisation, and it is recorded in the organisation's audit log.","heading":"7. Suspension"},{"text":"8.1 The customer's mail and data belong to the customer. We claim no rights to them and process them only to provide EMX, as Annex A describes. 8.2 The customer can take its mail out at any time without asking us: each person can export their mailbox, and the shared mailboxes they may read, as a file in the web client; mail apps read all of it over IMAP; and the API gives access to every message. 8.3 When the customer removes a person, that person's access ends at once. When removing them, or during the following 30 days, an administrator can turn the person's mailbox into a shared mailbox, or hand its mail to a colleague, who can then read and export it. Sealed messages stay unreadable to everyone (Section 9.3). A mailbox that is not handed on in one of these ways is deleted after 30 days. Administrators cannot export another person's mailbox directly. 8.4 When the customer removes a domain, EMX stops accepting and delivering mail for it at once and stops signing mail with its keys. Mail already received stays in the mailboxes. 8.5 **When the contract ends** (Section 4.2), the organisation sends and receives no mail any more, and EMX keeps its data for 30 days. During that time its people can still sign in, read their own mail and export it, and its owners can export all mailboxes of the organisation. The billing portal is closed while the organisation is cancelled. An owner can undo the cancellation during the 30 days. If the Team subscription had ended by then, the undo leaves at least 7 days to take it out again before the cancellation under Section 3.5 starts again. After 30 days we delete the mailboxes with their messages, the people, the domains and the rest of the organisation's data. On request we confirm the deletion in writing. 8.6 Deleted data also disappears from the copies of the message bodies within a few days, and from the database backups when they are replaced in the normal backup cycle. We restore from backups only to recover the service after a failure, never to bring back a customer's data that was deleted. Records we must keep by law, such as invoices (Art. 958f OR), are kept for as long as the law requires. 8.7 The export of a sealed mailbox contains its messages as they are stored: encrypted. The person can open them with their key, for instance with their recovery code and the age tool. 8.8 EMX is not an archive. Where the customer must keep business records, such as under Art. 958f OR and the GeBüV, it is responsible for doing so, for example by exporting the mail it must keep.","heading":"8. Data, export and deletion"},{"text":"9.1 The customer is the controller of the mail in its organisation. It decides, within the law, who may read a person's mailbox when that person leaves or is absent. It must observe the protection of its employees' personal data (Art. 328b OR) and the applicable data protection law, and inform its people of its rules in advance. 9.2 EMX gives administrators no way to read or export the mailbox of a person who is active in the organisation. One thing they do see: where the organisation chooses to hold suspected spam in a quarantine instead of filing it in the person's junk folder, its administrators see the sender, the recipients and the subject of each held message, so that they can release or delete it. When the customer removes a person, its administrators can deal with that person's mailbox only as Section 8.3 describes. Every such step is recorded in the organisation's audit log. 9.3 Mail in a sealed mailbox cannot be opened by anyone other than the person who sealed it: not by the organisation and not by us. If that person leaves without making their mail available, the organisation cannot read it, and it is not handed on with the rest of the mailbox. The owners of the organisation decide whether its people may seal their mailboxes; by default only an organisation of one person allows it. Turning sealing off does not unseal a mailbox that is already sealed. The customer should agree with its people whether business mail may be kept in a sealed mailbox. 9.4 We do not open a person's mail on behalf of the customer. The functions of EMX described here are the way to reach it. Section A.11 of Annex A governs requests from authorities.","heading":"9. The mail of people who leave, and access by the organisation"},{"text":"10.1 The customer keeps the details of the organisation and its billing contact accurate. 10.2 The customer ensures that its people keep their sign-in details and app passwords secret, and that a lost device's app password is revoked. We recommend a second factor for every person. A suspected compromise is reported without undue delay to security@elchi.dev. 10.3 The customer may only add domains it is entitled to use, and is responsible for their DNS records. Mail for a domain reaches EMX only once the domain's MX record points to it. 10.4 The customer ensures that its people comply with Section 6, informs them about EMX and the processing of their data, and answers the requests of data subjects whose data is in its mail, with the tools of EMX and our help under Annex A.","heading":"10. The customer's responsibilities"},{"text":"11.1 For the personal data in the customer's mail and in the accounts of its people, the customer is the controller and we are its processor. Annex A is the data processing agreement and forms part of these terms. 11.2 For our own purposes, namely concluding and performing the contract, billing, contact with the customer, the security of the service and handling abuse, we are the controller. For these purposes we process the details of the organisation and its billing contact, the administrators' contact details and the logs described in Annex B, B.7.","heading":"11. Data protection"},{"text":"12.1 We are liable without limitation for damage caused intentionally or by gross negligence (Art. 100 para. 1 OR), for personal injury, and wherever else the law does not permit liability to be limited in advance. Nothing in these terms limits that liability. 12.2 For slight negligence, our liability is limited to direct damage and, in total for all claims arising in a calendar year, to the greater of the fees the customer paid for EMX in the twelve months before the event causing the damage and CHF 500. Liability for indirect and consequential damage, in particular lost profit, is excluded for slight negligence. 12.3 If mail or data is lost for a reason for which we are responsible, we restore it from the most recent copy available and bear the cost. Further claims for the loss exist only under 12.1 and 12.2. 12.4 We are not liable for the content of mail sent or received by the customer, for the loss of sealed mail whose keys were lost (Section 2.4), for the services of the customer's own Resend account (Section 2.5), for other servers that refuse or delay mail or file it as spam, or for events beyond our reasonable control. 12.5 We are liable for the people we engage, including our sub-processors, as for our own conduct. 12.6 The customer indemnifies us against claims of third parties arising from use of EMX contrary to these terms by the customer or its people, unless we are responsible for the claim.","heading":"12. Liability"},{"text":"13.1 We give at least 30 days' notice of a change to these terms by email to the organisation's administrators and its billing contact. 13.2 If the customer does not agree, it may end the contract before the change takes effect, under Section 4.2. Otherwise the new version applies from the day stated. A change required by law, or needed at once to protect the security of the service, may take effect sooner; we say so in the notice. 13.3 Every version of these terms remains published, with its date, so that it can be seen what applied when.","heading":"13. Changes to these terms"},{"text":"14.1 Swiss law applies, excluding its conflict of laws rules and the United Nations Convention on Contracts for the International Sale of Goods. 14.2 The exclusive place of jurisdiction is Zug, Switzerland. We may also bring proceedings at the customer's seat. 14.3 If a provision of these terms is invalid, the rest remains in force, and the invalid provision is replaced by a valid one that comes as close as possible to what it intended. 14.4 These terms are published in German and in English with the same content. If the two versions differ, the German version prevails. 14.5 Notices to the customer go by email to the addresses in the organisation's administration. Notices to us go to legal@elchi.dev. 14.6 The customer may transfer the contract only with our written consent. We may transfer it to a company that continues the business of Krauss Software, with notice by email; the customer may then end the contract with effect from the transfer.","heading":"14. Final provisions"},{"text":"This annex is the agreement on the processing of personal data on behalf of the customer required by Art. 9 of the Swiss Federal Act on Data Protection (revDSG) and by Art. 28 of the General Data Protection Regulation (GDPR), where that applies. It forms part of these terms and needs no separate signature. Terms not defined here have the meaning given in the revDSG and the GDPR. ### A.1 Subject matter and duration We process personal data for the customer in order to provide EMX, for as long as the contract runs and until the deletion described in A.15. ### A.2 Nature and purpose Receiving, filtering incoming and outgoing mail for spam and harmful attachments, storing, indexing for search, displaying, synchronising, sending and exporting mail; managing the organisation's people, mailboxes, domains and rights; recording security and access events; and making the backups and copies described in Annex B. ### A.3 Data subjects The customer's people; the people who write to them or receive mail from them; and the people named in that mail. ### A.4 Categories of personal data - Account data: names, addresses, roles, the identifier of the person's sign-in, preferences, signatures, and digests of app passwords and tokens. - The content of messages and attachments, of any kind. - Message data: sender, recipients, subject, times, size, flags and folder. - The full-text search index of mailboxes that are not sealed. - The senders a person has allowed or blocked. - Logs: sign-ins, administrative actions and IP addresses, as described in Annex B, B.7. - Push subscriptions of browsers in which a person has turned on notifications. Mail can contain sensitive personal data in the sense of Art. 5 lit. c revDSG and Art. 9 and 10 GDPR, such as health data. EMX processes such data like any other mail. Whether the customer may send and keep it by mail is the customer's decision and responsibility. ### A.5 Instructions We process the data only on the customer's documented instructions. These terms and the customer's settings in EMX are those instructions. If we consider that an instruction infringes data protection law, we tell the customer and may suspend carrying it out until it is clarified. We process the data for other purposes only where the law obliges us to, as described in A.11. ### A.6 Confidentiality Everyone we authorise to process the data is bound by a written duty of confidentiality that continues after their engagement ends. We do not read the customer's mail. Where looking at a message is unavoidable, such as for a message a person sends us to resolve a problem, we look at it only as far as necessary. ### A.7 Security We take the technical and organisational measures in Annex B. We may change a measure, but not in a way that lowers the overall level of protection. ### A.8 Sub-processors The customer gives general authorisation for the sub-processors listed here: | Company | What it does for EMX | What it sees | Where | |---|---|---|---| | Infomaniak Network SA | Runs an application server (web client, API and mail ports), the object storage for the message bodies, and the server that watches the others | Everything EMX processes; message bodies are stored there only encrypted (Annex B, B.1) | Geneva, Switzerland | | Tavuru | Runs the primary database server; outgoing mail leaves through its address | The database (Annex B, B.1 says what in it is not encrypted); outgoing mail in transit, encrypted where the receiving server supports TLS | Frankfurt, Germany | | Hetzner Online GmbH | Runs a database replica and one of the two edge proxies, where HTTPS ends | The database; the requests of the web client and the API in transit | Nuremberg and Falkenstein, Germany | | Scaleway SAS | Runs an application server, a database replica, the nightly copy of the message bodies and an encrypted copy of the database backups | Everything EMX processes, as for Infomaniak and Tavuru | Amsterdam, Netherlands, and Paris, France | | UpCloud Oy | Runs the second edge proxy, where HTTPS ends | The requests of the web client and the API in transit | Amsterdam, Netherlands | | ClouDNS Ltd. | Answers the DNS name behind every host with the edge proxies that are healthy | DNS queries only, no message or account content | Sofia, Bulgaria | | Spamhaus Technology Ltd, through its Data Query Service (DQS) | Answers whether the IP address of a server sending mail to EMX, or a domain a message links to, is on the Spamhaus block lists | Those IP addresses and domains; no message content | United Kingdom; its name servers also elsewhere (A.9) | | Resend, Inc. | Sends the mails of the sign-in service EAuth to the customer's people, such as confirmations of their address and password resets | The recipient's address and the subject and text of those mails | Sent from its European Union region, stored in the United States | Resend does not send the customer's mail. EMX sends it through its own mail servers, except for a domain for which the customer has chosen its own Resend account (Section 2.5). These are not sub-processors and receive no content of mail: Stripe, which processes payment data as an independent party (Section 3.7); Cloudflare, which holds the DNS zones of our domains; and the push services of browser makers, which carry a notification, encrypted end to end to the browser, only to a browser in which a person has turned notifications on. We give at least 30 days' notice by email before adding or replacing a sub-processor. If the customer objects on reasonable data protection grounds within that period and we cannot accommodate the objection, the customer may end the contract with effect from the change. Every sub-processor is bound by data protection obligations no weaker than this annex, and we remain liable to the customer for them. ### A.9 Transfers abroad The data is processed in Switzerland and in Germany, the Netherlands, France and Bulgaria, and Spamhaus Technology Ltd is in the United Kingdom. These states, the United Kingdom included, provide adequate protection under Annex 1 of the Swiss Data Protection Ordinance (DSV), and the European Commission has found Switzerland and the United Kingdom adequate (Art. 45 GDPR). The name servers through which Spamhaus answers the questions in A.8 can also be in other states; a question carries only the IP address of a sending server or a domain a message links to, and no content of mail. One transfer goes outside both: Resend, Inc. stores the mails of the sign-in service in the United States. For data from Switzerland it rests on the standard contractual clauses in Resend's data processing agreement, as adapted for Swiss law (Art. 16 para. 2 lit. d revDSG). For data subject to the GDPR it rests on Resend's certification under the EU-U.S. Data Privacy Framework (Art. 45 GDPR), with those clauses in addition (Art. 46 para. 2 lit. c GDPR). Data held by a provider in another state can be reached by that state's authorities under its law, through the provider. Message bodies held by our providers are encrypted with a key that is not kept with the stored data; the database is not encrypted in that way (Annex B, B.1). If the customer sends through its own Resend account (Section 2.5), that transfer is the customer's. ### A.10 Data subject rights If a data subject asks us to exercise their rights, we forward the request to the customer without undue delay and do not answer it ourselves. EMX gives the customer the tools to answer: export, correction and deletion. Where these are not enough, we help the customer at no charge. ### A.11 Requests from authorities We disclose the customer's data to an authority only where Swiss law obliges us to, on an order of a competent Swiss authority. Requests from foreign authorities must go through Swiss mutual legal assistance. We tell the customer about a request without delay, unless the law or the order forbids it. How we handle requests, and what data exists, is described at docs.elchi.dev/emx-authorities. ### A.12 Assistance We help the customer, taking into account the nature of the processing and the information available to us, with the security of the processing, with notifying breaches of data security, and with data protection impact assessments and prior consultations (Art. 22 to 24 revDSG, Art. 32 to 36 GDPR). ### A.13 Breaches of data security We notify the customer of a breach of data security that affects its data without undue delay, and in any case within 72 hours of becoming aware of it. The notice describes the nature of the breach, as far as known the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. We notify the customer even where we are not certain that the breach affects it, because that judgement is the customer's. ### A.14 Audits The customer may request the information needed to show that this annex is complied with once per calendar year, and after a breach affecting its data. No certification or independent audit of EMX exists; we say so rather than let the customer assume otherwise. An audit on site requires 30 days' notice, must not disrupt the service or disclose other customers' data, and is at the customer's cost. ### A.15 Deletion and return When the contract ends, the customer can make a final export for 30 days, as Section 8.5 describes. We then delete the data, as Sections 8.5 and 8.6 describe, unless the law requires us to keep it. On request we confirm the deletion in writing.","heading":"Annex A: Data Processing Agreement"},{"text":"These are the measures in place, not a general list. Where something is not protected, this annex says so. ### B.1 Encryption - **Message bodies.** Every message, with its attachments, is compressed and encrypted with AES-256-GCM under a master key before it is stored in the object storage. The object storage and its nightly copy hold only ciphertext. - **The master key** is held in the platform's secret store and in the operator's password manager, and is not part of any backup. - **What is not encrypted in this way:** the database. It holds, for mailboxes that are not sealed, the sender, recipients, subject, times, flags and folder of each message, a short preview, and the full-text index for search built from the subject, the people and the text. It also holds the account data of Annex A, A.4. - **Secrets** are encrypted with the master key: the private keys for DKIM, the stored tokens of the sign-in service, the keys of the customer's own Resend accounts, the secrets of webhooks, the passwords given for importing mail, and the account and keys for the certificate of the mail server. - **App passwords, API tokens and session tokens** are stored only as SHA-256 digests. An app password is 100 random bits and is shown once. - **Sealed mailboxes.** Each message, including its subject, sender and recipients, is encrypted with age (X25519) to the mailbox's public key as soon as it is received or sent. The private key is kept on the server only encrypted to the person's recovery code and to a passkey or a passphrase, none of which the server sees. Mail that was in the mailbox before it was sealed is not encrypted in this way. What stays readable to the server is the time a message arrived, its size, its folder and its flags, and for mail sent to other servers the delivery record in B.7. Sealed messages are not indexed for search on the server, and IMAP is not available for them. While a message is being received or sent, the server handles it in clear. - **In transit.** The web client and the API are served over HTTPS only. HTTPS ends at our edge proxies, and from there requests travel over our own encrypted network between the servers. The mail ports use TLS 1.2 or newer; passwords are accepted only after TLS has been established. Outgoing mail is sent with TLS whenever the receiving server offers it, and only with TLS where the receiving domain requires it through MTA-STS. Whether mail travels encrypted between other servers and EMX also depends on the other side. ### B.2 Access control - People sign in through EAuth, with OpenID Connect; a second factor is available. Mail apps use one app password per device, which can be revoked on its own. - Rights are set per mailbox (read, write, delete, send as, send on behalf, manage) and checked on every request. A token never has more rights than the person it belongs to. EMX has no function by which an administrator reads or exports the mailbox of an active person. Where the organisation holds suspected spam in a quarantine, its administrators see the sender, the recipients and the subject of each held message, and why it was held, but not its content. - A removed person's mail reaches a colleague only when an administrator turns the mailbox into a shared mailbox or hands it on (Section 8.3); both are recorded in the audit log. - Failed sign-ins are counted per IP address and per account; too many lock further attempts for a period. - Access to the servers, the database and the master key is limited to the people who operate EMX and the platform it runs on. With that access, mail that is not sealed could technically be read; it is used only as Annex A, A.6, allows. ### B.3 Separation Every record belongs to one organisation, and each request is checked against the rights of the person making it. Organisations share servers and the database; the separation is logical. ### B.4 Integrity - Incoming mail is checked with SPF, DKIM and DMARC; outgoing mail is signed with DKIM. - Administrative actions are recorded in the organisation's audit log, with the person, the action and the time. - A message is stored in the object storage before the database refers to it, so an interruption cannot leave a reference to half a message. ### B.5 Availability and resilience - Two application servers, at two providers in two countries, each accept mail and serve the web client and the API. - Every database write is confirmed on three servers at three providers in two countries. The database is backed up weekly in full, daily by difference and continuously by its write-ahead log, which allows a restore to a point in time; an encrypted copy of the backups is kept at a second provider. - The message bodies are copied every night to a second provider, from which they are read if the first fails. - Connections and sign-ins to the mail ports are limited per address and in total, and sending is limited as Section 6.3 states. ### B.6 Filtering - Incoming and outgoing mail is checked for spam before it is filed or sent, using the checks in B.4, the sending server's name and address, the content, block lists, and a classifier per organisation that learns from what its people file as junk. - The block lists of Spamhaus, through its Data Query Service, are asked about the IP address of the sending server and about the domains a message links to. They receive no content of mail. - Attachments that are programs are refused, also when they are inside an archive. - A scan for known viruses runs only while a virus scanner is connected to EMX. At the time of this version none is, because the platform EMX runs on does not offer one yet; until then mail is not scanned for known viruses. - Mail filed as junk, or held in quarantine where the organisation chose that, is deleted after the organisation's retention period, 30 days unless it set another. ### B.7 Logs - The security and access logs record sign-ins, administrative actions and the IP address they came from. After 90 days, IP addresses in these logs are shortened to their network: an IPv4 address to its first 24 bits, an IPv6 address to its first 48. - The operating logs of the servers record connections to the mail ports with their IP address, and the sender of each message sent; they are used only to run the service and to handle abuse. - The delivery record of each outgoing message (sender, recipient, time and outcome) is kept for a week after delivery, so that a person can see where their mail went. - Counters of failed sign-ins are kept in memory for the length of their window only. ### B.8 Organisational measures - Secrets are given to the service through the platform's environment and are never committed to source control. - Every release is built from a reviewed commit and passes the automated tests first. - No independent security audit of EMX has been performed. When one is, we will publish the result regardless of its outcome.","heading":"Annex B: Technical and organisational measures"},{"text":"| Version | In effect from | Change | |---|---|---| | 1.1 | 9 October 2026 | Section 4.7 says what happens to an organisation when a person has their EAuth account deleted. Section 1.5 names the general terms and conditions of Elchi Studios by their name, without \"agency\". Every version is published at legal.elchi.dev. In effect without the notice in Section 13.1, since on that day no organisation outside Elchi Studios was affected. | | 1.0 | 6 October 2026 | First published version. |","heading":"Annex C: Version history"}]},"legal_basis":["Art. 9 revDSG (processing on behalf)","Art. 28 GDPR (processor obligations)","Art. 100 OR (limitation of liability)","Art. 2 lit. c and Art. 27 BÜPF (derived communication services)"],"effective_from":"2026-10-09T00:00:00Z","published":true,"source_sha256":"52df038943f13e785ab2da18972e6ac620101958e76bf327a4a23bd7921db854","created_at":"2026-10-09T05:31:13.264341Z","updated_at":"2026-10-09T05:31:13.264341Z","alternates":[{"locale":"de","slug":"emx-terms","title":"Allgemeine Geschäftsbedingungen für EMX"}],"toc":[{"level":1,"title":"EMX Terms of Service","anchor":"emx-terms-of-service"},{"level":2,"title":"1. Who these terms are between","anchor":"1-who-these-terms-are-between"},{"level":2,"title":"2. The service","anchor":"2-the-service"},{"level":2,"title":"3. Sign-up, plans and payment","anchor":"3-sign-up-plans-and-payment"},{"level":2,"title":"4. Term and ending the contract","anchor":"4-term-and-ending-the-contract"},{"level":2,"title":"5. Availability and support","anchor":"5-availability-and-support"},{"level":2,"title":"6. Acceptable use and limits","anchor":"6-acceptable-use-and-limits"},{"level":2,"title":"7. Suspension","anchor":"7-suspension"},{"level":2,"title":"8. Data, export and deletion","anchor":"8-data-export-and-deletion"},{"level":2,"title":"9. The mail of people who leave, and access by the organisation","anchor":"9-the-mail-of-people-who-leave-and-access-by-the-organisation"},{"level":2,"title":"10. The customer's responsibilities","anchor":"10-the-customers-responsibilities"},{"level":2,"title":"11. Data protection","anchor":"11-data-protection"},{"level":2,"title":"12. Liability","anchor":"12-liability"},{"level":2,"title":"13. Changes to these terms","anchor":"13-changes-to-these-terms"},{"level":2,"title":"14. Final provisions","anchor":"14-final-provisions"},{"level":2,"title":"Annex A: Data Processing Agreement","anchor":"annex-a-data-processing-agreement"},{"level":3,"title":"A.1 Subject matter and duration","anchor":"a1-subject-matter-and-duration"},{"level":3,"title":"A.2 Nature and purpose","anchor":"a2-nature-and-purpose"},{"level":3,"title":"A.3 Data subjects","anchor":"a3-data-subjects"},{"level":3,"title":"A.4 Categories of personal data","anchor":"a4-categories-of-personal-data"},{"level":3,"title":"A.5 Instructions","anchor":"a5-instructions"},{"level":3,"title":"A.6 Confidentiality","anchor":"a6-confidentiality"},{"level":3,"title":"A.7 Security","anchor":"a7-security"},{"level":3,"title":"A.8 Sub-processors","anchor":"a8-sub-processors"},{"level":3,"title":"A.9 Transfers abroad","anchor":"a9-transfers-abroad"},{"level":3,"title":"A.10 Data subject rights","anchor":"a10-data-subject-rights"},{"level":3,"title":"A.11 Requests from authorities","anchor":"a11-requests-from-authorities"},{"level":3,"title":"A.12 Assistance","anchor":"a12-assistance"},{"level":3,"title":"A.13 Breaches of data security","anchor":"a13-breaches-of-data-security"},{"level":3,"title":"A.14 Audits","anchor":"a14-audits"},{"level":3,"title":"A.15 Deletion and return","anchor":"a15-deletion-and-return"},{"level":2,"title":"Annex B: Technical and organisational measures","anchor":"annex-b-technical-and-organisational-measures"},{"level":3,"title":"B.1 Encryption","anchor":"b1-encryption"},{"level":3,"title":"B.2 Access control","anchor":"b2-access-control"},{"level":3,"title":"B.3 Separation","anchor":"b3-separation"},{"level":3,"title":"B.4 Integrity","anchor":"b4-integrity"},{"level":3,"title":"B.5 Availability and resilience","anchor":"b5-availability-and-resilience"},{"level":3,"title":"B.6 Filtering","anchor":"b6-filtering"},{"level":3,"title":"B.7 Logs","anchor":"b7-logs"},{"level":3,"title":"B.8 Organisational measures","anchor":"b8-organisational-measures"},{"level":2,"title":"Annex C: Version history","anchor":"annex-c-version-history"}]}}