On this page · 8 sections
Summary. On 21 August 2026 AWS added 2 tracking override parameters — ClickTrackingEnabled and OpenTrackingEnabled — to the SES SendEmail and SendBulkEmail APIs, at no additional cost, in all AWS Regions where SES runs. AWS cites GDPR and CNIL guidance, but the API reference states the override applies to every message in a SendBulkEmail request, so honouring France's CNIL recommendation of 14 April 2026 (and its 22 July 2026 FAQ) still requires splitting a campaign into 2 or 4 separate calls by consent state. Both fields are typed String with values ENABLED or DISABLED, not booleans, and 4 separate settings now decide whether a message is tracked.
Amazon SES added open and click tracking override parameters to SendEmail and SendBulkEmail on 21 August 2026. AWS frames the feature around consent: it says the overrides simplify "how you honor recipient-level tracking consent" and calls it useful for senders "that must respect per-recipient consent choices to meet data protection requirements such as GDPR and CNIL guidance."
Read the API reference next to that sentence and a gap opens up. For SendBulkEmail, AWS documents ConfigurationOverrides as an object whose settings "apply to every message in the request." One override, one value, every recipient in that call. If your recipients have different consent states — and under the CNIL recommendation that is the normal case, not the edge case — the one API built for high-volume sending cannot express them in a single request.
The feature is real and it removes genuine work. It just does not remove the work the launch post implies it removes.
What actually shipped
The new parameter is ConfigurationOverrides.Tracking, and it carries two fields: ClickTrackingEnabled and OpenTrackingEnabled. Both appear on SendEmail (POST /v2/email/outbound-emails) and on SendBulkEmail (POST /v2/email/outbound-bulk-emails).
Neither field is a boolean. AWS types both as String with valid values ENABLED and DISABLED. Teams that guess true/false from the field names will find out at runtime. Omit a field and SES falls back to whatever would otherwise apply.
The semantics are absolute rather than advisory. DISABLED means SES does not track "even when your account-level or configuration set settings enable click tracking," and for clicks specifically, SES "doesn't rewrite the links in the message." ENABLED works the other way — SES tracks "even when your account-level and configuration set settings don't enable" it. The override wins against both lower layers.
AWS says the capability is available in all AWS Regions where SES is available, at no additional cost.
The bulk-send limit is the story
SendEmail sends one message. Put a DISABLED override on it and you have honoured one recipient's refusal exactly. That path works as advertised.
SendBulkEmail is the one you use for a campaign, and it is where the promise thins out. AWS's own wording for the bulk operation is that the overrides "apply to every message in the request." The per-destination object in a bulk call — BulkEmailEntries — carries Destination, ReplacementEmailContent, ReplacementHeaders and ReplacementTags. It does not carry a tracking override. There is no per-entry hook.
So the compliant pattern for a mixed audience is not "one bulk send with overrides." It is: partition your recipient list by consent state, then issue at least two bulk calls — one with OpenTrackingEnabled: DISABLED and ClickTrackingEnabled: DISABLED, one without overrides or with them ENABLED. If you treat open consent and click consent as separate decisions, which the CNIL material gives you reason to do, you are partitioning into four buckets, not two.
That is still better than the pre-21-August world, where the same partitioning required a distinct configuration set for each combination of settings, plus the IAM, event-destination and lifecycle overhead each one drags along. The saving is real. The saving is in configuration-set sprawl, not in send-time logic.
The second thing the launch post does not mention
Turning tracking on with an override does not give you the events.
The reference is explicit: "Enabling open or click tracking with an override doesn't create an event destination." SES records the resulting opens and clicks in Virtual Deliverability Manager, where you can see them in VDM metrics and Message Insights. To receive those events at a destination you own, AWS says the configuration set the message uses must have an event destination that publishes open and click events.
This matters because it undercuts the "reduce configuration overhead" framing in the opposite direction. You cannot delete your configuration sets and drive everything from send-time overrides. The configuration set remains the only place event routing lives.
Counting properly, four inputs now decide whether a given SES message is tracked:
- the account-level
EngagementMetricssetting, set throughPutAccountVdmAttributes;
- the configuration set's
EngagementMetricssetting, set throughPutConfigurationSetVdmOptions;
- whether that configuration set has an event destination whose
MatchingEventTypesincludeOPENorCLICK;
- and now the per-request override, which beats the first two.
If you are debugging "why is this message still tracked," you have four places to look, and the newest one is invisible in your infrastructure-as-code because it lives in application send logic.
Why AWS cited CNIL by name
The regulatory pressure behind this is specific and dated. France's CNIL published the final version of its recommendation on tracking pixels in emails on 14 April 2026, after a public consultation, and followed it with a professionals' FAQ on 22 July 2026.
The recommendation treats the email tracking pixel — a 1×1 image whose filename carries a user identifier — under Article 82 of the French Data Protection Act, the same provision that governs cookies. It applies to every organisation, private or public, using tracking pixels in emails, and to the technical providers they use. CNIL says it was prompted in part by a rising number of complaints on the subject.
Two details from the July FAQ are directly relevant to how you use the new SES parameters.
Tracking links are not the same question as tracking pixels. CNIL says tracking links ("liens traçants") are not directly covered by the recommendation, but that operators using them must still comply with Article 82 alongside the GDPR, and points to EDPB guidelines 02/2023. SES click tracking works by rewriting links — so ClickTrackingEnabled and OpenTrackingEnabled are not two switches on one legal question. They are two switches on two.
"My vendor handles consent" is not a defence. The FAQ says a party that delegates consent collection cannot rely on a contract clause alone to prove consent; it must be able to demonstrate that consent was validly collected on its behalf, which CNIL suggests may mean audits. It also distinguishes providers acting as processors under Article 28 from providers that use the pixels for their own purposes, who may be joint controllers under Article 26. Sending through SES does not move the burden of proof to AWS.
Deliverability pixels are not automatically exempt. The FAQ says pixels used for deliverability must meet all the conditions set out in the recommendation to be exempt, and that a controller relying on the exemption has to show the operations stay limited to what is strictly necessary.
Teams already building consent plumbing for India's DPDP framework will recognise the shape of the problem — see our notes on DPDP consent manager readiness and on backfilling consent across legacy data.
What to change
If you maintain configuration sets purely to vary tracking, collapse them. That was the intended win and it holds. Keep the sets you need for event destinations, dedicated IPs, tenants and suppression; retire the ones whose only job was a tracking permutation.
Do not change your campaign sender to a single bulk call with an override and call it consent compliance. Segment before you send. Consent state has to be a partition key on your send batching, not a field you hope the API reads.
Send strings. "ENABLED" and "DISABLED", not true and false. Add a type-level guard so the value never reaches SES as a boolean.
Check whether you still get your events. If any of your alerting or attribution reads open and click events from SNS or Firehose, an override that flips tracking on will not feed it. The event destination on the configuration set is still the source.
Watch the size limits that predate this launch. With click tracking on, SES rewrites links to a redirect server, and the total size of headers including cookies on requests to that server must not exceed 8,192 bytes or the request returns a 400. With open tracking, the {{ses:openTracker}} placeholder lets you move the pixel out of the footer, but SES removes any placeholder beyond the first at send time, and more than one in a template returns a 400 BadRequestException.
Price context, unchanged by this launch. SES lists Essentials at $0.16 per 1,000 emails for the first 10 million per month with no per-account monthly fee, Pro at $0.22 per 1,000 plus $105 per account per region per month, and Enterprise at $0.23 per 1,000 plus $500. AWS says new SES accounts, and account-and-region combinations with no metered activity since 1 June 2025, start on Essentials from 21 July 2026. The tracking override adds nothing to any of those lines — see our SES pricing plan comparison for the tier arithmetic.
What is still unknown
AWS has not said whether per-entry tracking overrides will come to BulkEmailEntries. Nothing in the current reference suggests it is planned, and the wording — overrides "apply to every message in the request" — reads as a deliberate design choice rather than a first-release limitation.
It is also unclear how the override interacts with SES tenants, which appear in both SendEmail and SendBulkEmail as TenantName. The reference lists account level, configuration set level and the new override as the inputs to tracking behaviour; it does not place tenants in that hierarchy.
FAQ
References
- Amazon SES now supports open and click tracking override parameters — AWS What's New, 21 August 2026
_Last updated: 22 August 2026._
