Overlay / Amazon SES
Keep Amazon SES cheap. Add the operations it omits.
SES is inexpensive and scalable, and almost deliberately bare: no real deliverability tooling, no operations team, no UI to speak of. Egressif sits on top of SES and supplies the operating layer it leaves entirely to you.
The gap
Where SES leaves you on your own.
- ▸ SES moves mail cheaply but ships with almost no deliverability tooling.
- ▸ Warming, reputation, and suppression strategy are entirely your team’s job.
- ▸ Real support costs extra, and incidents are yours to debug from logs.
- ▸ Sending limits and account reviews can throttle you at the worst moment.
How the overlay works
Your ESP becomes one path. We become the layer above it.
What the layer adds
What you gain on top of moving mail.
Monitoring on the wire
We watch the actual responses your sends get from receivers, in real time, across every path. Blocklistings, reputation signals, deferral waves, and auth failures get caught as they happen, not in a weekly export.
Ordered failover
Your providers and our network become ordered paths. When one is blocked or throttled, traffic moves to the next automatically. A single provider having a bad day stops being your outage.
Route engineering
Decide how mail leaves: which path per destination, priority for time-sensitive messages, per-receiver throttles, separate lanes per stream. Routing becomes something you configure, not something a single vendor decides for you.
Suppression at the gate
Bounces, complaints, and do-not-contact requests are enforced beneath every application and every path, so an upstream mistake cannot send to someone who already opted out.
Evidence per message
For every message: which server accepted it, when, over what TLS, with the verbatim response, retained on your terms rather than expiring in a provider’s short window.
One provider for the whole stack
DNS, mailboxes, and sending under one operator instead of a different vendor for each layer. Fewer seams, and one team accountable when something breaks instead of a finger-pointing call.
Consolidated view
Every stream and every path in one place: what sent, what landed, what is at risk. Stop stitching together a separate dashboard per vendor to answer one question.
One vendor, one bill, one API
A single relationship, a single invoice, and one API for provisioning and delivery events, instead of integrating, reconciling, and paying several.
No migration
You keep your provider, your templates, and your code. Point your sending at us and your current setup keeps carrying traffic until you are satisfied.
Stream separation
Transactional and marketing stop sharing a reputation. Each stream earns its own, so a campaign can never sink a password reset.
Keep Amazon SES
What stays. What changes.
Your SES setup stays and becomes one routed path under the operating layer, so you keep its price and scale. We add the monitoring, warming, suppression, and evidence on top, plus a second path so an SES limit or review is not a full stop.
Two ways to work with us
Overlay today, whole stack later. Both work.
Start as a layer above Amazon SES. If you ever want us to own DNS, mailboxes, and the network too, the path is already there.
Managed
We run it for you.
Routing, suppression, warming, reputation, and incident response are ours. You get plain-language reporting on what happened and what we did. The email part of your week goes quiet.
Self-serve
You drive it.
Provision domains and mailboxes, set routing and fallbacks, and pull delivery data through the console and API. The same engine, operated by your team, at your pace.
FAQ
Running Amazon SES? Answered.
Do we lose the low SES price?
No. SES stays as a routed path, so you keep its cost and scale for raw sending. You are adding the operating layer that SES does not provide, not replacing SES.
SES has a suppression list already, no?
A basic one. We enforce suppression (bounces, complaints, do-not-contact) at the gate beneath every application and every path, so an opted-out recipient cannot be reached by a mistake upstream.
Can you help with the SES sending-limit ramp?
Yes. We warm on a demand-gated ramp and, because SES is one path among others, growth is not gated solely by a single account’s limits.
Put the operating layer on top of Amazon SES.
Tell us your volume and what hurts. We will show you exactly what the layer adds, and what it costs, in one conversation.