sendvia runs on top of your own Amazon SES account rather than replacing it. This page is about the gap between what raw SES gives you and what sendvia adds, what the $19 a month actually buys, and the cases where using SES directly is the better call.
SES is a sending API and an identity store, metered by the message. Verify a domain and it hands back three DKIM CNAME tokens, a sending quota and a rate. Nothing about what happens after you call it is SES's problem to solve, and mostly it does not try to.
The identity check stops at DKIM. SES does not generate an SPF record for bounce.yourdomain.com, a DMARC record, or a BIMI record, and it has no score that tells you whether what you have added is enough. It checks whether its own DKIM tokens are live and reports SUCCESS on the custom MAIL FROM once the MX resolves, and nothing more, so a domain can read as verified in the console while SPF is still authenticating amazonses.com instead of your own domain because the SPF TXT record was never added.
Bounces, complaints, delivery delays and rejections are all available, but only if you build the pipe yourself: an SNS topic, a configuration set event destination pointed at it, an HTTPS endpoint that handles the subscription confirmation handshake, and somewhere to store what arrives. SES keeps no message history of its own once a send call returns. There is no per-message record to search by recipient, subject or tag: you get a response to the API call itself, and after that you are working from whatever you built to catch the notifications.
It also has nothing resembling a contact list, a segment, a newsletter composer, open or click tracking, or a per-domain health score. That is not a gap so much as a description of what SES is: a delivery API, priced at $0.10 per 1,000 emails, with the application layer left for someone else to write.
Yes. Everything sendvia's dashboard shows can be built from the console and the CLI, because that is what sendvia itself is doing underneath: verify the identity, read the DKIM tokens back, create the SNS topic, subscribe the endpoint, attach the event destination to a configuration set. None of it runs on a private API.
What changes is who writes the glue, and how many times. Add a domain in sendvia and three AWS calls run in sequence: register the identity, then wire the notification side, which creates the SNS topic, points a configuration set's event destination at four SNS event types, and subscribes sendvia's own webhook URL to it. Do the same from the console and you do each step by hand, per domain, including the SNS subscription confirmation that a browser session will not complete for you automatically.
The console also stops at what SES itself models, which is DKIM status and a sending quota. It has no domain health score, because health here means DKIM plus DMARC enforcement plus MAIL FROM alignment plus BIMI plus your own bounce and complaint rate, weighed against the 5% bounce and 0.1% complaint rates at which SES itself would suspend the account. That is arithmetic sendvia runs on top, not something the console reports back.
The AWS setup is identical either way and it is real work. You need your own AWS account, an IAM user scoped to SES and SNS, and a new account starts inside Amazon's sandbox, capped at 200 emails a day to verified recipients only until Amazon grants production access, typically within 12 to 24 hours. Nothing about using sendvia instead of the console shortens that part.
Domain setup generates the SPF, DMARC and BIMI records SES's own identity check does not produce, checks each one live against DNS whenever the page loads, and rolls the result into a single health score from 0 to 100 with a grade from Critical to Excellent. That score is what the console does not compute: DKIM, DMARC enforcement, MAIL FROM alignment and BIMI, weighed against your own 30-day bounce and complaint rate against the thresholds at which SES itself suspends sending.
Adding a domain also wires up SNS automatically, covering the four event types SES publishes for a failure: bounce, complaint, delivery delay and reject. From there you can add your own HTTPS webhooks per domain, each with a signing secret and a choice of five event types, and a delivery that fails gets retried rather than dropped.
One line of that needs a caveat rather than a claim. "Delivered" is inferred, not confirmed. SES can emit a real DELIVERY event over SNS, and sendvia does not subscribe to it, because doing so once flooded the webhook pipeline and stalled the site. What you see instead is a message marked delivered two minutes after sending if nothing negative has arrived by then, or after 24 hours for one that was deferred. It is a reasonable inference from silence, not a confirmation, and it is worth knowing which one you are looking at.
Every send lands in a log SES does not keep at all: filterable by status, tag, source, domain and date range, searchable by recipient, sender, subject or body, with a click count per link on any message that got one. The SES dashboard turns the same data into delivery and bounce rate, average and fastest and slowest delivery time, a day-by-day chart, the top subjects by open rate on premium, the top tags by volume, and an SES cost estimate for the month split across API, SMTP and newsletter traffic. Retention runs 7 to 90 days depending on plan, against SES's own zero: once a send call returns, SES is not holding a copy of what happened.
Sitting in front of the account itself is a REST API at /v1/send and an SMTP relay on smtp.sendvia.io, with 2525 as a fallback for networks that block 587, plus contacts, segments and a newsletter composer, none of which SES has an equivalent of. AWS also publishes official SDKs for SES in every major language; sendvia has none, only the plain HTTP API and SMTP.
SES really is cheap on its own: $0.10 per 1,000 emails, billed straight to your AWS account, nothing else in the price. The $19 sendvia charges never touches that rate. It is a separate, flat fee for the platform described above, and Amazon bills the email itself at the same rate whether or not you use sendvia at all.
At 1,000 emails a month SES costs $0.10 and the flat fee is 99.5% of the $19.10 total: you are paying for the platform, and there is barely any SES bill underneath it. Push that to 100,000 emails and SES's own $10.00 turns the same $19 into a $29.00 total, with the flat fee down to 65.5% of it. At 1,000,000 emails SES costs $100.00, sendvia costs $119.00, and the $19 is down to 16.0% of the bill. The fee never moves. What moves is how much of the total it is.
Whether that is worth paying depends on whether you would otherwise build the dashboard, the health score and the webhook plumbing yourself. If that would cost you real development time and you send enough to use it most days, $19 a month clears that bar easily. If you send a handful of emails and have no interest in a log to search or a chart to read, it does not, and the next section is about exactly that case.
Four situations, each a real reason on its own rather than a token gesture at balance.
You already have tooling you are happy with. If you have already built your own SNS-to-webhook bridge, your own send log, or you already read SES through CloudWatch and that tells you what you need, sendvia duplicates infrastructure you are not short of. AWS also publishes official SDKs for SES in every language that matters; if your code is already written against one of those, there is nothing to gain by rewriting it against a plain HTTP API.
You need an SES feature or region sendvia does not surface. The add-domain form offers ten AWS regions: both US East regions, both US West regions, Ireland and Frankfurt in Europe, Singapore, Sydney and Tokyo in Asia Pacific, and São Paulo. An identity anywhere outside that list has to be managed straight from AWS, because sendvia's dashboard has no way to add it. The same goes for anything past sendvia's own ceilings: 50 recipients on a single API call, 500 messages in a batch, and scheduling no more than 72 hours out. Past any of those, the call has to go to SES directly.
You send little enough that a dashboard is not worth $19. A side project sending a handful of password resets a month has nothing to search, filter or graph. The SES console's own identity status and a CloudWatch chart are free and cover that completely.
You require dedicated IPs, which sendvia has no option for. Amazon sells a managed dedicated IP directly, at $15 a month per account plus a per-email fee, and it is a real answer to a reputation problem a shared pool can cause at high volume. sendvia's domain dashboard has no field for requesting or attaching one. If dedicated IPs are what you need, that has to be raw SES.
None of these are hypothetical. If one of them describes you, raw SES is the right tool, and paying $19 a month for a dashboard you would not open does not change that.