What the October 2026 Deadline Actually Means
On 30 October 2026, AWS will end support for Amazon Pinpoint. After that date you will no longer be able to access the Pinpoint console or any Pinpoint resources, including endpoints, segments, campaigns, journeys, and analytics. This is not a soft deprecation or a gradual wind-down. The console disappears, the APIs stop responding, and any workflow that depends on Pinpoint for email stops working entirely. AWS stopped accepting new Pinpoint customers on 20 May 2025, so the platform has been in managed decline for some time. If your team is still relying on it for email sending or deliverability monitoring, the clock is running.
AWS has been clear about where each workload should go. For email, the recommended destination is Amazon Simple Email Service. For engagement features such as segments, campaigns, and journeys, the guidance points toward Amazon Connect and supporting services. SMS, push, and voice channels continue under the AWS End User Messaging brand and require no migration. This article focuses entirely on the email migration path: moving sending infrastructure to SES and, critically, preserving the deliverability visibility that Pinpoint provided.
What Pinpoint Was Doing for Your Email Programme
Before mapping features to their equivalents, it is worth being precise about what Pinpoint actually handled. For many teams it was doing several jobs simultaneously, and conflating them leads to incomplete migrations.
Sending infrastructure. Pinpoint used Amazon SES under the hood for all email delivery. The distinction is that Pinpoint wrapped SES in a higher-level API that handled templating, audience targeting, scheduling, and send orchestration. If you called the Pinpoint API to send an email, SES was the actual delivery engine.
Campaigns and journeys. Pinpoint provided a visual interface for building multi-step email journeys and scheduled campaigns against segmented endpoint lists. This is the layer being retired entirely, and there is no direct like-for-like SES equivalent.
Deliverability dashboard. Pinpoint included a built-in dashboard showing open rates, click rates, bounce rates, and complaint rates at the campaign level. This gave marketing and engineering teams a single place to monitor programme health without building a custom data pipeline.
Event streams. Pinpoint could stream engagement and delivery events to Kinesis, making it possible to feed downstream analytics systems with per-message event data.
Suppression lists. Pinpoint maintained suppression data for bounced and complained addresses, preventing re-sends to damaged recipients.
The Direct SES Equivalents
SES covers several of these capabilities natively, though the configuration is more explicit and requires deliberate setup rather than automatic enablement.
Configuration sets are the SES equivalent of Pinpoint's project-level settings. A configuration set applies rules to outbound messages, controls which IP pool a message routes through, and specifies where sending events are published. Every production email you send through SES should reference a named configuration set.
Event destinations replace Pinpoint's event streams. A configuration set can publish email sending events, including sends, deliveries, opens, clicks, bounces, complaints, rejections, and rendering failures, to Amazon SNS, Amazon CloudWatch, or Amazon Data Firehose. SNS is the most practical starting point: wire a dedicated SNS topic to bounce events and another to complaint events, then subscribe a Lambda function or an SQS queue to process them in near real time.
Account-level suppression list. SES maintains an account-level suppression list that prevents sending to addresses that have previously produced hard bounces or spam complaints. You manage entries via the SES API v2 using the PutSuppressedDestination, GetSuppressedDestination, and DeleteSuppressedDestination operations, or in bulk through the console. This is directly equivalent to the suppression behaviour Pinpoint handled automatically.
Virtual Deliverability Manager (VDM) is SES's answer to a deliverability dashboard. It provides deliverability insights, optimisation recommendations, and detailed dashboards covering bounce rates, complaint rates, open rates, click rates, and delivery rates broken down by sending identity, configuration set, and ISP. VDM also surfaces authentication issues with SPF, DKIM, DMARC, and BIMI through an advisor view. AWS has indicated that SES will offer deliverability dashboard functionality comparable to Pinpoint's before the October 2026 cut-off date.
The Monitoring Gap You Need to Plan For
Here is the part most migration guides gloss over. Raw SES, even with VDM enabled, delivers monitoring data differently from the way Pinpoint presented it. Pinpoint surfaced campaign-level metrics in a dashboard that non-technical stakeholders could read without touching the AWS console. SES publishes event data to destinations you must wire up and query yourself, or visualise through CloudWatch dashboards you build from scratch.
Without additional tooling, you lose several things that Pinpoint gave you automatically: a time-series view of your bounce and complaint rate trends, proactive threshold alerts when either metric approaches a dangerous level, per-domain or per-campaign breakdowns of reputation signals, and a consolidated view that does not require someone to correlate SNS notifications, CloudWatch metrics, and VDM data by hand.
Google and Yahoo's 2024 bulk sender requirements set a spam complaint rate operational ceiling of 0.10 percent, with 0.30 percent as the hard limit at which inbox providers begin blocking or severely degrading delivery. Staying well below those thresholds requires continuous visibility, not periodic manual checks. The monitoring gap that opens when the Pinpoint dashboard disappears is real, and it needs to be filled before cut-over, not after.
Step-by-Step Migration Checklist
1. Audit your current Pinpoint usage
Before touching any configuration, inventory every Pinpoint resource: campaigns, journeys, segments, templates, and event integrations. Export endpoint lists, suppression data, and any analytics reports you need for historical reference. After 30 October 2026, Pinpoint-specific analytics such as open rates by segment and journey completion rates will be gone permanently. Export them now.
2. Verify sending identities in SES
In the SES console, navigate to Verified Identities and create an identity for every domain and address you intend to send from. For domain-level sending, add a domain identity and configure DKIM verification. SES supports Easy DKIM, which automatically rotates 2048-bit RSA keys, so prefer it over manual key management. Confirm that your SPF record includes the SES sending endpoints for your region, and set up a DMARC policy of at least p=none with a reporting address so you can observe alignment before tightening enforcement.
3. Create configuration sets
Create at least one configuration set for transactional email and a separate one for marketing or bulk sends. Separating traffic types into distinct configuration sets lets you monitor reputation signals independently, apply different IP pools, and adjust suppression behaviour per stream without affecting your transactional programme when you troubleshoot a marketing issue.
4. Wire up bounce and complaint SNS topics
Add an SNS event destination to each configuration set. Create separate SNS topics for bounce events and complaint events rather than combining them into one topic, so that downstream consumers can apply different handling logic. Subscribe your processing function, whether Lambda, SQS, or a webhook, to each topic. Your processor should update your application database to suppress future sends to any hard-bounced or complained address, and it should trigger an alert when rates cross your defined thresholds.
5. Migrate suppression lists via the SES API
Export your Pinpoint suppression data and replay it into the SES account-level suppression list using the PutSuppressedDestination API call for each address, specifying the suppression reason as either BOUNCE or COMPLAINT. Do this before you cut over sending, not after. A suppression list that is incomplete at cut-over means you will immediately send to addresses that previously hard-bounced, inflating your bounce rate at precisely the moment your new sending infrastructure is trying to establish a clean reputation signal.
6. Update your sending code
Replace calls to the Pinpoint SendMessages API with calls to the SES v2 SendEmail operation, or switch to SMTP relay using your SES SMTP credentials. Every outbound message must include the ConfigurationSetName parameter so that event publishing and suppression rules apply. If you were using Pinpoint email templates, migrate them to SES templates using the CreateEmailTemplate API, which supports the same Handlebars-style variable substitution syntax.
7. Enable Virtual Deliverability Manager
Enable VDM at the account level from the SES console or via the API. VDM provides breakdown views by sending identity and configuration set, surfaces recommendations for authentication issues, and gives you time-series graphs of your key metrics. Note that VDM carries an additional cost on top of the base SES sending price, so evaluate whether you need it continuously or only during active troubleshooting periods.
Preserving Deliverability During Cut-Over
Switching sending infrastructure mid-flight carries real reputation risk. Inbox providers build trust in sending IP addresses over time. If you move to new IPs without warming them, you may see a temporary increase in spam folder placement even if your list quality is excellent.
If you are moving to SES shared IPs, the warm-up is managed by AWS and is generally transparent for moderate volumes. If you are provisioning dedicated IPs, plan for a four-to-eight-week ramp period during which you gradually increase daily send volume. Start with your most-engaged recipients first, since positive engagement signals such as opens and replies accelerate IP warming. Do not start with bulk or re-engagement sends on a cold IP.
Run Pinpoint and SES in parallel for a short overlap period if your architecture allows it. Route a small percentage of traffic through SES first, monitor the bounce and complaint rates, and increase the proportion only when the metrics are stable. A parallel-run window of one to two weeks is usually sufficient for transactional programmes. Marketing campaigns warrant a longer overlap to observe inbox placement across a full send cycle.
Ensure your DMARC alignment is correct before you switch. A DMARC failure on a new sending IP is harder to recover from than one on an established IP, because inbox providers have no prior positive signal to weigh against it.
Replacing Pinpoint Analytics and Alerting
This is the section that determines whether your migration is truly complete or whether you have simply moved the delivery layer while leaving your team blind to what is happening.
SES event destinations give you the raw data. Turning that data into actionable visibility requires an additional layer. The options are: build a custom pipeline using Lambda, CloudWatch Metrics with custom namespaces, and CloudWatch Alarms; use VDM's built-in dashboard for the metrics it covers; or use a dedicated SES monitoring tool that aggregates event stream data into a deliverability-focused dashboard with pre-built alerting.
The custom-build route is entirely feasible but takes meaningful engineering time to do properly. You need to handle SNS message parsing, aggregate bounce and complaint rates as rolling percentages rather than raw counts, set up alarms with sensible thresholds, and build views that are accessible to non-engineers who need to monitor programme health. Teams that have gone this route typically spend several sprint cycles on the plumbing before the result matches what Pinpoint gave them out of the box.
SES Monitor provides exactly this layer without the custom build. It connects directly to your SES account, ingests event stream data, and presents bounce rate trends, complaint rate trends, open tracking, and per-domain breakdowns in a dashboard designed around deliverability monitoring rather than general AWS observability. Threshold-based alerts notify you when bounce or complaint rates approach the limits that trigger inbox provider penalties, giving you the same proactive posture that Pinpoint's built-in dashboard enabled. For teams focused on a fast, low-risk migration rather than a custom data-engineering project, it is the most direct way to restore the monitoring capability that Pinpoint is removing.
Post-Migration Health Check: Five Metrics to Watch
In the first two weeks after switching sending infrastructure, keep a close eye on these five signals. Anomalies in this window are almost always recoverable if caught early; left undetected, they can cause lasting reputation damage.
Bounce rate. Hard bounces should remain below two percent at all times. A spike in the first few days of operation often indicates that the suppression list migration was incomplete. Cross-reference bouncing addresses against your Pinpoint suppression export.
Complaint rate. Aim to stay well below 0.10 percent to maintain a comfortable margin beneath the threshold at which inbox providers begin acting. A rising complaint rate in the first two weeks typically signals that your unsubscribe mechanism is not working correctly in the new setup, or that recipients cannot easily distinguish your email from unwanted mail.
Delivery rate. Track the ratio of successful deliveries to attempted sends. A delivery rate below 95 percent warrants investigation, particularly if bounces alone do not account for the gap.
DMARC pass rate. Monitor your DMARC aggregate reports during the first fortnight. Alignment failures that were masked by Pinpoint's sending path can surface when you switch to direct SES sending, especially if your From domain differs from your envelope domain.
Open rate trend. Open rates are a proxy for inbox placement. A sudden drop in opens without a corresponding drop in sends suggests your messages are landing in spam folders rather than inboxes, which warrants an immediate review of IP warm-up status and authentication configuration.
Conclusion: Migration Is Straightforward; Monitoring Is Not
The Amazon Pinpoint shutdown is a firm deadline. The practical work of migrating email sending to SES is well-defined: verify identities, build configuration sets, wire up SNS topics for bounce and complaint events, migrate your suppression list, and update your sending code. Most engineering teams can complete the core migration in a focused sprint or two.
The harder problem is the monitoring gap. Pinpoint gave your team a deliverability dashboard without any configuration effort. SES does not. Filling that gap with a custom CloudWatch pipeline takes time your team may not have before October 2026. SES Monitor restores bounce tracking, complaint rate monitoring, open rate visibility, and threshold alerts as soon as you connect it to your SES account, letting you focus migration effort on the sending infrastructure rather than on rebuilding observability from scratch.
Start the migration now, before deadline pressure makes careful execution difficult. Export your Pinpoint data, build your SES configuration sets, and put monitoring in place before you cut over sending traffic. The teams that struggle post-migration are those that moved the sending pipe but left deliverability visibility as a follow-up task that never quite got prioritised.