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 the connected AWS account, not ours — there are two lanes, and both remain under the account owner's control.
The AWS owner's application sending: untouched
Transactional email sent directly through SES never passes through SendOps. We observe delivery events via EventBridge — if SendOps were unavailable, that email would keep flowing.
Campaigns authored in SendOps: dispatched through connected SES
Broadcasts and workflow emails are composed by SendOps and sent through SES in the connected AWS account — using that account's domains, IPs, and reputation. Never through shared infrastructure.
The AWS owner's account and resources
SES configuration sets, identities, and EventBridge rules are provisioned inside the connected AWS account via CloudFormation. The account owner maintains ownership and visibility over every resource.
No access to your databases
SendOps never connects to the Customer's or Client's application databases. Contact and audience data lives in SendOps only when an authorized user puts it there — via import, the API, or sync — and it stays scoped to the applicable workspace, exportable, and deleted when that workspace is closed.
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 the AWS account through STS temporary credentials, not stored API keys. The owner or an authorized administrator deploys 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. Deleting the stack removes the role and revokes our access.
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.
DMARC Reports
Aggregate evidence without message content
SendOps accepts DMARC aggregate reports and deliberately does not request or process forensic reports. Aggregate reports contain sending IPs, message counts, authentication results, and receiver dispositions. They do not contain message bodies. This gives teams the evidence needed to identify sources and improve authentication without collecting recipient-level message content through DMARC.
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 or subprocessor, as applicable, when handling personal data on your behalf or on behalf of a managed client. Our DPA includes the applicable Standard Contractual Clauses (Module 2 or Module 3) for EEA, UK, and Swiss data transfers. Provider and sub-processor list published at sendops.dev/subprocessors.
- CCPA/CPRA. We do not sell personal information. Optional advertising technologies can be disabled through Cookie settings or Global Privacy Control. 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 |
| Service Provider and 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
Provider and sub-processor oversight
- Due diligence conducted on providers before engagement, based on the data they process and the role they perform.
- Contractual data protection obligations imposed on every further sub-processor that handles customer-controlled Personal Data.
- 30-day advance notice of sub-processor changes, with objection rights for customers.
- Full provider and 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.