An AWS SES Skill Can Prepare the Send. It Cannot Own It.

The skill supplies procedure, not message authority

AWS released Amazon SES and End User Messaging agent skills for the AWS MCP Server on September 25, 2026. The launch names Claude Code, Codex, Cursor and Kiro as supported coding-agent environments. The important operational addition is current service guidance at the moment an engineer is configuring or troubleshooting the integration, not a new business right to contact people.

The amazon-ses setup guide describes the skill as guidance for SES setup and troubleshooting. It excludes Mail Manager and receiving workflows. When the agent retrieves it through the AWS MCP Server, it gets the current skill. When a team installs a local copy, that copy must be reinstalled to pick up updates.

That distinction is useful. A current runbook can reduce stale setup advice. It still cannot answer these questions:

• Which business workflow is allowed to send?
• Who owns the decision to contact this recipient?
• Which sender, content and region were approved?
• What should happen when the API outcome is ambiguous?
• Who receives a bounce or complaint and stops the workflow?

Credentials answer who may call AWS. IAM narrows what the caller may do. The application still owns why this exact message may leave the company. This is the same separation as the broader AWS MCP production boundary: a useful capability should arrive inside an operating contract, not become the contract itself.

Bind the exact send envelope before execution

Do not approve a prose request such as “send the renewal notice.” Approve a versioned effect envelope containing the workflow ID, accountable owner, sender, exactly one recipient, subject digest, body digest, AWS Region, configuration set, trace tag and approval digest.

The approval must bind the whole envelope. If personalization, recipient, content or routing changes after review, the digest changes and the send returns to hold. This prevents a valid approval for one message from floating onto another message assembled later.

SES gives IAM policy authors useful outer rails. Its service-specific condition keys include ses:Recipients, ses:FromAddress, ses:FromDisplayName and ses:FeedbackAddress for supported send actions. Use them to constrain the permitted sender and recipient surface. Do not mistake those conditions for content approval. IAM does not know whether the subject and body match the business decision.

Use one recipient per API call. AWS's sending-quota guidance recommends this because quotas count recipients and one invalid recipient can reject a multi-recipient request. It also gives the application a clean map from one approved effect to one SES receipt. If the workflow needs ten recipients, create ten independently authorized effects rather than one opaque batch.

Before the first production call, record whether the SES account is still in the sandbox. The production-access guide says a sandbox account may send only to verified recipients or the mailbox simulator and is limited to 200 messages per 24 hours at one message per second. These are account constraints to observe, not throughput targets.

A timeout is an uncertain effect

An agent should never turn an ambiguous transport outcome into an automatic second email.

The documented SendEmail v2 request schema has fields for content, destination, sender, configuration set, tags, endpoint, feedback address, list management, reply-to addresses and tenant data. It does not document a client token or idempotency field. That absence is an inference from the current schema, not a claim about SES internals.

If the client times out without a MessageId, the application does not know whether SES accepted the first call. Route the effect to uncertain. Do not blind-retry. A person or a separately defined reconciliation process must decide whether enough authoritative evidence exists to send again.

This is the same failure shape as an ambiguous CRM mutation. The idempotent CRM write pattern reserves one business effect before the provider call, separates intent from provider acceptance, and refuses to call a timeout either success or failure.

The retained reference gate makes that route explicit:

if (input.approvedEnvelopeDigest !== input.envelopeDigest) {
  return { route: "hold", reason: "approved-envelope-changed" };
}

if (input.recipients.length !== 1) {
  return { route: "hold", reason: "one-recipient-per-send-required" };
}

if (input.transportOutcome === "timeout" && !input.messageId) {
  return {
    route: "uncertain",
    reason: "send-outcome-ambiguous-no-blind-retry",
  };
}

A stable internal effect ID still matters. It joins approval, call attempt, MessageId and later events. It does not magically make the SES API idempotent.

MessageId means accepted, not delivered

An HTTP 200 response with a MessageId proves that SES accepted the message request. It does not prove that a recipient server accepted the email, that a person saw it, or that the business workflow succeeded.

AWS says a message can be accepted and still not be sent, including when an attachment contains a virus or template personalization is invalid. Store the returned MessageId with your internal effect ID immediately. AWS's notification troubleshooting guide recommends maintaining your own mapping because SES does not retain a customer's custom message identifier. Complaint notifications may also redact recipient information, which makes the stored join more important.

Apply a configuration set and a trace tag at send time. SES event publishing can then report sends, deliveries, bounces, complaints, rejections, rendering failures, delivery delays and other events to a configured destination. Join each event on the SES MessageId and the trace tag you already bound to the effect.

Do not assume event arrival order. The notification contract allows notification records to be grouped or split. Consumers therefore need duplicate-safe, order-independent state reduction. In the reference gate, a complaint wins even if a delivery event arrived first. A bounce, reject or rendering failure terminates as failed. A delivery delay remains visible as delayed rather than being rounded into success.

That state machine preserves three different facts:

1. Intent: the company approved one exact message.
2. Acceptance: SES returned a MessageId for the request.
3. Outcome: event evidence later described delivery, delay, failure or complaint.

For important workflows, “delivered” may still be only provider evidence. A renewal process might require an account update, response or human follow-up before the business task is accepted.

Release with simulator evidence and a complaint owner

Use the SES mailbox simulator to exercise the operating contract without inventing a performance result. AWS documents simulator addresses for success, bounce, out-of-office, complaint and suppression-list cases. Simulator messages do not count against the daily sending quota or reputation metrics, but AWS says they are billed and still subject to the maximum sending rate.

The local release artifact for this article passes 22 dependency-free cases. It covers a missing owner, multiple recipients, changed approval digest, sender and recipient policy failures, unknown sandbox state, simulator eligibility, unobserved quota, ambiguous timeout, API rejection, MessageId acceptance, mismatched events, delivery, bounce, rendering failure, delay, complaint precedence and a complete release gate. These are control-flow tests, not SES delivery benchmarks or client results.

Before production recipients, require all of the following:

• a named workflow owner and complaint owner;
• a recorded skill source, so reviewers know whether guidance was current or locally copied;
• exact-envelope approval and separate IAM sender and recipient tests;
• one recipient per send;
• observed sandbox state and current quota;
• a configuration set, event destination and trace-tag join;
• durable mapping from the business effect to the SES MessageId;
• an explicit no-blind-retry rule for timeouts;
• simulator cases for success, bounce, complaint and suppression;
• duplicate and out-of-order event tests;
• a stop rule when complaint, divergence or unexplained uncertainty exceeds the owner's boundary.

The agent skill earns its place by keeping service procedure current. The application earns the right to send by binding authority before the call and reconciling evidence afterward.

Frequently asked questions