SES vs SESv2 – Inbound Email / Receipt Rules Support

[Arun-kumar002]

Hi team,

In our application, we initially used the @aws-sdk/client-ses package for sending emails. Later, we migrated to @aws-sdk/client-sesv2 since it is recommended for email sending and provides better APIs for that use case. At this point, we are using SESv2 exclusively for sending emails.

Now we are building a feature to receive inbound emails using Amazon SES. For inbound email configuration, we currently rely on the following APIs, which are available only in @aws-sdk/client-ses:
const { CreateReceiptRuleCommand, DescribeReceiptRuleSetCommand, CreateReceiptRuleSetCommand, SetActiveReceiptRuleSetCommand, } = require("@aws-sdk/client-ses");
These receipt rule–related APIs are not available in @aws-sdk/client-sesv2.

Questions:

1. Is it the recommended approach to use both client-ses and client-sesv2 together—SESv2 for sending emails and SES (v1) for inbound email/receipt rules?
2. Are there any plans to add receipt rule / inbound email APIs to client-sesv2 in the future?
3. If not, is client-ses expected to remain the official and long-term solution for inbound email configuration?

Any guidance or best practices around this would be very helpful.
Thanks in advance!

[NikanEidi]

Hi @Arun-kumar002,

I've double-checked the current AWS SDK v3 architecture, and your observation is correct. Here is the verified technical breakdown for your questions:

1. Is it the recommended approach to use both?

Yes. Currently, @aws-sdk/client-sesv2 is a specialized client designed for modern Outbound workflows (Sending, Configuration Sets, Virtual Deliverability Manager, etc.). However, Inbound Email / Receipt Rule management is still part of the original SES control plane. Since these actions are not exposed in the SESv2 API, using both @aws-sdk/client-ses (for inbound) and @aws-sdk/client-sesv2 (for outbound) is the standard and only way to handle this in JS SDK v3.

2. Are there plans to add these to SESv2?

As of now, there is no official roadmap or public announcement from AWS to port Receipt Rule APIs to the V2 client. SESv2 was built to provide a cleaner interface for the most common sending tasks, while legacy features remain in the V1-based client.

3. Long-term support for client-ses

@aws-sdk/client-ses is expected to remain the official solution for Receipt Rules for the foreseeable future. AWS keeps these clients active specifically because many core service features (like Inbound processing) rely on the original API structures.

Best Practice Implementation:

You can cleanly manage this by exporting both clients from a central configuration file:

import { SESClient } from "@aws-sdk/client-ses";
import { SESv2Client } from "@aws-sdk/client-sesv2";

const config = { region: "us-east-1" };

// Dedicated for Inbound/Receipt Rules
export const inboundClient = new SESClient(config);

// Dedicated for Outbound/Sending
export const outboundClient = new SESv2Client(config);

Hope this helps!
‍‍‍‍‍‍

[MukundaKatta]

The receipt-rules APIs were intentionally left out of SESv2 — AWS decided inbound-email plane stays on v1 for now since it has a different scaling story. Recommended pattern: use @aws-sdk/client-ses for the rules and rule-sets, and @aws-sdk/client-sesv2 for send-side. Having both clients in the same project is supported and doesn't duplicate the request signer or transport much. AWS has no public plan to migrate inbound to v2.