Feedback-ID

Every email OptiPub sends carries a Feedback-ID header. Google uses this header to group spam complaints in Google Postmaster Tools, so your complaint data breaks down by individual send instead of arriving as a single number for your whole domain. Google's Feedback Loop documentation covers the header itself in full detail.

OptiPub sets the header automatically on every send. There is nothing to configure.

Format

The header is four colon-separated fields:

Feedback-ID: <mailing or template ID>:<sender name>:<mail class>:0000<client ID>

A real broadcast looks like this:

Feedback-ID: 57949898:KyleOptiPub:bulk:00007

📘

Google requires the sender identifier to be the last field, and reads the fields from the right. Because : separates them, no value may contain a colon — this is why the sender name is stripped of punctuation before it is used.

Mail class

The third field tells Google which kind of mail it was, and it also determines what the first field identifies.

That difference is useful rather than incidental. A broadcast is a one-time event, so its complaint rate belongs to that send alone. An auto responder sends the same content continuously, so reporting it under a stable template ID lets Google accumulate a meaningful rate for the auto responder as a whole instead of scattering complaints across thousands of single-recipient sends that would each be too small to report on.

📘

Bulk and transactional mail draw very different complaint behavior, so compare each class against itself over time rather than against the other.

Using it in Google Postmaster Tools

1. Verify your sending domain in Google Postmaster Tools. See Domains for the DNS records OptiPub needs.
2. Open the Feedback loop report.
3. Find the row for the identifier you care about, using the table below.

Postmaster Tools does not list the whole header value. It reports each field as its own identifier, so a single message like 57949898:KyleOptiPub:bulk:00007 produces four separate rows:

To investigate a bad rate, start at the sender name row to confirm which publication is affected, then look for mailing IDs and auto responder template IDs with high rates to find the specific content responsible.

Google only reports an identifier once that day's traffic contains enough messages and enough distinct spam reports, so low-volume mailings may not appear at all. FBL data also covers @gmail.com recipients only — it says nothing about how other mailbox providers see the same send.

The Postmaster+ Feedback tab

Reading the raw Google report means checking one identifier at a time. Postmaster+ pulls the same data through the Postmaster Tools API and aggregates it on its Feedback tab, which lists every identifier reported across your domains alongside its average complaint rate and the number of days Google reported it.

Because the list is sortable, the identifiers driving the most complaints surface immediately, and selecting one opens its daily history so you can see whether a rate is a one-day spike or a sustained problem. Since bulk identifiers are mailing IDs, a bad row points at a specific broadcast you can open in OptiPub.

Gmail complaint % in OptiPub

OptiPub reads those identifiers back through the Postmaster+ API and writes each one's complaint rate onto the message it came from, so there is nothing to cross-reference by hand.

flowchart LR
  A[Gmail Postmaster Tools] --> B[Postmaster+ Feedback]
  B --> C[Hourly sync]
  C --> D[Gmail % on the message]

Connecting Postmaster+

1. In Postmaster+, open Team Settings → API Tokens and create a token.
2. In OptiPub, go to Admin → Settings → Integrations, open Postmaster+, and paste the token into API Token.

📘

The token must be your own team's. Spam identifiers are scoped to the Postmaster Tools team that owns the domains, so OptiPub authorizes these calls with your team token rather than a shared one.

Once connected, the sync runs hourly. Each run asks Postmaster+ which identifiers were reported in the last seven days, then stores the daily complaint rate for each one. Google publishes this data once a day, so hourly polling simply means a new day appears in OptiPub shortly after Google releases it.

Where the value appears

Matching relies on the first field of the header, so it lands on broadcasts: OptiPub finds the message whose mailing ID equals the identifier and stores the average of that identifier's reported daily rates. That value surfaces in two places:

A few things worth knowing about the number:

• Days with a zero rate are left out of the average. Google reports zeros for identifiers that otherwise have real complaint data, and including them would understate the rate.
• A dash means Google has not reported that mailing. Most often the send did not clear Google's volume threshold, as described above.
• Read it alongside Complaints, not instead of it. OptiPub's Complaints percentage is measured against FBL-eligible recipients, which excludes Gmail and Google Workspace, so Gmail % covers exactly the audience the other column cannot.
• Split test parents average their children. A parent message reports the average of whichever variations have a Gmail rate, and stays blank when none do.

Related

• The header is covered by the message's DKIM signature. Google requires this — unsigned Feedback-ID headers can be spoofed, so FBL data is only generated for traffic signed by a domain you have verified in Postmaster Tools.
• Google's Feedback Loop documentation is the authoritative reference for the header format and how the data is aggregated.
• Complaints that come back through a feedback loop are recorded as FBL events. See Invalid Subscribers for handling them automatically, and the Glossary for how complaints are counted in stats.