The pixel is not the email: SES per-send tracking, and why a leaked SaaS key is not your AWS
Amazon SES now allows per-send tracking overrides for GDPR compliance. Leaked SMTP/API keys are user credentials, not provider breaches.
Two email infrastructure events landed in the same week, both material, neither quite what the headlines suggested.
On August 21, Amazon SES added per-send tracking overrides — the ability to disable open and click tracking for a single email, regardless of the configuration set. On August 29, threat intelligence firm Brinztech published an alert about actor acethegreat marketing SMTP credentials and API keys for SES, SendGrid, Resend, and Postmark users on a dark web forum.
The first is a privacy feature that changes how you honor consent. The second is a credential leak from customer applications, not a breach of the providers themselves.
Both are worth understanding, because tracking pixels are now regulated separately from the emails that carry them, and because “leaked API keys” does not mean what it sounds like when the keys were never the provider’s to protect.
Tracking pixels and terminal access: what CNIL and Garante actually said
A tracking pixel is the 1×1 transparent image embedded in HTML email that reports when the email was opened. When your mail client requests the image, the server logs your IP address, the timestamp, and whatever identifier was embedded in the image URL. That log entry becomes “Bob opened this email at 2:47 PM.”
Click tracking is similar: every link in the email is rewritten to pass through the provider’s redirect server, which logs the click before sending you to the real destination.
Both techniques have been standard practice in email marketing since the early 2000s. Both are now explicitly regulated by European data protection authorities, separately from consent to receive the email itself.
CNIL: tracking consent must be separate
On April 14, 2026, France’s Commission Nationale de l’Informatique et des Libertés (CNIL) published guidance treating email tracking pixels as terminal access under Article 5(3) of the ePrivacy Directive. The practical requirement: consent for tracking must be separate from consent to receive marketing emails.
A subscriber can agree to receive your newsletter and decline to be tracked. You are required to honor both preferences. They cannot unsubscribe from tracking — they can only unsubscribe from the emails, or receive the emails without tracking.
CNIL’s position is that open and click tracking accesses the recipient’s device (their mail client and browser) to collect data not strictly necessary to deliver the message. That makes it terminal access, and terminal access requires consent under ePrivacy.
Garante: tracking can be bundled, but withdrawal must be granular
On April 17, 2026, Italy’s Garante per la Protezione dei Dati Personali (Provision 284) took a slightly different line. You may bundle tracking consent with marketing consent if the bundling is presented neutrally and the subscriber understands they are agreeing to both. But withdrawal must be granular: the recipient must be able to stop tracking while continuing to receive the emails.
The practical result is the same as CNIL. Whether you collect tracking consent separately at signup or bundle it and allow separate withdrawal later, you end up with subscribers in four states:
| Marketing emails | Tracking | What you send |
|---|---|---|
| Yes | Yes | Email with tracking |
| Yes | No | Email without tracking |
| No | Yes | (contradictory — treat as No/No) |
| No | No | Nothing |
Most platforms implement this with two checkboxes at signup or two toggles in the preference center. The technical requirement downstream is that you must be able to send an email to a consenting recipient without the tracking pixel and without rewriting the links, even if your default configuration set has tracking enabled.
Why this is distinct from consent to send
It is worth pausing on the structure of the requirement, because it is not obvious if you are used to U.S. email compliance (CAN-SPAM) or transactional-only sending.
Under CAN-SPAM, the primary obligation is to honor unsubscribe requests. You cannot send marketing email to someone who opted out. There is no separate consent requirement for tracking because CAN-SPAM does not regulate tracking.
Under GDPR and ePrivacy, consent to receive marketing email and consent to be tracked are two separate legal bases. The first is usually legitimate interest or consent under GDPR Article 6. The second is consent under ePrivacy Article 5(3), and the two are not interchangeable.
A recipient who withdraws tracking consent but not marketing consent must continue to receive the emails, without the tracking. The requirement is technically awkward — most email platforms default to “all emails from this configuration set are tracked” — but legally it is the same category of obligation as “honor the unsubscribe.” It is not optional and it is not best-effort. You must be able to send the untracked email.
For a full comparison of CNIL and Garante guidance, see Lewis Silkin’s analysis from June 2026. The Garante provision itself is available in Italian here.
SES per-send tracking overrides: what changed and why it matters
Before August 21, 2026, Amazon SES tracking was controlled at the configuration set level. If your configuration set had open and click tracking enabled, every email sent through that configuration set was tracked. If it was disabled, none were tracked.
To honor granular tracking consent, you had two options: create multiple configuration sets (one with tracking, one without) and route each send to the correct set based on the recipient’s preferences, or disable SES tracking entirely and implement your own pixel and link-rewriting logic in your application code.
Both options worked. Neither was simple.
On August 21, SES added ConfigurationOverrides.Tracking to the SendEmail and SendBulkEmail API calls. You can now pass OpenTrackingEnabled: DISABLED and ClickTrackingEnabled: DISABLED to suppress tracking for that specific send, regardless of what the configuration set says.
AWS describes this as useful for senders that must respect per-recipient consent choices to meet data protection requirements such as GDPR and CNIL guidance. The tracking overrides apply per request and take precedence over the tracking behavior defined in the associated configuration set, giving you fine-grained control without changing your existing configuration set structure.
What this looks like in practice
The SDK signature for SendEmail now includes an optional ConfigurationSetName and an optional ConfigurationOverrides block. The Tracking field inside ConfigurationOverrides has two boolean flags: OpenTrackingEnabled and ClickTrackingEnabled, each of which can be set to ENABLED or DISABLED.
If you omit the Tracking block, the send uses the configuration set’s defaults. If you include it, the override wins.
Example: your default configuration set has both open and click tracking enabled. Recipient A has consented to tracking. Recipient B has not. You send to both using the same configuration set, but you pass OpenTrackingEnabled: DISABLED and ClickTrackingEnabled: DISABLED in the request body when sending to B.
Recipient A receives the email with the tracking pixel and rewritten links. Recipient B receives the same email content, but the pixel is omitted and the links are not rewritten. One API call per recipient, one configuration set, no routing logic.
SendBulkEmail works the same way, except the override is per row in the BulkEmailEntries array. That means a single bulk send can mix tracked and untracked emails based on per-recipient preferences — no need to split the batch.
Why this matters more than it sounds
Per-send overrides are not a feature you notice until you are handling tracking consent. Once you are handling it, they are the difference between “write a router that picks the right configuration set based on a lookup table” and “set a flag in the send request.”
The cost is the same — SES does not charge extra for overrides. The deliverability surface is the same — you are using the same domain, the same configuration set, the same IP pool (shared or dedicated). The only thing that changes is whether AWS rewrites the HTML before sending.
The practical impact: you can now run a single SES sending path, with a single configuration set, and honor granular tracking consent by reading a flag from your database and passing it to the send API. The alternative was to maintain parallel configuration sets or move tracking into your own application code, and both of those are more operational surface area than a per-send flag.
This is not a theoretical feature. If you send marketing email to EU recipients, CNIL and Garante guidance applies to you, and you are now required to be able to send untracked email to recipients who declined tracking. SES per-send overrides are how you do that without restructuring your sending logic.
Leaked SMTP credentials and API keys: what acethegreat was actually selling
On August 29, 2026, Brinztech published an alert about dark web actor acethegreat listing “valid SMTP and API credentials for major email delivery platforms” on the forum exploit.in. The platforms named: Amazon SES, SendGrid, Resend, and Postmark.
The headline reads like a breach of the providers. It was not. The credentials listed were stolen customer credentials — API keys and SMTP users extracted from customer applications, not from AWS, Twilio, Resend, or Postmark infrastructure.
This is not speculation. Brinztech describes the listing as “pre-tested credentials,” meaning acethegreat verified they worked before posting them. If AWS had been breached, AWS would know and the credentials would be rotated before they reached a forum listing. The fact that they were still valid when tested means they were extracted from customer environments that had not yet detected the compromise.
The distinction matters, because the response is different. A provider breach means you wait for the provider to tell you whether your account was affected, and the provider rotates credentials on your behalf. A customer credential leak means you are responsible for finding the leak, rotating the credentials, and auditing where they were used.
How customer email credentials leak
Email API keys and SMTP passwords leak the same way every other secret leaks: they are committed to public GitHub repositories, they are logged in plain text, they are stored in environment variables on compromised servers, they are printed in error messages, they are left in staging databases that get exposed, or they are extracted by malware from developer machines.
One documented example from 2026: CVE-2026-4020, a vulnerability in the WordPress plugin Gravity SMTP. The plugin stored SES, Resend, and other provider credentials in the WordPress database and exposed them to unauthenticated GET requests. Any WordPress site running the affected version (prior to the patch) had its email credentials readable by anyone who knew the URL pattern.
CVE-2026-4020 is a separate incident from the acethegreat listing — there is no public evidence they are related — but it illustrates the class of problem. The credentials were not leaked by AWS or Resend. They were leaked by a WordPress plugin that stored them insecurely. The fix was not “contact AWS.” The fix was “patch the plugin, rotate the credentials, and audit the access logs to see if anyone used them.”
This is not hypothetical. If you store email API keys in environment variables, in database fields, or in code, and any of those are exposed — through a web vulnerability, a server compromise, a public Git commit, or a developer laptop that gets phished — the credentials are gone. They are in logs, in breach databases, and eventually on forums like exploit.in.
Why a leaked SaaS API key is different from a leaked SES credential
The acethegreat listing included credentials for both SaaS email APIs (Resend, SendGrid, Postmark) and for Amazon SES. From a customer’s perspective these sound equivalent — a leaked key is a leaked key — but the infrastructure they grant access to is not the same.
A Resend API key, a SendGrid API key, or a Postmark API key is a credential that grants access to the vendor’s infrastructure. The key lives in Resend’s system, or Twilio’s system, or Postmark’s system. It is scoped to your Resend account, or your SendGrid subuser, or your Postmark server, but the infrastructure it touches is the vendor’s cloud. You cannot SSH into the server that processes your send requests. You cannot read the vendor’s logs. You cannot set IAM policies on the API. The key is a remote control for infrastructure you do not operate.
An Amazon SES IAM access key or SMTP user is a credential that grants access to your AWS account. The key is scoped to your account and to whatever IAM policy you attached to the user. The infrastructure it touches — the SES service in your account, the SNS topics that receive bounce notifications, the CloudWatch logs that record API calls, the configuration sets that control sending behavior — is yours. It is not AWS’s shared infrastructure. It is the SES service running in your account, on your bill, governed by your IAM policies.
The difference shows up in four places:
| SaaS API key (Resend, SendGrid, Postmark) | SES IAM user or SMTP credential | |
|---|---|---|
| Who owns the infrastructure | The vendor | Your AWS account |
| Who can rotate the credential | You, via the vendor’s dashboard or API | You, via IAM or SES console |
| What the credential can access | Only the vendor’s email API, scoped to your account | SES in your AWS account, plus any other AWS service the IAM policy allows |
| Audit trail | Vendor’s logs, accessible via dashboard or API | CloudTrail logs in your account, queryable via SQL or shipped to your SIEM |
The blast radius is still bad in both cases. A leaked Resend key can send spam as you, burn your domain reputation, and exhaust your plan limits. A leaked SES key can do the same, and if the IAM policy is too broad, it can also do things outside of SES — start EC2 instances, read S3 buckets, whatever the policy allowed.
But the ownership of the problem is different. A leaked SaaS API key is a credential for infrastructure you were renting. You cannot audit the access logs without asking the vendor. You cannot set up alerting on unusual send patterns unless the vendor’s API exposes the metrics you need. You cannot revoke the key from anything except the vendor’s UI or API.
A leaked SES key is a credential for your infrastructure. You can see every API call in CloudTrail. You can set up CloudWatch alarms on send volume, bounces, complaints, and API throttling. You can revoke the key instantly via IAM, and you can verify it is revoked by checking the IAM policy.
This is not a claim that SES is immune to credential theft. It is not. The claim is that the boundary between “my infrastructure” and “the vendor’s infrastructure” changes where the observability and control surfaces live. When the credentials are for your AWS account, the tools to detect and respond to the leak are in your AWS account. When the credentials are for a vendor’s API, the tools are the vendor’s tools, and your access to them depends on what the vendor exposes.
Rotation and the difference between credentials and accounts
One more distinction worth making: a leaked API key is not the same as a compromised account.
If someone has your Resend API key, they can send email as you, but they cannot log into your Resend dashboard, change your DNS settings, or read your suppression list. The key is scoped to the send API. To access the account itself, they would need your login credentials, your SSO session, or access to your password reset email.
If someone has your SES IAM access key, they can call the SES API with whatever permissions the IAM policy granted. If the policy is scoped to ses:SendEmail and nothing else, that is all they can do. If the policy includes ses:* or iam:* or ec2:*, they can do those things too. IAM policies control the scope of damage.
The practical lesson: when you create an IAM user or access key for SES, scope it. Grant ses:SendEmail, ses:SendBulkEmail, and ses:SendRawEmail. Do not grant ses:* unless you need the user to change configuration sets or manage suppression lists. Do not grant permissions outside of SES unless the application actually needs them.
The same principle applies to SaaS API keys. Resend, SendGrid, and Postmark all support scoped API keys — send-only keys that cannot access account settings or suppression lists. Use them. If a key leaks and it is scoped to send-only, the damage is limited to reputation and bill exhaustion. If it is scoped to full account access, the damage includes everything in your account.
Credential hygiene does not change just because the infrastructure is yours
None of this is new advice. Do not commit secrets to Git. Do not log API keys. Rotate credentials after a suspected compromise. Use secret management tools. Scope permissions to the minimum required.
The reason to revisit it in the context of SES and leaked SaaS keys is that “running on your own AWS” sounds like it should be more secure, and it is not automatically more secure. It is more observable and more controllable, but the credentials still leak in the same ways, and the responsibility to protect them is still yours.
The advantage of owning the infrastructure is that when something goes wrong, you have the tools to see it and stop it. CloudTrail tells you what the leaked key was used for. CloudWatch tells you if the send volume spiked. IAM lets you revoke the key immediately without waiting for a support ticket. You are not dependent on a vendor’s incident response timeline or their willingness to share forensic details.
The disadvantage is that you are also responsible for setting up those tools in the first place. If you do not have CloudWatch alarms on SES bounce rate and send volume, you will not know a leaked key is being used until your domain reputation tanks or AWS throttles you. If you do not enable CloudTrail, you will not have an audit log to review.
SaaS providers run those monitors on your behalf because it is in their interest to detect abuse before it spreads to other customers on the shared infrastructure. When you run SES in your own account, the shared infrastructure is not a factor — your sends do not affect anyone else’s reputation — but the monitoring is also not automatic. You have to build it.
This is not a reason to avoid SES. It is a reason to treat “run it on your own AWS” as “operate email infrastructure” rather than “pay AWS instead of Resend and everything else is the same.” The cost is lower, the control is greater, and the operational surface area is yours.
What these two changes mean together
SES per-send tracking overrides and the acethegreat credential leak are not connected except by timing. One is a feature that makes privacy compliance easier. The other is a reminder that credentials leak from customer applications, not from the providers, and the remediation is your problem.
But they point at the same underlying question: who operates the infrastructure, and where does your operational responsibility start and end?
When you use Resend or SendGrid or Postmark, tracking configuration is their feature and credential security is their incident response process. You interact with both through an API or a dashboard. You are not managing configuration sets, you are not monitoring CloudTrail, and you are not setting IAM policies. The trade is that you also do not own the event data, you do not control the suppression list, and you cannot see the forensic logs when something goes wrong.
When you use SES, tracking configuration is an API parameter you control, and credential security is your IAM policy, your secret rotation process, and your CloudWatch alarms. You manage configuration sets, you monitor CloudTrail, and you set IAM policies. The trade is that you own the event pipeline, you control the suppression list, and you can query the audit logs directly when something goes wrong.
Neither model is universally better. The question is whether you want to operate the infrastructure or pay someone else to do it, and whether you want the visibility and control that comes with ownership or the simplicity that comes with renting.
Resend vs Amazon SES: cost, lock-in, and when to send from your own AWS compares the two models in detail. What it actually costs to send 500,000 emails from your own AWS breaks down the full bill line by line. This post is about two specific infrastructure changes — one that makes compliance easier, one that reminds you whose credentials are whose — and what they tell you about where the responsibility boundary sits.
If you are handling EU recipients and GDPR applies to you, per-send tracking overrides are now the simplest way to honor granular tracking consent without maintaining multiple configuration sets. If you are running email infrastructure on your own AWS, credential leaks are your problem to detect and rotate, and the advantage of owning the infrastructure is that you have the tools to do it without waiting for a vendor.
Selva Mail is a licensed email platform that runs on your AWS account and sends through your SES. It handles suppression, bounce processing, and event webhooks so you get SES pricing without building the infrastructure yourself. One-time license, $497. See what’s included.
