sendmsg.io vs Amazon SESManaged Email Infrastructure

1. Configuration Sets vs Identities vs Verified Domains — three overlapping concepts

Every engineer onboarding to SES hits this wall. Verified identities are email addresses or domains that have proven ownership via DNS. Configuration Sets are named bundles of sending behavior covering event publishing, IP pool routing, suppression scope, and dedicated IP assignment. The account itself sits in either sandbox or production state, which is separate from both. A single email send has to combine the right identity, the right configuration set, and the right account state to land in an inbox. When something fails, the error message usually points at one layer but the root cause is often a different one. We spent the first week of our SES adoption building a mental map of which layer owns which behavior, and we still re-derive it every time we add a new sending domain.

sendmsg.io collapses the model. A verified sending domain has its own reputation graph, its own event webhook config, its own per-domain suppression scope. One concept. The send happens.

2. Sandbox mode at signup — the 200/day cap nobody warns you about

Brand new AWS accounts land in SES sandbox mode by default. You can send 200 emails per day, to verified recipients only, at one email per second. Exiting requires a Service Quota Increase request that asks for your use case, expected volume, list acquisition method, bounce/complaint handling plan, and unsubscribe mechanism. Approval typically takes 24-48 hours but we have seen accounts wait a week when AWS asks follow-up questions. After approval you start at a low daily quota — often 50K/day — that expands gradually based on your bounce rate (must stay under 5%) and complaint rate (must stay under 0.1%). The pattern catches teams who assumed they could spin up SES on a Friday for a Monday launch.

sendmsg.io has no sandbox. We do KYC at signup and approve production traffic on day one for accounts with a verified business and a clean sending intent. The onboarding speed bump is real on SES.

3. Bounce and complaint handling — AWS makes it your problem

SES does not automatically suppress addresses that bounce or complain. There is an account-level suppression list you can opt into, but the default posture is that you receive the bounce or complaint event via SNS and you decide what to do with it. The typical pattern: SNS topic publishes the event, a Lambda function consumes it, updates your suppression database, and emits a CloudWatch metric. The Lambda code is short — under 100 lines — but the operational surface is not. You need IAM policies that let Lambda read SNS, write to your database, and publish CloudWatch metrics. You need a dead-letter queue for failed invocations. You need alarms on the DLQ depth. You need to handle the schema variants AWS emits for hard bounces, soft bounces, transient failures, complaints, and delivery delays. We have seen teams ship to production with only hard-bounce handling and discover six months later that their soft-bounce volume has been quietly accumulating on a stale-address subset of their list.

// Typical Lambda handler for SES bounce events via SNS
exports.handler = async (event) => {
  for (const record of event.Records) {
    const message = JSON.parse(record.Sns.Message);
    const notificationType = message.notificationType;

    if (notificationType === 'Bounce') {
      const bounceType = message.bounce.bounceType; // 'Permanent' or 'Transient'
      for (const recipient of message.bounce.bouncedRecipients) {
        if (bounceType === 'Permanent') {
          await suppressAddress(recipient.emailAddress, 'hard_bounce');
        } else {
          await trackTransientBounce(recipient.emailAddress);
        }
      }
    } else if (notificationType === 'Complaint') {
      for (const recipient of message.complaint.complainedRecipients) {
        await suppressAddress(recipient.emailAddress, 'complaint');
      }
    }
  }
};

None of this is hard. All of it is your responsibility. sendmsg.io auto-suppresses on every bounce and complaint variant by default, with per-domain scope so a marketing complaint does not poison your transactional list.

4. VPC endpoint setup if you want SES from private subnets

Default SES traffic goes through the public internet. If your application servers live in private subnets and your security posture requires AWS API calls to stay inside the VPC, you need to configure an Interface VPC Endpoint for SES. The endpoint itself costs $7.30 per AZ per month (so $22/month for three-AZ redundancy), plus data processing charges. The IAM and security-group configuration is a separate ticket from the application code change. None of this is unique to SES — every AWS service has the same pattern — but it is one more line item that the SES landing page does not mention.

5. Deliverability tooling gap — no managed warmup, no real reputation dashboard

SES does not have a managed warmup feature. The recommended pattern from the AWS docs is that you start at low volume, monitor CloudWatch, and gradually increase. The mechanism is you, watching dashboards. If you go too fast, ISPs defer or block, your bounce rate spikes, and SES sends you an email titled "Your Amazon SES sending pause has been temporarily increased" which halts your sending entirely. The reputation tooling beyond CloudWatch is limited: VDM is a step up from raw metrics but still primarily a visualization layer, not an actionable system. The first signal of a reputation problem is often the AWS email itself, by which point you are already in remediation mode.

The deeper structural gap: SES applies reputation at the account level by default. Your transactional sends (password resets, OTP, receipts) and your marketing sends share the same account reputation unless you put them on different dedicated IP pools, which costs extra and requires you to manage the segregation in your application code. A complaint on a marketing campaign can degrade your transactional inbox placement. We have watched this happen.

sendmsg.io's Cortex runs warmup automatically with a 30-day default schedule, per-ISP throttling, and engagement-weighted ramp adjustments. Reputation is isolated per domain by default. A complaint on mail.yourdomain.com does not touch tx.yourdomain.com.