Why RevOps keeps ending up on SES
Every RevOps lead evaluating email providers arrives at the same number eventually: fractions of a cent per message on Amazon SES versus multiple cents per message on most ESPs. For a team sending hundreds of thousands to millions of messages a month, the math is not subtle.
SES keeps winning the unit-economics conversation. It keeps losing the operating-layer conversation. The teams that run on SES successfully at scale almost always have either (a) in-house engineering that has rebuilt a mini orchestration layer, or (b) a third-party operating layer on top.
This post is about the RevOps-specific version of that trade-off and how Mailers.io fits as the layer above SES.
Why SES alone is painful for RevOps
SES is a transport. When RevOps has to run outbound, lifecycle, or marketing on SES, the missing parts show up fast:
- No campaigns. RevOps has to wire SES to an external campaign tool or write their own sequence logic.
- No multi-identity rotation. SES identifies the configuration set, not the mailbox.
- Suppression scoped to SES. Cross-provider or cross- identity suppression requires an external source of truth.
- No RBAC beyond IAM. RevOps managers do not want to administer IAM policies; they want per-campaign or per-list roles.
- No CRM-native orchestration. Every integration has to be built.
- Per-region limits and sandboxes. Production-access steps and regional quotas make “scale is easy” less true than the pitch suggests.
These are not bugs; they are correct minimalism for a transport. RevOps is paying for the fact that the operating layer was never part of SES’s scope.
What Amazon SES actually gives you
A fair list of what SES does well:
- Extremely low per-message cost, especially at volume.
- High reliability, scaled to the AWS backbone.
- Native authentication (DKIM signing, SPF alignment) with minimal work on domain verification.
- Configuration sets for event destinations (SNS, CloudWatch, Firehose, Kinesis).
- Shared IP pools with the option of dedicated IPs.
- Region-scoped deployments for latency and compliance.
And what it does not try to do:
- Campaigns, sequences, segmentation, templating beyond basic.
- Multi-identity abstractions for outbound.
- Centralised suppression across other providers.
- RBAC or audit beyond what IAM and CloudTrail give you.
- Reply or inbox management.
- A unified API across other providers you might also run.
What Mailers.io adds above SES
Mailers.io attaches to SES like any other provider. RevOps keeps the AWS bill, the IP strategy, and the configuration sets. Above that, the orchestration layer provides:
- Unified API and normalised events. One surface for SES + SendGrid/Mailgun/Postmark/SMTP/Workspace. RevOps dashboards and CRM webhooks do not branch by provider.
- Campaigns and sequences. Native, cross-identity, without hand-rolling a sequence runner on top of SES.
- Centralised suppression. Workspace-wide. A bounce on SES suppresses sends on Workspace; a Workspace unsubscribe suppresses sends on SES. List-unsubscribe headers are honored automatically.
- Per-identity caps, rotation, priority. SES handles sending; Mailers.io decides from which identity, in what cadence.
- RBAC, audit, DPA. Per-resource roles; audit trail readable without CloudTrail expertise; pre-signed DPA at /dpa.
- CRM-native routing. Hook CRM events into orchestration without writing a Lambda for each case.
Out of scope explicitly:
- Replacing SES or taking over the AWS relationship.
- Inbox or reply management.
- Lead database or data enrichment.
- Warmup.
- Any claim of guaranteed inbox placement.
Side-by-side comparison
| Dimension | Mailers.io (on top of SES) | Amazon SES alone |
|---|---|---|
| Category | Orchestration layer | Transport / sending API |
| Unit cost per message | Same SES cost + orchestration plan | Lowest in the category |
| Campaigns / sequences | Native | Not included |
| Multi-identity routing | Native | Not included |
| Centralised suppression | Workspace-wide, cross-provider | Within SES |
| RBAC | Per-resource Full Access / Read Only | IAM only |
| Events | Normalised across providers | SES-shaped |
| CRM integration | First-class, via integrations and webhooks | Build your own |
| Reply / inbox management | Not provided | Not provided |
| Deliverability guarantee | Not offered | Not offered |
Three architectural differences for RevOps
1. Transport vs operating layer
SES is a world-class transport. RevOps workflows are operating-layer work: campaigns, sequences, suppression, roles, audit. Asking a transport to behave like an operating system ends in a patchwork of Lambdas, DynamoDB tables, and runbooks. Splitting the layers is simpler to run and cheaper to evolve.
2. Cross-provider resilience
SES has rare outages; when they happen, they take down a lot of the internet. An orchestration layer above SES lets RevOps pre-configure a failover to another provider (Workspace for branded sends, SendGrid as a transactional fallback) and keep shipping while SES recovers. The integration list at /integrations is the starting point.
3. Auditability for enterprise procurement
CloudTrail is excellent for auditing AWS API calls. It is not the same as a human-readable audit of which campaign ran against which list with which template, edited by whom. RevOps and compliance teams want the latter. Mailers.io provides workspace-level audit and per-resource RBAC, which complements (not replaces) CloudTrail.
Three RevOps scenarios
Scenario A — RevOps on SES with a homegrown campaign runner
Your team built a simple campaign runner on top of SES two years ago. It works. Adding features has gotten expensive: consent changes, list-unsubscribe header compliance, new CRM hooks, new report shapes.
Keep SES. Move the campaign runner to Mailers.io. The runner problem stops being your team’s problem and the savings on engineering time usually dwarf the orchestration plan cost.
Scenario B — RevOps wants to add Workspace for branded outbound
Sales leadership wants executives and reps to send from Workspace mailboxes for better reply rates. RevOps does not want to maintain two parallel stacks.
Mailers.io runs both from the same API. SES stays for high-volume, non-branded sends (lifecycle, notifications). Workspace handles branded outbound. One suppression list applies to both.
Scenario C — RevOps in a regulated industry
You are in financial services, healthcare, or another sector with real audit requirements. SES + IAM + CloudTrail is part of the answer. You also need application-level audit (who queued this campaign? who edited this template? which list did it run against?).
Mailers.io’s audit, RBAC, and pre-signed DPA (GDPR Article 28, SCCs Module 2, UK IDTA, Swiss FADP, CCPA/CPRA) are the application-level layer.
Pros and cons
When SES alone is enough
- You have strong in-house engineering willing to maintain the operating layer.
- You have narrow use cases (pure transactional, single sender).
- Audit and RBAC are fine at IAM/CloudTrail level.
When Mailers.io on top of SES is the right answer
- RevOps is the primary consumer and wants dashboards, segments, and audit readable without AWS expertise.
- You want the option of a second provider for resilience or for branded/multi-identity sending.
- You want centralised suppression and consent across providers.
- Enterprise procurement wants application-level RBAC and audit.
Who should choose what
The short version: if SES plus a small amount of homegrown tooling has been enough for your RevOps workload and is still enough for the next year, don’t fix what isn’t broken. The moment RevOps wants multi-identity outbound, cross-provider resilience, or audit beyond CloudTrail, the orchestration layer starts paying for itself.
How to decide
SES is the right transport for most high-volume RevOps workloads. Mailers.io is the right operating layer above it. Treat them as separate decisions: keep SES for cost and reliability, add orchestration for campaigns, sequences, suppression, audit, and multi-provider flexibility.
References: /integrations/amazon-ses, /platform/quota-aware-email-routing, /platform/audit-log, and /pricing.
Testing discipline for guide-style problems usually improves when you separate “content experiments” from “infrastructure changes.” If you must change both, sequence them: stabilize the path, then test creative, or you will not know which variable moved the signal you care about. If you are comparing providers, do it with the same list ethics and the same segment definitions; otherwise the comparison is a story, not a measurement.
Runbooks are underrated. A good runbook is not a PDF nobody opens; it is a checklist that includes who is allowed to do what, what “pause sending” does in your configuration, and how to verify suppression state after an incident. Mailers.io is built as orchestration and policy on infrastructure you connect—useful when you have multiple paths, shared templates, and need consistent governance across teams. It is the wrong product if the primary pain is a missing CRM surface or a guarantee that mail will “land in primary.”
Related depth for “Article”: operators often underestimate how much time is spent on credential lifecycle (API keys, SMTP passwords, domain delegation) and how little time is left for improving message quality. Rebalance that intentionally if revenue depends on reliable outbound. Multi-provider routing can reduce provider-specific lock-in and separate blast radius, but it does not remove your obligation to own consent, suppression, and record-keeping. Not legal advice. Where GDPR, CCPA/CPRA, or similar apply, align with counsel. We do not use generic marketing copy to assert SOC 2 or ISO 27001.
Cross-functional alignment fails quietly: Marketing ships a new domain, Data updates a list export, and Engineering rotates an API key—each change reasonable alone, but together they break assumptions about identity and suppression. A useful discipline is a lightweight change log for anything that touches a live sending identity, even if the change is “small.” The goal is not paperwork theatre; the goal is that the next on-call can reconstruct state without heroics.
Procurement and security questions often ask for certifications as shorthand. The better question is: what logs exist, for how long, and who can access them? A control plane can unify routing, but you still need your own data map for personal data, subprocessors, and incident response. This article is educational; align final commitments with your counsel and your customer contracts. We do not claim outcomes we cannot own (placement, read rates, or a unified sales inbox) because that would mis-sell the product’s shape.
Related depth for “Article”: operators often underestimate how much time is spent on credential lifecycle (API keys, SMTP passwords, domain delegation) and how little time is left for improving message quality. Rebalance that intentionally if revenue depends on reliable outbound. Multi-provider routing can reduce provider-specific lock-in and separate blast radius, but it does not remove your obligation to own consent, suppression, and record-keeping. Not legal advice. Where GDPR, CCPA/CPRA, or similar apply, align with counsel. We do not use generic marketing copy to assert SOC 2 or ISO 27001.
Finally, treat deliverability talk as a constraint problem, not a battle of slogans. Recipients, mailbox providers, and local IT policies are not under your vendor’s control. What you can control is list provenance, authentication, throttles, content hygiene, and how fast you stop repeating mistakes. The organizations that do well here look boring: fewer surprises, fewer “unknown unknowns” in audits, and operators who can show receipts.
When you operationalize Article at scale, the durable win is a repeatable review loop: weekly metrics that surface drift before leadership notices. That usually means bounces and complaints as first-class series—not vanity engagement charts—paired with a written rule for when a program pauses. This matters whether your stack is a single console or a multi-provider layer; the work is the same even when “Article” is the public label on the project.
Related depth for “Article”: operators often underestimate how much time is spent on credential lifecycle (API keys, SMTP passwords, domain delegation) and how little time is left for improving message quality. Rebalance that intentionally if revenue depends on reliable outbound. Multi-provider routing can reduce provider-specific lock-in and separate blast radius, but it does not remove your obligation to own consent, suppression, and record-keeping. Not legal advice. Where GDPR, CCPA/CPRA, or similar apply, align with counsel. We do not use generic marketing copy to assert SOC 2 or ISO 27001.
Testing discipline for guide-style problems usually improves when you separate “content experiments” from “infrastructure changes.” If you must change both, sequence them: stabilize the path, then test creative, or you will not know which variable moved the signal you care about. If you are comparing providers, do it with the same list ethics and the same segment definitions; otherwise the comparison is a story, not a measurement.
Runbooks are underrated. A good runbook is not a PDF nobody opens; it is a checklist that includes who is allowed to do what, what “pause sending” does in your configuration, and how to verify suppression state after an incident. Mailers.io is built as orchestration and policy on infrastructure you connect—useful when you have multiple paths, shared templates, and need consistent governance across teams. It is the wrong product if the primary pain is a missing CRM surface or a guarantee that mail will “land in primary.”