# Security

_Last updated 20 August 2026_

What we actually do today to protect your data and your sending reputation — and, just as importantly, what we have not built yet. We would rather you find the gaps here than in a procurement review.

## Not yet certified, and we will not imply otherwise

SadaSend does not hold SOC 2, ISO 27001, or HIPAA attestation. We are a new company and those take time and audited history to earn. If your procurement process requires one of them today, we are not yet the right vendor and we will tell you that rather than waste your evaluation cycle.

What follows is what is genuinely in place now.

## Encryption

- All API and dashboard traffic is served over TLS 1.2 or higher. HTTP requests are redirected, never served.
- SMTP submission on port 587 requires STARTTLS. We do not accept unencrypted authentication.
- Outbound mail uses opportunistic TLS to receiving servers, which is the strongest guarantee the email protocol allows.
- Data at rest — database and object storage — is encrypted using our infrastructure providers’ managed encryption.

## Credentials

- API keys are stored as hashes. We cannot show you a key again after you create it, because we do not have it.
- Every key carries an explicit scope set, its own rate limit, an optional recipient allowlist, and an optional approval mode. A leaked key does strictly less damage than a leaked key elsewhere.
- DKIM private keys are generated per domain, encrypted at rest, and never exposed through the API or dashboard.
- Passwords are hashed with a memory-hard algorithm. We support two-factor authentication on all plans, including Free.

## Access control

Access to production systems is limited to engineers who need it, requires two-factor authentication, and is logged. We do not read customer message bodies as a matter of routine — only when you ask us to investigate a specific message, or where we are legally compelled.

## Abuse prevention

A shared sending platform is only as trustworthy as its worst customer, so abuse controls are a security feature rather than an operational afterthought.

- New accounts start with capped sending limits and are reviewed before those limits are raised.
- Bounce and complaint rates are evaluated per account continuously, with automatic throttling and suspension.
- Sending from an unverified domain is refused outright, which prevents most impersonation attempts.
- Suppression is enforced when a message is accepted rather than when it is sent, so a suppressed address fails fast and visibly.

## Reporting a vulnerability

Security inquiries and vulnerability reports will be accepted through our dedicated security channel upon public launch. We aim to acknowledge within one business day and to keep you updated until the issue is resolved.

We will not pursue legal action against researchers who act in good faith, stay within their own account’s data, avoid degrading the service for others, and give us reasonable time to fix an issue before publishing. We do not currently run a paid bounty programme, and we will say so plainly rather than imply one exists.

## Reporting abuse

If you have received unwanted mail sent through SadaSend, reports with full message headers will be reviewed through our abuse channel upon launch. Reports are investigated by a person, and we act on the sending account rather than asking you to unsubscribe.