Security
Security by architecture, not just policy.
Every email SendOps touches goes out through your own AWS SES account — on your domains, your IPs, your reputation. Your application's transactional sending never passes through SendOps at all. We never hold your AWS keys.
Architecture
Data isolation by design
The single most differentiating aspect of SendOps's security model is architectural. Email delivery lives in your AWS account, not ours — there are two lanes, and both stay yours.
Your application's sending: untouched
Transactional email your application sends through SES never passes through SendOps. We observe delivery events via EventBridge — if SendOps were unavailable, your email would keep flowing.
Campaigns you author in SendOps: dispatched through your SES
Broadcasts and workflow emails are composed by SendOps and sent through SES in your AWS account — your domains, your IPs, your reputation. Never through shared infrastructure.
Your AWS account, your resources
SES configuration sets, identities, and EventBridge rules are provisioned inside your AWS account via CloudFormation. You maintain full ownership and visibility over every resource.
No access to your databases
SendOps never connects to your application databases. Contact and audience data lives in SendOps only when you put it there — via import, the API, or sync — and it stays scoped to your organization, exportable, and deleted with your account.
Recipient address handling
Recipient email addresses are stored in plaintext within the search index (scoped per account) to enable per-message lookup. For analytics and aggregate reporting, addresses are stored as irreversible hashes.
Zero stored credentials
SendOps connects to your AWS account through STS temporary credentials, not stored API keys. You deploy a CloudFormation stack that creates a scoped IAM role — we assume that role on demand using short-lived tokens that expire automatically. There are no keys to rotate, no secrets to leak, and no credentials stored on our side. If you want to revoke access, delete the stack. The role disappears and so does our access — instantly and completely.
Infrastructure
Where things run
- Hosting: Hetzner Online GmbH (Germany) and Amazon Web Services (United States).
- Encryption in transit: TLS 1.2+ on all external connections.
- Encryption at rest: All databases, backups, and stored credentials are encrypted at rest.
- Network isolation: Production systems are segmented behind firewalls and security groups with restricted access.
- Patch management: Regular updates to OS, dependencies, and application code.
Access Control
Authentication & access
Your account
- Session-based authentication with secure, server-side session storage. Sessions are not stored in cookies or client-side storage.
- Role-based access control for Authorized Users within your organization.
Our systems
- Multi-factor authentication required for all administrative access to production.
- Unique accounts for all personnel — no shared credentials.
- Principle of least privilege across all internal systems.
Data Handling
What we store, and for how long
- Data about your workspace. Account and user records, authentication and session data, audit records, usage and device data, billing references, and your AWS and SES configuration.
- Contact and audience data you place here. Recipient email addresses, your own contact IDs, the custom attributes you define and populate, list and segment membership, segment definitions, consent and topic preferences, and suppression status. It arrives by CSV import, by API, by sync with your SES contact list, or from definitions in a repo you connect — never by us reaching into a database of yours.
- Data generated by sending. Email events from SES (sends, deliveries, bounces, complaints, opens, clicks), recipient-level message history, per-recipient campaign outcomes including why a recipient was filtered, and activity events you send us. Recipient addresses are plaintext in the searchable event store (scoped to your workspace, behind its own permission) and irreversible hashes in the analytics store.
- Campaign content. Templates, subject lines, preview text, inline content, merge data, workflow definitions, and assets — because SendOps has to render and send them. Email your application sends straight through SES is never stored, because it never reaches us.
- AWS access. Via a scoped IAM role assumed with short-lived STS tokens. No long-lived AWS keys are stored — delete the CloudFormation stack and our access ends instantly.
- Plan retention is a visibility window, not a delete schedule. Your plan sets how far back reports and search will show event data. Physical deletion is separate: email event records are deleted 24 months after ingest and move to cold storage after 90 days, while your contacts, consent records, and content stay until you delete them or close the workspace. The full schedule — category by category — is in the Privacy Policy.
Free
7 days
Team
90 days
Business
1 year
- Account deletion. Full deletion of account data upon closure, with ordered cascade across all stores.
Consent & Suppression
How opt-outs are enforced
Suppression is only worth something if it holds. Here is exactly where it is applied, and the one place it is deliberately not.
- Two tiers, checked before a message is composed. Every broadcast is filtered against workspace-level state (suppressed, or unsubscribed from everything) and topic-level state (opted out of this campaign's topic). Filtered recipients are recorded with the reason and never sent to.
- Stricter wins. When SendOps and your SES contact list disagree about a recipient's consent, the stricter state governs and is pushed back to SES. A relaxed state in SES never re-enables sending.
- One-click unsubscribe, signed per recipient. Broadcasts carry
List-Unsubscribeand RFC 8058 one-click headers, and the hosted unsubscribe page records the choice workspace-wide or per topic. - Test sends bypass consent filtering — by design. A test send goes to a small set of addresses you name so you can see the real rendered email. It skips the audience snapshot and both consent tiers, never changes campaign state, and is excluded from reporting. Address test sends only to your own workspace members or to seed addresses you control — using one to reach an opted-out recipient breaches the Terms.
- What a test send cannot bypass. Every send still goes through SES in your account, so your account-level and configuration-set suppression lists still apply. Addresses SES suppressed for a hard bounce or a spam complaint stay suppressed — that control sits below SendOps and is not bypassable through the product.
Deliverability
Keep transactional and marketing traffic apart
One shared reputation means a marketing complaint spike can take your password resets down with it. This is a recommendation, not a requirement — but it is the single highest-leverage thing most teams can do for deliverability.
- Separate sending subdomains for each traffic class.
- Separate SES configuration sets, so events, tracking, and suppression settings are scoped per class.
- Separate reputation monitoring and alert thresholds.
- Separate suppression and subscription policies — a marketing opt-out should not silence a receipt.
- Separate AWS accounts where volume or risk warrants the blast radius.
Compliance
Legal & regulatory
SendOps is operated by AltaCoda LLC, a Delaware limited liability company. We comply with applicable data protection laws including GDPR and CCPA/CPRA.
- SOC 2 Type II. Certification in progress.
- GDPR. We act as a data processor when handling personal data on your behalf. Our DPA includes Standard Contractual Clauses (Module 2) for EEA, UK, and Swiss data transfers. Sub-processor list published at sendops.dev/subprocessors.
- CCPA/CPRA. We do not sell or share personal information. Our DPA includes CCPA service provider certification.
| Document | Link |
|---|---|
| Terms and Conditions | sendops.dev/terms |
| Privacy Policy | sendops.dev/privacy |
| Data Processing Addendum | sendops.dev/dpa |
| Sub-processor List | sendops.dev/subprocessors |
Incident Response
When things go wrong
- Documented incident response procedures for identifying, containing, and remediating security incidents.
- Personal Data Breach notification within 72 hours, as required by GDPR and committed in our DPA.
- Post-incident review and remediation for all security events.
Vendor Management
Sub-processor oversight
- Due diligence conducted on all sub-processors before engagement, evaluating their security practices and data protection controls.
- Contractual data protection obligations imposed on every sub-processor.
- 30-day advance notice of sub-processor changes, with objection rights for customers.
- Full sub-processor list published at sendops.dev/subprocessors.
Responsible Disclosure
Found a vulnerability?
We're grateful to security researchers who help keep SendOps safe. If you've found a vulnerability, please reach out privately before public disclosure.
- We acknowledge reports within 2 business days.
- We work to understand and validate the reported issue.
- We will not take legal action against researchers acting in good faith.
- We ask for reasonable time to remediate before public disclosure.
Transparency
What we don't do
- ✕ We don't send email through shared infrastructure — every send goes out through your own SES.
- ✕ We don't hold long-lived AWS keys for your account.
- ✕ We don't expose recipient addresses beyond your organization's scope.
- ✕ We don't access your application databases.
- ✕ We don't buy, rent, broker, append, or enrich contact lists — or supply you with recipients.
- ✕ We don't sell or share your data.
- ✕ We don't store full payment card numbers.
- ✕ We don't impose directory structures on your repositories.
