Legal
Security
Effective date: July 17, 2026
Security is part of how Qsendyx is designed, not a feature bolted on afterward. This page summarizes the main technical and organizational measures we apply. No system is perfectly secure, but the platform is built to fail closed.
1. Tenant isolation
Every account’s data is isolated at the database layer using PostgreSQL Row Level Security. The application connects with a role that has no privilege to bypass those policies, and the tenant is derived from your session or API token, never from the client. One customer cannot read or write another customer’s data.
2. Authentication and secrets
Passwords are hashed with argon2id and never stored in plain text. API tokens are stored only as a prefix, a hash of the secret and its last characters. The full secret is shown once, at creation, and cannot be recovered afterward. Tokens are scoped, and each can be revoked independently. DKIM private keys used to sign your email are encrypted at rest and never leave the platform.
3. Data in transit and at rest
Traffic to the platform is served over TLS. Message content and metadata are processed only to deliver your messages and provide analytics, and sensitive material (including secrets and provider credentials) is never written to logs.
4. Billing integrity
Balances are computed from an immutable, append-only ledger (reserve, consume and release) rather than a mutable column, and every financial write is protected by idempotency and database transactions. This prevents a message from being charged twice or a balance from being corrupted by a retry.
5. Abuse prevention
The platform enforces per-account quotas and rate limits and monitors for spam, SMS pumping, phishing and OTP abuse. Suppression lists are enforced on every send so opted-out and previously bounced recipients are not contacted again, and an emergency kill switch can halt sending when abuse is detected.
6. Provider webhooks
Status and engagement events arrive from carriers and email providers as untrusted input. We preserve the raw payload, verify the provider’s signature, apply idempotency, and confirm that each event belongs to the right message, provider and tenant before acting on it. Out-of-order and duplicate events are treated as the rule, not the exception.
7. Reporting a vulnerability
If you believe you have found a security issue, please email contact@qsendyx.com with the details. We appreciate responsible disclosure and will work with you to validate and address the report.