The complaint visibility gap in Amazon SES
If you send email through Amazon SES, you already have access to complaint events via Amazon SNS. When a recipient at Yahoo, Comcast, or another participating mailbox provider marks your message as spam, an Abuse Reporting Format (ARF) notification arrives in your SNS topic within minutes, and your SES complaint rate metric ticks upward. That feedback loop is well understood, well documented, and straightforward to act upon.
Gmail is a different story. It is the dominant consumer mailbox provider worldwide, yet it contributes nothing to the SES complaint event stream. Your SES dashboard can show a clean 0.05% complaint rate while Gmail is quietly filtering a significant portion of your messages into spam, and you would have no direct signal from SES to tell you so. The two numbers measure fundamentally different populations, so they routinely tell different stories.
Closing that blind spot requires two things working together: the Gmail Feedback Loop (FBL) via Google Postmaster Tools, and correctly configured Feedback-ID headers in your outbound SES messages. This article covers every step, from understanding why Gmail works differently, to writing the code that injects custom identifiers, to reading the resulting complaint data and acting on it.
How Gmail complaint feedback works differently
Most mailbox providers that operate feedback loops send individual ARF complaint messages back to the sender. Each report identifies one recipient and one message, which means you can immediately suppress that address. Gmail deliberately does not do this. The reason is privacy: Gmail does not want senders to confirm which specific addresses reported them as spam and then use that information for tracking or retaliation.
Instead, Gmail aggregates complaint signals and exposes them as statistical data inside Google Postmaster Tools. There are no individual ARF events sent to SES from Gmail. What you receive is a daily spam rate figure for your sending domain, and, if you have configured the Feedback-ID header correctly, a campaign-level breakdown inside the Postmaster Tools FBL dashboard. The data covers only @gmail.com recipients, not Google Workspace accounts on custom domains.
This aggregate-only design means the Gmail FBL is useful for diagnosing which campaign or product line is generating elevated complaint rates, but it cannot tell you which individual addresses to suppress. That distinction shapes everything about how you build your workflow.
What the Feedback-ID header is and why it matters
The Feedback-ID is an email message header that Gmail uses to associate complaint signals with the sender who generated them. The header follows a structured format: up to three optional identifier fields separated by colons, followed by a mandatory SenderId field. The full form looks like this:
Feedback-ID: a:b:c:SenderID
The three optional fields, referred to as identifiers a, b, and c, can carry any value you choose, such as a campaign name, a product line, or a customer segment. The SenderId is a mandatory stable value of between five and fifteen characters that uniquely identifies the sender. Gmail aggregates complaint data independently for each identifier, so a spike in complaints against a particular value of identifier a will be visible in Postmaster Tools even if the overall domain rate remains acceptable.
To prevent spoofing, the email must be DKIM-signed by a domain that you own or control, and that same domain must be registered and verified in Google Postmaster Tools. If either condition is not met, Gmail will not attribute the FBL data to your account and the campaign-level breakdown will not appear. Google also requires that each message carries only one Feedback-ID header, and that the sending IPs are published in the SPF records of your signing domain and have valid PTR records.
How Amazon SES auto-generates the Feedback-ID
SES automatically adds a Feedback-ID header to every message it sends. You do not need to do anything to enable this basic behaviour. The auto-generated header contains an SES-internal identifier that SES uses to collect complaint information, and a static trailing value of "AmazonSES" that identifies the sending platform. The c field and the SenderId remain under SES control and cannot be overridden.
A default SES-generated Feedback-ID looks roughly like this:
Feedback-ID: [SESInternalID]:[AccountRegionID]:AmazonSES
This default header gives Google enough information to attribute complaint data to a verified domain, and it allows Postmaster Tools to display your overall domain-level spam rate. However, all of your messages, regardless of whether they come from a weekly newsletter, a transactional trigger, a re-engagement campaign, or a separate business unit, are grouped under the same SES-level identifier. You have no way to distinguish which campaign is causing a spike.
Why the default Feedback-ID is not granular enough
The problem with account-level granularity is that it hides the signal inside the noise. Suppose you send three campaign types: a high-volume promotional newsletter, a behavioural trigger series, and a cart-abandonment sequence. If your overall spam rate climbs above Google's recommended threshold of 0.10%, the Postmaster Tools domain dashboard tells you there is a problem, but not which of those three streams is responsible. You are forced to investigate all of them simultaneously, and suppression decisions become guesswork.
If you operate multiple products or clients under a single SES account, the situation is worse still: you cannot tell which product is responsible for a reputation dip. The default Feedback-ID header gives you a smoke alarm but not the location of the fire.
Setting custom Feedback-ID values in SES
In June 2024, AWS released a feature that allows SES senders to inject up to two custom values into the Feedback-ID header using message tags named ses:feedback-id-a and ses:feedback-id-b. SES places these values into the a and b fields of the Feedback-ID header respectively, so they appear as the first and second identifiers that Google's FBL system reads and aggregates. The remaining fields stay under SES control and cannot be overridden.
The resulting header structure when both tags are set looks like this:
Feedback-ID: [ses:feedback-id-a]:[ses:feedback-id-b]:[SESInternalID]:AmazonSES
This feature is available in all AWS regions where SES operates, and it works across all sending methods: the SES API v2, the legacy SES API v1, and the SMTP interface.
Setting tags via the SES API v2 (Boto3)
When calling send_email through the SES v2 API in Python using Boto3, pass the message tags inside the EmailTags parameter:
import boto3
client = boto3.client("sesv2", region_name="eu-west-1")
response = client.send_email(
FromEmailAddress="sender@example.com",
Destination={"ToAddresses": ["recipient@gmail.com"]},
Content={
"Simple": {
"Subject": {"Data": "Your weekly digest", "Charset": "UTF-8"},
"Body": {"Text": {"Data": "Hello!", "Charset": "UTF-8"}},
}
},
EmailTags=[
{"Name": "ses:feedback-id-a", "Value": "newsletter-weekly"},
{"Name": "ses:feedback-id-b", "Value": "segment-uk"},
],
)
Setting tags via the SMTP interface
If you send through the SES SMTP endpoint, inject the tags as custom X-SES-MESSAGE-TAGS headers before the message body:
X-SES-MESSAGE-TAGS: ses:feedback-id-a=newsletter-weekly, ses:feedback-id-b=segment-uk
SES reads these headers at ingestion time, strips them from the outbound message, and uses their values to populate the Feedback-ID header that Gmail receives. The recipient never sees the X-SES-MESSAGE-TAGS header.
Designing a Feedback-ID taxonomy
Because SES limits you to two custom fields, and because Gmail aggregates independently on each identifier, you need to choose your taxonomy carefully. A useful rule of thumb is to put your most granular, campaign-specific value in the a field and a broader category value in the b field. This way you get fine-grained debugging capability and a reliable higher-level signal that will accumulate enough volume to be statistically visible.
A practical taxonomy for a multi-product SES sender might look like this. The a field carries a campaign or send-type identifier such as "newsletter-weekly", "cart-abandon", or "otp-auth". The b field carries a product line or regional segment such as "product-billing", "region-emea", or "brand-retail". Keep all identifier values short, alphanumeric, and consistent across sends. Changing a value mid-campaign creates a new aggregation bucket and breaks historical comparisons.
Bear in mind that Google only generates FBL report rows when an identifier appears in a sufficient volume of messages and attracts enough distinct user complaints in a single day. Very small or highly granular campaigns may produce no FBL output at all even when the header is correctly formatted. Broader identifiers accumulate volume more reliably and are more likely to produce visible signals.
Registering and verifying your domain in Google Postmaster Tools
Postmaster Tools domain verification is a prerequisite for seeing any FBL data. The registration process requires that you can add a DNS TXT record to the domain you send from, and that domain must already have valid SPF and DKIM records in place. DKIM signing is especially important because Gmail only includes DKIM-authenticated messages in its spam rate calculations.
To register your domain, navigate to postmaster.google.com and sign in with a Google account. Click the plus icon to add a domain, enter your sending domain such as "mail.example.com" or "example.com", and Google will generate a TXT record value. Add that TXT record to your domain's DNS configuration. Verification typically completes within a few minutes once DNS propagation is complete, though it can take up to 24 hours. Once verified, the domain appears in your Postmaster Tools dashboard and data begins accumulating.
If you use a dedicated sending subdomain in SES, such as "email.example.com" as your MAIL FROM domain, verify that subdomain in Postmaster Tools rather than the root domain. The FBL dashboard will then show data scoped to the domain that appears in your DKIM signing, which is the domain Gmail uses for attribution.
Reading campaign-level complaint data in Postmaster Tools
Once your domain is verified and you have deployed the custom Feedback-ID tags, the Postmaster Tools FBL dashboard shows two graphs. The first is the average FBL spam rate across all campaigns per day. The second shows the count of unique identifiers flagged by the FBL on each day. Clicking a data point on the average spam rate graph expands the view to show individual identifier values and their associated complaint rates for that day.
Google's guidance is to keep your spam rate below 0.10% at all times, and to treat any sustained rate above 0.30% as a critical threshold that risks delivery penalties including bulk filtering or outright rejection. Gmail calculates this rate by dividing spam reports by the number of messages that reached the inbox, not the total number sent. Messages already delivered to the spam folder are excluded from the denominator, which means the effective rate can be higher than a naive calculation would suggest.
When an identifier appears in the FBL dashboard, it means that identifier's complaint rate is elevated enough to be statistically significant. Treat any FBL entry as an actionable alert rather than routine data. Identify the campaign associated with that identifier, review its audience quality, and consider pausing the send while you investigate.
Building a complaint-suppression workflow
Because Gmail does not send individual ARF complaints, you cannot automate per-address suppression directly from FBL data. What you can do is build a workflow that combines the campaign-level signal from Postmaster Tools with proactive list hygiene practices.
A practical suppression workflow has three stages. First, monitor the Postmaster Tools FBL dashboard daily, either manually or by polling the Postmaster Tools API if your volume warrants automation. When an identifier's spam rate exceeds your internal alert threshold, for example 0.08%, immediately pause any in-progress sends for that campaign identifier. Second, audit the audience segment associated with that identifier. Look for addresses that have not engaged in the past 90 days, addresses acquired through high-risk collection points such as co-registration or purchased lists, and addresses that have already bounced or complained on other providers via SES ARF events. Suppress all of those addresses before resuming the campaign. Third, review the content and frequency of the flagged campaign. A sudden spike that correlates with a new template or a change in send cadence is a strong signal that content or frequency is the root cause rather than list quality.
On the SES side, keep your SNS complaint notifications active even though Gmail does not contribute to them. Yahoo and other ARF-participating providers do send individual complaints through SES, and these give you suppressible addresses you can act on immediately. Cross-referencing SES ARF complaints with your Postmaster Tools FBL identifiers gives you a more complete picture of which campaigns are generating complaints across all providers, not just Gmail.
What Gmail FBL does not cover
The Gmail FBL is valuable but intentionally narrow. It covers only @gmail.com recipients, provides only aggregate data, and requires a minimum volume of both messages and complaints before any data point appears. Small campaigns, low-volume senders, and highly granular identifier schemes may see no FBL rows even when complaints are occurring.
Providers such as Yahoo Mail, Microsoft Outlook, and Comcast operate traditional ARF-based feedback loops that do send individual complaint notifications back to SES. These arrive as SES complaint events in your SNS topic and give you suppressible email addresses in near real-time. Monitoring these ARF complaints carefully is essential because they represent the half of the complaint picture that Gmail does not provide.
SES Monitor is designed specifically for this gap. It watches your SES event stream in real time, surfaces bounce and complaint events from ARF-participating providers the moment they arrive, and alerts your team before your account complaint rate reaches a level that triggers SES enforcement action. It does not replace Google Postmaster Tools but works alongside it: SES Monitor handles the immediate, address-level signals from providers that do send individual complaint data, while Postmaster Tools handles the Gmail-side aggregate view.
Gmail FBL readiness: checklist for SES senders
Use the following checklist to confirm your Gmail FBL setup is complete and actionable.
Authentication prerequisites: SPF record published for your sending domain. DKIM signing enabled and verified in SES. DMARC policy in place at a minimum of p=none. PTR records configured for your dedicated sending IPs, resolving to a valid hostname.
Postmaster Tools setup: Sending domain verified in Google Postmaster Tools. Postmaster Tools account linked to the same Google account used to manage your domain. Domain-level spam rate and compliance dashboards showing data.
Feedback-ID configuration: ses:feedback-id-a tag set on every campaign send with a consistent campaign or send-type identifier. ses:feedback-id-b tag set with a product line or segment identifier. Identifier values kept short, alphanumeric, and stable across sends for the same campaign type. Only one Feedback-ID header present per message.
Monitoring and response: Daily review of the Postmaster Tools FBL dashboard. Internal alert threshold defined (recommended: 0.08%). Documented process for pausing a campaign when its identifier appears in the FBL dashboard. SES SNS complaint notifications active and routing ARF complaints from non-Gmail providers into your suppression list. Real-time alerting configured so that emerging complaint trends are caught before they escalate to account-level SES enforcement action.