How should I format Feedback-ID for Gmail?
Updated on 26 Oct 2026: We clarified Gmail's Feedback-ID field rules and added DKIM signing checks and Amazon SES setup examples.
Format Gmail Feedback-ID as four colon-separated values at most: three optional identifiers followed by a mandatory right-most SenderId. The direct answer is Feedback-ID: campaign:stream:account:senderid. This is a useful naming convention. Gmail requires SenderId last, but does not assign fixed meanings or a required hierarchy to the optional fields.
If your current idea is Database ID:Contact List ID:Mailing ID:Account Name, the first three values can identify those groups in that order. Replace Account Name with a stable 5-15-character SenderId. Another useful convention is Mailing ID:Contact List ID:Database ID:SenderId, with compact values and no personal data.
- Use four fields max: Gmail uses the first four fields separated by colons, starting at the right.
- Make SenderId stable: The right-most value is mandatory, 5-15 characters, and should stay consistent across the mail stream.
- Avoid recipient values: Never use a subscriber ID, Message-ID, email address, order ID, or any value unique to one message.
- Expect sparse reports: Gmail only shows Feedback Loop data when an identifier has enough mail and enough distinct spam reports.
The exact Gmail format
Google documents the header as Feedback-ID: a:b:c:SenderId. The three left-side fields are optional identifiers. The right-most SenderId is required. Google also says the aggregate data is generated for the first four colon-separated fields, starting at the right side. If SenderId is empty, Gmail generates no data. An empty optional field does not block reporting for the remaining fields because Gmail aggregates each identifier independently. The Google FBL help page is the source to follow when checking the official syntax.
The important part is that Gmail does not need labels like campaign= or account=. Only the right-most field has a fixed role, SenderId. Each optional identifier is aggregated independently. Prefixes inside values help when namespaces overlap, such as camp8241 or acct42, because they keep identifiers from colliding across fields.
Keep campaign IDs unique across customer accounts. If two accounts both use camp8241, distinguish them as acct42camp8241 and acct73camp8241. Use prefixes or hashes to separate overlapping namespaces, and reuse an identifier across messages only when you intend a shared reporting group.
Recommended Feedback-ID shapes
Feedback-ID: acct42camp8241:listnews:acct42:brand01 Feedback-ID: acct42batch250525:otp:acct42:esp01 Feedback-ID: acct42camp8241::acct42:brand01 Feedback-ID: brand01
|
|
|
|
|---|---|---|---|
A | Campaign or batch | acct42camp8241 | Message ID |
B | List or stream | listnews | Recipient ID |
C | Account or program | acct42 | Person name |
D | SenderId | brand01 | Long label |
One possible mapping; Gmail does not prescribe the roles of A, B, and C.
Do not put private identifiers in this header
Treat Feedback-ID as a reporting key. It should be repeated across enough messages to create useful aggregate data. If a value points to one recipient, one transaction, or one message, Gmail can suppress it and your own privacy risk increases.
How to choose Feedback-ID values
Choose Feedback-ID values by asking what the team needs to isolate when Gmail shows an unusual complaint rate. That usually means a campaign or batch, a list or stream, an account or product area, and a stable sender ID. Keep SenderId consistent across the mail stream. Each optional identifier should describe a group with enough daily traffic to support aggregate reporting.
For a single brand sending its own mail, the right-most SenderId can be a compact brand code. For an ESP, agency, or multi-tenant platform, the right-most value often identifies the platform, while the next value identifies the customer account. If that creates poor grouping for your reporting model, keep the right-most value as your stable sender program and put customer or account in the C position.
Good identifier design
- Stable groups: Use values that repeat across many messages.
- Clear namespaces: Prefix values when IDs overlap between accounts, lists, or campaigns.
- Operational labels: Map each value to something your team can act on quickly.
- Manage granularity: Keep identifiers broad enough to group many messages, with a stable SenderId.
Poor identifier design
- Personal values: Do not use email addresses, user IDs, or order numbers.
- One-off values: Avoid unique Message-ID values or per-message random strings.
- Ambiguous reuse: Do not reuse the same value across unrelated fields.
- Invalid SenderId: Keep the final value at 5-15 characters. Google states that length rule for SenderId, not for every optional field.
Smallest bucket first and largest bucket last is one practical convention. With this layout, read the header right to left to review the sender program before a specific campaign. This is a triage method, not a Gmail aggregation hierarchy: Gmail reports each qualifying identifier separately.
Feedback-ID grouping flow: SenderId, account, stream, and campaign.
What Gmail reports back
Gmail Feedback Loop reporting gives aggregate spam complaint statistics, without per-recipient Abuse Reporting Format (ARF) reports. You do not receive the identities of users who clicked spam, so FBL data cannot build a recipient suppression list. The Feedback Loop dashboard shows Average FBL spam rate over time and Identifier volume, which counts unique reported identifiers per day, not messages sent. Click a point on the spam-rate graph to inspect the qualifying campaigns behind it.
The scope is narrower than many teams expect: Gmail FBL data only applies to @gmail.com recipients. It does not cover every mailbox hosted by Google Workspace, and it should not be treated as a full replacement for domain-level complaint and authentication monitoring.
A correctly formatted header can still produce no visible FBL rows. An identifier needs sufficient daily mail volume and distinct user spam reports; Google publishes no fixed numeric threshold for either. A blank dashboard does not establish a zero complaint rate. If domain-level spam rates are high but FBL identifiers are missing, consider fewer, broader identifiers rather than adding more granular values.
Choosing the scope of Feedback-ID identifiers
Qualitative grouping advice, not Gmail reporting thresholds. Every identifier still needs sufficient daily traffic and spam reports.
SenderId
Keep stable
Broad sender program or platform value.
Account
Group messages
Customer, brand, or product program.
Campaign
Check volume
Useful only when send volume is large enough.
Recipient
Do not use
Private or unique values should be excluded.
Feedback-ID differs from the domain-level Spam Rate dashboard. That dashboard measures user-reported spam on DKIM-authenticated mail delivered to engaged Gmail inboxes, as described in Google's dashboard documentation. FBL isolates qualifying tagged groups. Their different scopes mean the rates are not interchangeable. A low rate also does not prove good inbox placement, because messages Gmail sends directly to spam get fewer opportunities for inbox recipients to report them.
Google Postmaster Tools Feedback Loop table with Feedback-ID identifier spam rates.
How to read the Postmaster Tools views
The Feedback Loop dashboard has two aggregated views. Select the view that matches how the domain participates in the message, then keep that scope consistent when comparing dates or investigating a complaint spike.
- From header domain: Includes messages where the selected domain matches the visible From: header domain. Use it to investigate complaints tied to the brand recipients see.
- All signed domains: Includes messages where the selected domain is one of the successful DKIM signers. Use it for a broader view across mail that the domain signs, including multi-domain or platform sending.
A row that appears under All signed domains but not under From header domain usually means the selected domain signed mail whose visible From: domain was different. Check the DKIM signing domain, From: domain, and Feedback-ID taxonomy before treating the difference as missing data.
Implementation checklist
The header has to be present before DKIM signing and covered by the signature. Confirm that Feedback-ID appears in the h= list of signed header names, defined in the DKIM signature specification. A passing DKIM signature alone does not prove that the custom header was signed. If a relay adds Feedback-ID after your application signs, have the relay sign the header. For related Gmail header work, the RFC 5322 guide is useful when validating the wider message format.
- Design the taxonomy: Decide what A, B, C, and SenderId mean for your sending model.
- Keep values safe: Use compact ASCII identifiers with no spaces, no colons, and no recipient data.
- Sign the header: Insert Feedback-ID before signing and include feedback-id in the passing signature's h= list.
- Verify the domain: Add and verify the DKIM signing domain you own or control in Gmail Postmaster Tools.
- Check infrastructure: Follow Google's FBL guidance for SPF on the signing domain and sending-IP PTR records. The PTR hostname's forward DNS must resolve back to the sending IP. See Google's FBL setup requirements.
- Check one header: Make sure the message has only one verified Feedback-ID header.
- Review results: Compare FBL identifiers with spam rate, authentication, and campaign timing.
Illustrative message headers (DKIM signature abbreviated)
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; h=from:to:subject:feedback-id; bh=...; b=... From: Example Brand <news@example.com> To: subscriber@example.net Subject: Weekly account update Feedback-ID: acct42camp8241:listnews:acct42:brand01
After adding the header, send a test through your production sending path to a Gmail inbox. Open the message menu and select "Show original" to inspect the raw headers. Confirm that Feedback-ID is present once, SenderId is last, and the passing DKIM signature includes feedback-id in its h= list. Suped's email tester helps with this practical check because it shows the received headers and authentication results in one report.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If DKIM fails after the change, fix that before judging Feedback-ID. A broken DKIM signature can prevent Gmail from trusting the header. Suped also has a focused DKIM checker for DNS validation when you need to confirm selectors, public keys, and signing domains.
When Amazon SES generates the header
If you send through Amazon SES, do not try to replace the whole Feedback-ID header. SES owns the generated header and, since June 11, 2024, lets you add two custom values with the message tags ses:feedback-id-a and ses:feedback-id-b. AWS documents this as SES custom values for the generated Feedback-ID header.
Use the same taxonomy with fewer sender-owned slots. Put the most useful aggregate buckets into A and B, such as tenant and campaign, or account and mail stream. The a tag supplies the first field and the b tag supplies the second; SES supplies its internal identifier and the final AmazonSES value. Keep your values short and stable, with no recipient-level data.
Amazon SES v2 SendEmail tags (request excerpt)json
{ "EmailTags": [ { "Name": "ses:feedback-id-a", "Value": "acct42" }, { "Name": "ses:feedback-id-b", "Value": "listnews" } ] }
For SMTP or raw email, pass these tags through X-SES-MESSAGE-TAGS rather than adding another Feedback-ID header. The AWS event publishing documentation describes the API and raw-header methods.
Amazon SES tags for SMTP or raw email
X-SES-MESSAGE-TAGS: ses:feedback-id-a=acct42, ses:feedback-id-b=listnews
Do not confuse reporting with compliance
Feedback-ID is an optional diagnostic header. It does not satisfy Gmail's bulk-sender requirements. Bulk senders still need SPF and DKIM authentication plus DMARC, valid DNS, TLS, and low spam rates. Marketing and subscribed messages also need one-click unsubscribe and a visible unsubscribe link in the message body.
Check email authentication with Suped
Feedback-ID identifies tagged Gmail groups with unusual complaints when enough data exists. Investigate the affected campaign's audience and sending frequency, then check authentication separately. Correct authentication does not prevent recipients from reporting unwanted mail.
Suped's DMARC and email authentication platform helps teams review sending sources and investigate SPF or DKIM failures by domain.
A practical workflow is to use Feedback-ID to isolate Gmail complaint buckets, then use Suped's DMARC monitoring and domain health checker to investigate authentication failures on the affected sending source. These checks support troubleshooting; they do not guarantee inbox placement.
Practical workflow
- Tag the mail: Use Feedback-ID to identify Gmail complaint buckets.
- Verify authentication: Review the affected sending source's SPF and DKIM results in Suped's DMARC reports.
- Act on issues: Use Suped issue detection and steps to fix the failing source or domain.
- Watch changes: Use real-time alerts and weekly summaries after each sender or policy change.
Common mistakes that reduce FBL value
The most common mistake is making the header too precise. It is tempting to add every internal ID you have, but Gmail's FBL is designed for aggregate abuse and complaint analysis. If a field changes on every message, that field cannot provide a useful reporting group; broader identifiers in the same header can still qualify.
- Wrong final field: Keep SenderId last. The optional fields have no required campaign, list, or account order.
- Weak SenderId: An empty final value prevents reporting; a value outside 5-15 characters or a frequently changing value undermines the required stable sender identifier.
- Duplicate headers: Multiple Feedback-ID headers create uncertainty and can break reporting.
- Unsigned header: Adding Feedback-ID after signing, or omitting it from the signature's h= list, leaves it unprotected even when another DKIM signature passes.
- Sparse campaigns: A campaign with low Gmail volume often produces no visible FBL output.
- Repeated identifiers: Reusing one value across unrelated fields can merge complaint signals that should stay separate.
- No action map: If nobody can map an identifier back to a campaign, list, or owner, the report has little value.
If you already have rows in Postmaster Tools but do not understand the warning, the Identifiers flagged page explains how to read that status.
Views from the trenches
These sender experiences describe practical grouping conventions, not a Gmail-required order for the optional fields. Gmail reports each qualifying identifier independently.
Best practices
Map Feedback-ID values to stable mail groups your team can trace without personal data.
Keep SenderId broad and consistent, then use left fields for stream and campaign detail.
Add Feedback-ID before DKIM signing and include it in the passing signature's h= list.
Common pitfalls
Using recipient-level IDs often suppresses reporting and creates unnecessary privacy risk.
Expecting every campaign ID to appear leads to false concern when Gmail lacks enough data.
Reusing the same identifier across unrelated fields can merge complaint signals incorrectly.
Expert tips
Keep SenderId last; choose optional group identifiers your team can trace across messages.
Use prefixes or hashes when ID namespaces overlap between accounts, lists, or mail types.
Compare FBL rows with spam rate and authentication changes before changing the taxonomy.
Marketer view
Marketer from Email Geeks says Gmail Feedback-ID supports four variable slots, usually expressed as A:B:C:D.
2024-01-12 - Email Geeks
Marketer view
Marketer from Email Geeks says many accounts only show one or two identifiers, even when all four are present.
2024-01-12 - Email Geeks
