Version 1.0 · Effective date: October 15, 2026 · Mailbari LLC
Last Updated: October 15, 2026
Email and files are among the most sensitive things a business has, so security is built into every part of Mailbari. Your data is encrypted in transit and at rest, kept separate from every other customer, and opened by our staff only when you ask for help, to stop abuse, or when the law requires it, with every access logged. We protect your domain's mail with SPF, DKIM, DMARC and MTA-STS, back everything up daily, and tell you within 72 hours if a breach affects your data. If you find a weakness, please tell us at [email protected]. An attacker or a mistake has to get through every layer to reach Customer Data; sections 2 to 8 describe each one.
1.1 Mailbari runs on servers in professional data centres operated by our hosting provider [hosting provider and region, to confirm], with physical access control, power and network redundancy, and fire protection. 1.2 Our core software — the Stalwart mail and collaboration server, ONLYOFFICE for documents and LiveKit for meetings — runs on Mailbari's own servers. Those vendors do not receive your data. 1.3 Production systems sit behind firewalls that allow only the ports the Services need. Administrative access goes through a private, multi-factor connection.
2.1 In transit. Every connection to Mailbari uses TLS 1.2 or higher: the web and mobile apps, IMAP, SMTP submission, CalDAV, CardDAV, WebDAV, the APIs and the MCP server. Older protocols and weak ciphers are switched off. 2.2 Between mail servers. Mailbari sends and receives mail over TLS whenever the other server supports it. Customer domains can publish an MTA-STS policy (we host it for you) so that other providers must use TLS to deliver to you, and TLS reports tell you if something fails. 2.3 At rest. Mail, files, backups and databases are encrypted with AES-256. Keys are kept separate from the data they protect and rotated. 2.4 End-to-end. Users can send and read OpenPGP or S/MIME encrypted mail with their own keys. Mailbari cannot read messages encrypted that way.
Each organisation is a separate tenant with its own users, domains, quotas and permissions. Every request is checked against the organisation and the user making it. Search indexes, AI search indexes and backups keep the same separation.
4.1 Users can protect their account with two-step login using an authenticator app or a passkey. Admins can require it for everyone, and it is required for all Admins. 4.2 Admins can set password rules, session length, allowed sign-in countries, single sign-on (SAML or OpenID Connect) and app passwords for older mail apps. 4.3 Users see their active sessions and devices and can sign out of any of them. We alert Users and Admins about sign-ins from new devices and other suspicious activity. 4.4 The audit log in Admin › Audit records sign-ins, admin changes, sharing, exports, API keys and connected apps for 13 months.
5.1 Only a small number of trained Mailbari engineers can access production systems, each with their own account, two-step login and only the permissions their job needs. 5.2 Staff do not open Customer Data except: (a) when an Admin or User asks for support and approves time-limited support access in Admin › Security; (b) to investigate abuse or a security incident; or (c) when the law requires it. Every such access is logged with the reason, and support access appears in the customer's own audit log. 5.3 Staff sign confidentiality agreements, are trained on security and privacy when they join and every year, and lose access the day they leave.
6.1 Mailbari signs all outgoing mail with DKIM for your domain, checks SPF, DKIM, DMARC and ARC on incoming mail, and helps you set up all the needed DNS records, including in one click through Domain Connect. 6.2 Incoming mail is filtered for spam, phishing, spoofing and malware. Attachments and files are scanned for viruses, links are checked against Google's Web Risk lists, and remote images are blocked until you choose to load them. 6.3 Outgoing mail is watched for signs of compromised accounts, such as sudden spikes or sending from new countries, and sending is paused automatically to protect you and every other customer.
7.1 Every change to Mailbari's code is reviewed by another engineer before release. We scan our code and its dependencies for known vulnerabilities and apply security updates promptly. 7.2 Test and development systems never use real Customer Data. 7.3 An independent security firm will test Mailbari at least once a year, and we fix what they find according to its severity. 7.4 The Mailbari APIs and MCP server use OAuth 2.1 with PKCE, tokens bound to Mailbari's own servers, short-lived access tokens, scoped API keys and rate limits. They never accept tokens issued for other services.
8.1 We back up Customer Data every day, encrypted, to a separate location. Backups are kept for 35 days. 8.2 We test restores regularly and keep a written disaster recovery plan. Our targets are to restore service within 8 hours and lose no more than 24 hours of data in a disaster that destroys a whole data centre; in normal failures redundant servers take over without data loss. 8.3 Deleted items stay in trash for 30 days, and Admins can restore a deleted User for 30 days, so most mistakes can be undone without backups.
9.1 We follow a written incident response plan to find, contain and fix security incidents and learn from them. 9.2 If a personal data breach affects your Customer Data, we tell your Admins without undue delay and within 72 hours of becoming aware of it, with what we know and what we are doing, and we keep you updated. We notify authorities and affected people where the law requires us to. 9.3 Service status and outages are posted at status.mailbari.com.
10.1 If you find a security weakness in Mailbari, please email [email protected] with enough detail for us to reproduce it. Our security.txt file is at mailbari.com/.well-known/security.txt. 10.2 We acknowledge reports within 3 business days, keep you updated, and credit you if you wish once it is fixed. 10.3 We will not take legal action against good-faith research that follows these rules: test only against your own accounts; do not read, change or delete other people's data; do not degrade the Services, send spam or use social engineering; and give us reasonable time to fix the issue before you publish it.
Security is shared. Please turn on two-step login, keep Admin accounts few, remove Users who leave, review connected apps and API keys, keep your domain's DNS records correct, and tell us at once if you suspect a problem.
• Mailbari LLC · 104 Quigley Blvd, Ste 1013, New Castle, DE 19720, USA · +1 302 580 8514 • Bangladesh office · Rafiq Place, Level 1A, BM College Mosque Gate, Barisal-8200, Bangladesh · +880 1805 459129 • Security: [email protected] · Abuse: [email protected]