Security
& trust.

Effective Date: October 14, 2026 Last Revised: October 14, 2026

This page describes how maildx protects the data you entrust to it. It is written to be verifiable: every claim below maps to a specific control in our system, not to an aspiration.

1. Tenant isolation

maildx is multi-tenant software, so isolation is the control that matters most.

• Every tenant row is scoped. All tenant tables carry a non-null company_id.
• Isolation is enforced by the database, not by application code. Each request runs inside a transaction that sets app.company_id before any query, and PostgreSQL Row-Level Security filters rows accordingly. A missing or incorrect tenant context returns no rows rather than the wrong rows.
• Vector search filters inside the query. Knowledge retrieval applies the company_id predicate *within* the SQL statement. We never retrieve first and filter afterwards, which is the common way this control fails.
• Cache, storage, and log keys include the tenant. There is no shared cache namespace across companies.

Cross-tenant access tests run as part of the test suite for new endpoints and jobs.

2. Encryption

Provider credentials are decrypted only at the moment of use. They are never logged, never returned to the browser, and never included in a prompt sent to an AI model. After saving an integration, the interface shows only the last four characters of the key.

3. Your data and AI models

• No training on your data. Customer email and uploaded documents are never used to train, retrain, or fine-tune foundation models. AI inference runs under enterprise zero-retention terms.
• Minimum necessary context. Only the cleaned message body, a summary, and the retrieved evidence passages are sent to the model. Attachments are not sent in the current release.
• Email is treated as untrusted input. Message content is placed in delimited blocks so it cannot be interpreted as instructions to the model.
• The model cannot act. It has no tools. Only pipeline code can send an email or create a ticket, and only after the grounding checks pass.
• Every run is recorded. Each AI execution writes a row capturing the model, prompt version, retrieved chunk IDs, extracted claims, confidence, decision, token usage, and cost.

4. Grounding and correctness controls

• Answers are generated only from your retrieved sources and must cite them. If there is no supporting evidence, the pipeline escalates instead of guessing.
• A configurable confidence threshold governs whether a draft may be sent. Below it, a human ticket is created.
• Sensitive categories — chargebacks, legal matters, security breaches, account takeover, harassment, and data-rights requests — are routed to humans and never auto-replied.
• Any AI failure, timeout, or low-confidence outcome fails toward a human. No customer message is left unanswered.

5. Webhook and email integrity

• Webhook signatures are verified against the raw request body before parsing, using a constant-time comparison, and stale timestamps are rejected.
• Processing is idempotent. Events deduplicate on the provider event ID and on the RFC Message-ID, so a redelivery cannot produce a duplicate reply.
• Outbound sends carry an idempotency key.
• maildx never replies to auto-replies, bounces, no-reply senders, its own domain, or mailing-list traffic, and it honours Auto-Submitted and Precedence headers.
• "Accepted", "delivered", and "answered" are tracked as distinct states, never collapsed into one.
• Raw email HTML is never rendered. Content is sanitised and displayed as text.

6. Access control and audit

• Authorization is enforced server-side on every request. The web tier only renders; it never decides access.
• Role-based controls separate owner, admin, and agent capabilities.
• Privileged and state-changing actions write immutable audit events: settings changes, document creation and deletion, ticket assignment, draft approval and rejection, kill-switch toggles, DPA acceptance, retention purges, and customer data exports or erasures.
• Logs record identifiers rather than message bodies, addresses, or names at information level.

7. Operational controls

• Rate limiting is applied globally to the API.
• Security headers are set on every response, and error responses never expose stack traces.
• Retries are bounded with exponential backoff and jitter. Unrecoverable jobs are routed to a dead-letter queue visible in the processing log.
• Backups are taken by the managed database provider, and a restore drill is part of the release process.

8. Data retention and deletion

• Each workspace sets a retention window between 7 and 365 days (default 90).
• A nightly cascade purge permanently deletes expired conversations, messages, AI run records, and webhook payloads, leaving no orphaned rows.
• Customers can export or permanently erase all data for a single data principal from the workspace, in line with DPDP access and erasure rights.
• On account termination, records are permanently purged within 30 days.

9. Breach notification

We maintain a documented incident-response runbook with defined severity levels, a named on-call owner, and an evidence-preservation process.

In the event of a confirmed personal data breach affecting your workspace, we will notify you in writing within 24 hours of confirmation, describing what happened, what data was involved, the likely consequences, and the remedial action taken.

10. Sub-processors

maildx relies on a small set of infrastructure and AI providers. Each is bound by a data processing agreement, and the current list — with purpose, data category, and processing region — is published on the Sub-Processors page. We provide at least 30 days' advance notice before adding a new sub-processor.

11. What we do not claim

Security is a practice, not a certificate. To be precise about our current position:

• maildx is not currently certified for ISO 27001 or SOC 2.
• We do not claim to be "fully compliant" with any framework. We implement the specific controls described above and can discuss them in detail.
• We publish no uptime guarantee. Service levels are described in our Terms of Service.

If your procurement process requires a security questionnaire, a penetration-test summary, or an architectural review call, contact us — we would rather answer directly than have you infer from a marketing page.

12. Reporting a vulnerability

If you believe you have found a security issue, please report it to security@maildx.dev with enough detail to reproduce it. Please do not test against other customers' data, and give us a reasonable window to fix the issue before public disclosure. We will acknowledge your report and keep you informed of the resolution.

13. Contact

• Security reports: security@maildx.dev
• Privacy and data protection: privacy@maildx.dev
• All contacts: see the Contact & Grievance page