Security

Your data is stored in the European Union. EXITO Media LLC, which runs the Service, is a US company; our Privacy Policy explains what that means for your data.

How the pieces fit together

• One hardened server. The web app, the mail server (Stalwart, which we run ourselves), the PostgreSQL databases and the cache run in isolated containers on our server. The databases, the cache and the mail server's management interface are reachable only from inside the server, never from the internet.
• Content in object storage. Message bodies, attachments, Exito Vault files and Exito Transfer files live in object storage, separate from the server. Exito Vault and Exito Transfer files are uploaded and downloaded directly between your browser and storage (Wasabi or Cloudflare R2), using short-lived signed links that work for one file only, so the storage provider also sees your IP address.
• Mail goes direct. Other mail servers, and mail apps using SMTP, IMAP or JMAP on mail.exitomail.com, connect directly to our server and never pass through Cloudflare. We send mail from our own IP addresses, without a third-party relay.
• The web app behind Cloudflare. Our website and the web app at exitomail.com (webmail, Exito Vault and Exito Transfer screens in your browser) are served through Cloudflare's network, which protects them against attacks. Your encrypted connection ends at Cloudflare's edge, which forwards the traffic to our server; this means mail and files you open in the web app pass through Cloudflare in transit.

In transit

• Web. Every page and API is served over HTTPS, with HTTP Strict Transport Security (HSTS) so browsers never fall back to unencrypted connections. Certificates come from Let's Encrypt and renew automatically.
• Mail apps. IMAP (port 993) and SMTP submission (ports 465 and 587) are only offered over TLS, so your password and messages are never sent in clear text between your device and us.
• Server to server. When we exchange mail with other providers we use STARTTLS whenever the other side supports it. We publish an MTA-STS policy so other servers know to require TLS when they deliver to us, and we receive TLS reports (TLS-RPT) so we notice delivery problems. As is standard for email, if the other server does not support TLS and publishes no policy requiring it, a message can travel between the two servers unencrypted.

At rest

Mail content, attachments, Exito Vault files, Exito Transfer files and backups are stored in object storage that our providers encrypt at rest. Backups are additionally encrypted on our own server, with a key we control, before they are uploaded.

Authenticated mail

Every message we send is signed with DKIM (both Ed25519 and RSA keys), and our domain publishes SPF and DMARC records, so receiving servers can check that mail really comes from us. When you connect a custom domain, we give you the same records to publish, and check them before your domain goes live.

• Least privilege. Only a small number of named people can administer our systems, each with only the access their role needs. Access is reviewed regularly and removed promptly when someone leaves.
• SSH keys only. Administrative access to our server uses SSH keys. Password logins are disabled.
• Multi-factor authentication. We use multi-factor authentication on the administration consoles of our hosting, storage, DNS and payment providers, and on our own administrator accounts.
• Separated credentials. Each component of the Service uses its own credentials with only the permissions it needs; for example, each database has its own role.
• Audit log. Administrative actions in our tools, such as suspending an account, are recorded in an audit log.

When our staff may access your content

We do not browse your mail, files or transfers. Our staff access content only when it is necessary:

• to help you, when you ask us to look at something specific;
• to investigate a security issue or a report of abuse; or
• to comply with a legal obligation, as described in our Privacy Policy.

Such access is limited to what the task requires, and it is recorded in the related support or abuse case.

• Passwords. Passwords must be at least 10 characters long. We store them only as salted, one-way hashes, never in plain text, so not even we can see them.
• Two-factor authentication. You can add a second step to sign-in with an authenticator app. We strongly recommend it, especially for organization owners and admins.
• Rate-limited sign-in. Sign-in attempts are rate-limited to slow down password guessing.
• Recovery email. We recommend adding and verifying a recovery email. Password reset links go only to a verified recovery address (never to the mailbox you are locked out of), expire after 30 minutes, and resetting your password signs you out everywhere else.
• Sessions. Session cookies are HttpOnly and Secure, and requests are checked against cross-site request forgery. Sessions end after 30 days without use. Changing your password, recovery email or two-factor settings, or deleting your account, requires your current password.
• Security notifications. When your password changes, we notify you by email at your verified recovery address.

• DKIM keys. Our mail server generates its own DKIM signing keys (Ed25519 and RSA). It rotates them every 90 days for our own domain and for custom domains whose DNS it manages automatically.
• TLS certificates. Certificates are issued and renewed automatically, so they never lapse.
• Secrets. Passwords, API keys and other secrets are kept outside our codebase, on the server, readable only by its administrator account. They never appear in our source code repository.
• Backup keys. Backups are encrypted with a key pair whose private half is kept offline only, never on our servers, so backups can be restored even if the server is lost, and are useless to anyone who obtains the backup files alone.
• Verified webhooks. Payment notifications from Stripe are accepted only with a valid cryptographic signature.
• Rotation. We rotate credentials when someone with access leaves, and immediately whenever we suspect a credential has been exposed.

• Logs. Our servers keep security, access and mail delivery logs, including IP addresses, for 30 days. We use them to keep the Service running, investigate problems and detect abuse, never for advertising or profiling.
• Automated monitoring. An automated watchdog checks our containers, the website, the SMTP service, IMAPS certificate expiry, disk space and the age of our latest backup every 5 minutes, and alerts us whenever something changes.
• Intrusion prevention. Addresses that repeatedly fail to log in to the server are blocked automatically.
• Mail reports. We review DMARC aggregate reports and TLS reports for our domain to spot spoofing and delivery problems.

• What we back up. Every night, a dump of each of our databases (accounts, settings, mail metadata and indexes, Exito Vault and transfer records) and of our server configuration.
• Where. In Wasabi's EU-Central-1 region (Amsterdam), separate from the Frankfurt region that holds your mail and files.
• How. Encrypted on our server before upload, with public-key encryption. The private key needed to decrypt the backups is kept offline only, never on our servers.
• How long. 30 days, on a rolling basis. This also means that data you delete can remain in backups until they rotate out.
• Restores. We have a documented procedure to rebuild the server and restore the databases from backups.

Backups exist to recover from a disaster. They are not used for anything else, and if we ever restore one, we delete again any data that had already been deleted.

We have a written procedure for security incidents, and we follow these steps:

1. 1
   Detect
   Through automated monitoring and alerts, reports from users and security researchers, and notices from our providers.
2. 2
   Contain
   Isolate affected systems, revoke exposed credentials and keys, block malicious traffic and suspend abusive accounts.
3. 3
   Assess
   Establish what happened, which data and people are affected and how serious the risk is, preserving evidence along the way.
4. 4
   Notify
   Where a personal data breach requires it under the GDPR, we notify the competent supervisory authority within 72 hours of becoming aware of it, and tell affected people without undue delay when the risk to them is high. Business customers are notified as their processor without undue delay and within 72 hours, as set out in our Data Processing Agreement. Service disruptions are posted on our status page.
5. 5
   Recover and learn
   Restore service from clean sources, then review the incident to find the root cause and improve our measures so it does not happen again.

• Operating system. Security updates are installed automatically.
• Software we run. Our containers run pinned versions of their software (including the Stalwart mail server, PostgreSQL and the web server). We follow their security releases and update promptly, after reading the release notes and taking a backup.
• Dependencies. We monitor our application's dependencies and keep them up to date.
• Outside reports. We welcome reports from security researchers and fix confirmed issues within target times based on severity (see Responsible disclosure).

• Review. Changes are reviewed before they are deployed, and deployments are scripted and repeatable.
• Built-in protections. Strictly typed code, input validation, protection against cross-site request forgery, rate limiting, and security headers (including HSTS, frame denial and content-type sniffing protection) on every response.
• Separate environments. Development uses local stand-ins for storage and databases, with fictional demo data. Production data is never used for development or testing, and production secrets never leave production.
• Minimal footprint. No third-party analytics or advertising code runs in our website or app, and we disable telemetry in third-party libraries where possible.

We keep the number of companies that handle your data small. We choose them for EU data location, their security practices and their published security attestations, and we sign a data processing agreement with each one. We review them periodically.

The full list, with what each company does, where and under which safeguards, is on our Subprocessors page. We announce new subprocessors at least 30 days before they start processing customer data; to be told by email, write to privacy@exitomail.com with the subject “Subprocessor updates”.

We are open about how ExitoMail is built. The application currently runs on one primary server in an EU data centre. Your mail and file content is held separately in object storage with provider-managed redundancy, and encrypted backups of everything else are kept in a second EU region.

• If the server fails. We follow a documented procedure to rebuild it from scratch on new hardware and restore the databases from the latest backup. Because backups are taken nightly, changes made since the last backup can be lost in a worst case.
• Incoming mail waits during outages. When our server is unreachable, sending mail servers queue messages and retry delivery, normally for several days, as the email standards require.
• Status. Planned maintenance and outages are posted on our status page.

We do our best to keep ExitoMail available, but unless we have agreed a service level agreement with you in writing, we do not promise a specific uptime. The free plan has no service level agreement.

Keeping spammers and fraudsters out protects everyone's mail: it keeps our servers' reputation good, so your messages reach the inbox.

• Sending limits. Every account has a daily sending limit (for example, 100 messages a day on the Free plan). Limits start lower for new accounts and grow with account age and trust.
• Sign-up checks. Sign-ups are rate-limited per IP address, disposable recovery addresses are refused, and a Cloudflare Turnstile bot check runs on the sign-up form.
• Automated enforcement. Our automated enforcement system watches spam complaints, bounces, blocklist listings, malware results, signs of account takeover and reports. It can limit or suspend sending, suspend accounts or domains, block transfers and quarantine files, and block attacking IP addresses. Its measures are reversible, users are told why, and a person reviews every appeal (see Acceptable Use Policy).
• No open relay. Sending always requires authentication, and you can only send from addresses and domains that belong to your account.
• Filtering. Incoming mail is checked for spam on our own infrastructure and may be scanned for malware. To do this, our servers may look up the sending server's IP address or domain in public DNS blocklists.
• Verified domains. A custom domain only starts receiving or sending mail after you prove you own it with a DNS TXT record, so nobody can claim a domain that is not theirs.
• Exito Transfer. We may scan uploads for malware and block flagged files. Links always expire, and recipients can report a transfer in one click.

To report spam, phishing or other abuse that involves ExitoMail, write to abuse@exitomail.com. To report illegal content under the EU Digital Services Act, use our Notice & Action process. Our rules are in the Acceptable Use Policy.

• GDPR. As a US company offering the Service in the EU, we are subject to the GDPR (Article 3(2)). We are the controller for personal accounts and for the data we need to run our business, as described in our Privacy Policy. For business customers we act as a processor under our Data Processing Agreement, and the companies that help us are listed on our Subprocessors page.
• Digital Services Act. As a hosting service, we run a notice-and-action process for illegal content, explain our decisions and offer an appeal. See Notice & Action.
• ePrivacy. We only use strictly necessary cookies and storage. See our Cookie Policy.
• Child safety. As a US provider, we report apparent child sexual abuse material to NCMEC, as 18 U.S.C. § 2258A requires.
• ISO/IEC 27001:2022 and ISO/IEC 27701. Our security program is modelled on these standards. We do not claim certification.

If you believe you have found a security vulnerability in ExitoMail, please tell us. We will work with you to understand and fix it, and we will not take legal action against good-faith research that follows this policy.

How to report

Email security@exitomail.com. Please include:

• a description of the vulnerability and the affected URL, host or component;
• step-by-step instructions to reproduce it, and a proof of concept if you have one (screenshots or a short video help);
• the impact you think it has, and how an attacker could exploit it; and
• how we can reach you, and whether you would like to be credited.

If your report contains sensitive details, ask us for a secure channel first. Please do not send malware or exploit code that runs automatically as an attachment.

This address is for security vulnerabilities only. For spam or phishing, write to abuse@exitomail.com; for help with your account, write to support@exitomail.com.

Scope

In scope:

• exitomail.com and all its subdomains, including mail.exitomail.com (SMTP, IMAP, JMAP, autoconfiguration and MTA-STS);
• the web app: webmail, Exito Vault (including share links), Exito Transfer (including download pages and “request files” links), account settings and the team and address management for custom domains;
• our APIs, sign-up, sign-in, two-factor and account recovery flows; and
• how we handle custom domains (for example, domain verification). Customers' own domains and websites are not in scope.

Out of scope:

• denial-of-service attacks, load testing or any volumetric testing;
• social engineering or phishing of our staff or users, and physical attacks on offices or data centres;
• sending spam, or brute-forcing passwords, without demonstrating an underlying vulnerability;
• missing best-practice headers or settings (for example, a missing security header) without a demonstrated impact;
• self-XSS, and issues that need an already compromised device or account;
• third-party services themselves, such as Cloudflare, Stripe or Wasabi (please report those to the provider); and
• findings from automated scanners without a working proof of concept.

Rules of engagement

• Use your own accounts. Test only with accounts you created yourself. Do not interact with other users' accounts or data without their permission.
• Stop if you reach other people’s data. If you come across someone else's data, stop, do not keep, use or share it, and report it to us right away.
• Minimal proof. Do not copy or exfiltrate more data than the minimum needed to demonstrate the issue.
• Do no harm. Do not degrade the Service, delete or change data that is not yours, or send mail to people who did not agree to receive it. Respect the sending limits of your account.
• Give us time. Keep the details confidential until we have released a fix or 90 days have passed since your report, whichever comes first. If a fix needs more time, we will explain why and agree a new date with you.

Safe harbor

If you make a good-faith effort to follow this policy, we will consider your research authorized, we will not pursue or support legal action against you because of it, and we will not report you to law enforcement. We waive the restrictions in our Terms of Service and Acceptable Use Policy to the extent needed for research carried out under this policy. If a third party takes legal action against you for research carried out under this policy, we will make it known that you acted in line with it.

This safe harbor covers our systems only; we cannot authorize testing of other companies' services. If you are unsure whether something is allowed, ask us first at security@exitomail.com.

Our commitments

Recognition

We do not run a paid bug bounty program at this time. With your permission, we are glad to thank you publicly for a valid report once it is fixed.

security.txt

Our security.txt (opens in a new tab) file at /.well-known/security.txt (RFC 9116) lists our security contact and links to this policy.