Six Months Without Domain Reputation: What Postmaster Tools v2 Actually Tells You

March 2026 — Operational note. The Domain Reputation and IP Reputation dashboards in Google Postmaster Tools were retired on September 30, 2025 and fully deprecated by October 31, 2025. The v1 API was shut down at the end of 2025. Six months into the new normal, this note examines what Postmaster Tools v2 actually predicts about deliverability, what diagnostic gaps the retirement created, and how to operationally rebuild the early-warning signals that the old four-tier reputation gauge used to surface.

The short version: the v2 dashboard is honest about what it shows but quieter about what it does not. The Compliance Status, Spam Rate, Authentication, Encryption, and Feedback Loop panels are useful. The High/Medium/Low/Bad reputation label that used to anchor deliverability triage no longer exists, and the absence is more operationally significant than Google's announcement implied. Six months of running production infrastructure without it has clarified which workflows broke and which monitoring practices replaced them effectively.

What Was Retired and What Remains

Google's announcement framed the retirement as removing "vanity metrics" and refocusing senders on actionable compliance signals. The framing is partly correct and partly self-serving. The old reputation labels were imperfect — Medium covered an enormous range of underlying sender behaviour, and the lag between sending changes and label changes was sometimes weeks. But the labels were not vanity. They were the single most direct signal Gmail provided about how its internal filtering model assessed a sending domain. Removing them changed the diagnostic surface from "Gmail thinks you are in the Medium tier today" to "Gmail will reject your message with a 5.7.26 if your compliance fails, and otherwise will not tell you what it thinks."

The five surviving dashboards each have specific operational uses. Spam Rate is the primary reputation signal that remains visible: Google's recommended ceiling is 0.1%, with 0.3% as the enforcement cliff. Authentication shows SPF, DKIM, and DMARC alignment pass rates per sending domain. Encryption tracks TLS adoption rates on outbound messages. Feedback Loop surfaces aggregated complaint data for senders that have registered for the FBL programme. Delivery Errors breaks down 4xx versus 5xx responses by error category, which is where the November 2025 enforcement escalation became most visible.

The Compliance Status panel is the genuine addition. It runs through Gmail's bulk sender requirement checklist (SPF, DKIM, DMARC at minimum p=none, one-click unsubscribe header for marketing mail, valid forward and reverse DNS, TLS, RFC 5322 formatting) and shows a binary Pass or Fail. When the result is Fail, it identifies which specific check failed. This is useful diagnostic information that did not exist in v1. It is also, importantly, a check on infrastructure configuration rather than on sending behaviour — passing Compliance Status does not mean Gmail trusts your mail, only that the technical baseline is met.

Why the Old Reputation Signal Mattered Operationally

It is worth being specific about what the old reputation labels did well, because the replacement strategies have to substitute for those specific functions rather than for "reputation" in the abstract. Three operational workflows depended on the High/Medium/Low/Bad gauge: warming validation, incident triage, and configuration change verification.

Warming validation. During IP warming, the old reputation label confirmed that the schedule was working. A new IP would start in the Unknown tier (greyed out in the dashboard), progress to Low or Medium within two to three weeks, and reach High at four to six weeks if the warming pace and engagement quality were appropriate. The label provided independent confirmation, separate from spam rate data, that Gmail's internal trust model was accumulating positive signals. Without it, warming validation now depends entirely on indirect signals: declining deferral rates, stable open rates as volume scales, low complaint accumulation, and Compliance Status remaining green. These are observable but more ambiguous — a low deferral rate during warming might mean the IP is building trust or it might mean Gmail is patient with low-volume new senders that have not yet earned a reputation in either direction.

Incident triage. When complaint rates spiked or delivery degraded, the first diagnostic step used to be checking whether domain reputation had dropped. If the label moved from High to Medium concurrent with a complaint spike, the connection was obvious and the recovery path was clear: reduce volume, audit list quality, wait for the label to recover. If the complaint spike happened without a reputation drop, the issue was more likely transient (a single campaign, a recent acquisition source, a content classifier hit) and required different remediation. The label encoded Gmail's internal judgement about whether the incident was structural or episodic, which is the single most important triage question for an incident. Without it, the same question has to be answered through external inference: comparing spam rate trends over 7, 14, and 30 day windows, checking whether Compliance Status changed, correlating with the specific campaigns sent in the affected window. The work is doable; it just takes longer.

Configuration change verification. When operators made significant infrastructure changes — switching SMTP relay providers, adding new sending IPs, changing DKIM key sizes, modifying DMARC policy — the old reputation label was the ground truth signal that the change did not damage Gmail's trust. A change that produced a stable reputation label over 30 days was confirmed safe. Now that signal is gone, and operators have to monitor a broader set of secondary indicators for a longer period before concluding a change is safe.

The November 2025 Enforcement Shift

The retirement of the reputation dashboards happened in tandem with an enforcement escalation that changed what compliance failures cost. Starting in November 2025, Gmail moved from filtering non-compliant mail to spam folders to issuing SMTP-level rejections with permanent 5.7.x error codes. The specific codes that became common: 5.7.26 for authentication failures (SPF or DKIM not passing or not aligned), 5.7.25 for missing or invalid PTR records, and 5.7.1 for mail blocked due to policy compliance failures including unsubscribe header absence on bulk traffic.

The escalation matters for how senders interpret Postmaster Tools v2 data. Before November 2025, a Compliance Status of Fail produced degraded inbox placement but messages still reached recipients via spam folder routing. After November 2025, the same Fail status produces permanent message rejections that never reach recipients. The dashboard reading is the same; the operational consequence is qualitatively different.

Rebuilding Early-Warning Signals Operationally

The diagnostic gap created by the reputation retirement is real, but it is bridgeable. The early-warning function that the old labels provided can be reconstructed from signals that are still visible, with some additional discipline around how those signals are read together. Three patterns have proven effective across CSE OÜ's managed infrastructure clients in the six months since the retirement.

Pattern 1: Spam Rate Trend Analysis Over Multiple Windows

The single biggest insight from operating post-retirement is that spam rate is a more informative signal than it appeared to be while the reputation labels existed. Looking at the trailing 7-day, 14-day, and 30-day windows together reveals direction and stability that a single-day number does not. A current spam rate of 0.06% is healthy in isolation; the same 0.06% becomes a warning if the 14-day trend shows a slow rise from 0.02% three weeks ago.

The threshold worth internalising: Google's documentation describes 0.3% as the enforcement line, but the operational reality is that placement starts degrading well before that. Programmes that drift from 0.04% baseline up to 0.10-0.15% sustained typically see open rate drops of 3-5 percentage points within 30 days, which is the proxy for the placement change that the retired reputation label would have flagged directly.

Pattern 2: Compliance Status as Stability Check

The Compliance Status panel is a less rich signal than the old reputation label, but it is a useful stability indicator. The check runs continuously against the bulk sender requirements; any drift in authentication configuration or unsubscribe header handling produces a Fail state that surfaces immediately. The recommended monitoring discipline: log the Compliance Status weekly and alert on any change from Pass to Fail.

The most common failure modes that surface in Compliance Status, in order of frequency observed across managed clients since November 2025:

• SPF lookup limit exceeded. Adding a new ESP or third-party sender pushes the include chain past the 10-lookup ceiling. Compliance Status flips to Fail. Resolution: SPF flattening or removal of unused includes.
• DKIM signing intermittent. A subset of mail (often transactional traffic on a different MTA) is sending without DKIM signature, dragging the alignment rate below the threshold Gmail considers compliant. Resolution: audit all sending sources, ensure DKIM signing is universal.
• DMARC alignment failure. SPF and DKIM pass but the From: domain does not align with either. Often surfaces when a marketing platform sends through its own domain while displaying the customer's brand in the visible From. Resolution: configure the platform to authenticate as the customer's domain.
• One-click unsubscribe header missing. The RFC 8058 List-Unsubscribe-Post header is absent on bulk marketing mail. Most major ESPs add this automatically but custom-built sending stacks frequently miss it. Resolution: add the header at the MTA or application layer.
• PTR record mismatch. The sending IP's reverse DNS does not match the HELO/EHLO hostname presented in the SMTP session. Surfaces as 5.7.25 rejections. Resolution: align PTR with sending hostname via the network provider.

Pattern 3: Cross-Provider Signal Correlation

The third effective replacement for the old reputation label is treating Postmaster Tools v2 as one of several reputation signals rather than the authoritative source. Microsoft SNDS, Yahoo Sender Hub, and engagement-based signals from inbox placement tests each provide a partial view; cross-correlating them produces the composite picture that the single Gmail reputation label used to summarise.

The discipline that has proven effective is a weekly correlation review: take the spam rate trend from Postmaster Tools v2, overlay the SNDS status changes, compare to seedlist placement scores, and check the DMARC pass rate. When all four show stable, healthy patterns, the absence of a direct Gmail reputation label is not operationally constraining. When two or more show drift in the same direction, the composite signal is at least as informative as the old single label was, and often earlier.

Lessons from the January 24, 2026 Incident

The January 24, 2026 Gmail spam-checking degradation is worth examining specifically because it revealed something about how Postmaster Tools v2 fits into the broader Gmail operations stack. For approximately four hours and 53 minutes, Gmail's spam classification systems experienced backend failures that triggered a retry storm. Some messages delivered during the window arrived with "not scanned for spam" warnings; others were classified inconsistently; Postmaster Tools data for the window had gaps.

Google's February 6 root-cause writeup cited capacity, retry tuning, and improved load shedding as the prevention actions. From a sender perspective, three observations from the incident shaped subsequent monitoring practice.

Observation 1: Postmaster Tools is downstream of Gmail's filtering systems. When the filtering system degraded, Postmaster Tools lost visibility into that period. This had not been clear before. Senders had implicitly assumed Postmaster Tools was an independent observability layer; the incident demonstrated it is a derived view that shares the same failure modes as the systems it observes. For operationally critical monitoring, this means Postmaster Tools cannot be the only source of truth — the MTA-side delivery logs are necessary as the primary data, with Postmaster Tools as the secondary correlation layer.

Observation 2: Retry storms compound at scale. The Gmail incident was triggered, in part, by a retry storm in the spam-checking backend. The same pattern affects sender infrastructure: when an ISP returns 4xx deferrals at elevated rates, an aggressive retry configuration can produce retry pressure that worsens the original ISP-side condition. The incident reinforced the importance of exponential backoff in MTA retry configuration, particularly for senders whose volume is significant relative to the receiving ISP's processing capacity.

Observation 3: Compliance Status is more resilient than reputation labels would have been. During the incident window, Compliance Status continued to reflect accurate state for participating senders because the check is configuration-based (SPF records exist, DKIM signing works, unsubscribe headers are present) rather than behaviour-based. A reputation label, if it had still existed, would have shown disrupted data during the same window. This is a subtle benefit of the v2 architecture that was not obvious at the time of the retirement announcement: compliance signals are more robust to backend disruption than behavioural signals because they do not depend on the same realtime classification pipeline.

What Google Has Hinted At and What Has Not Materialised

Google's retirement announcement promised "new dashboards to provide senders with more useful and actionable information" launching by end of 2025. As of March 2026, no genuinely new dashboard has materialised beyond the Compliance Status panel that was already part of the v2 rollout. The promised new signals — speculatively involving engagement data scrubbed of pre-fetch noise, real-time inbox placement rates, or domain-level behavioural metrics — have not appeared.

The v2 API has launched and is functional. The schema differs from v1 (any monitoring scripts built against v1 endpoints required rewriting). The API exposes the same data that the web UI shows: Spam Rate, Compliance Status, Authentication, Encryption, Feedback Loop, Delivery Errors. There is no API endpoint that returns a numeric reputation score or anything functionally equivalent to the old label.

Operational Summary: What Six Months Has Taught

The retirement of Domain Reputation and IP Reputation from Postmaster Tools v2 was, in the end, a more disruptive change than its description suggested. Senders who relied on the labels for warming validation, incident triage, and configuration change verification have had to build replacement workflows. Six months in, the replacements are workable but require more discipline than the labels did.

The four practices that have stabilised across well-run programmes since the retirement:

1. Monitor spam rate as a trend, not a snapshot. The 7-day, 14-day, and 30-day windows together provide what the old label did directly. Set up alerts on slope rather than on threshold — a sustained rise from 0.03% to 0.06% is more actionable than the absolute value of either point.
2. Treat Compliance Status as the configuration health check. Weekly log review with alerts on any Pass-to-Fail transition. The check is cheap; the cost of missing a compliance regression in the current enforcement environment is high.
3. Correlate across providers. Postmaster Tools v2, Microsoft SNDS, Yahoo Sender Hub, seedlist tests, and DMARC aggregate reports together approximate the diagnostic surface that the single Gmail label used to offer. None of them alone is sufficient; the composite picture is roughly as informative as the old label.
4. Use MTA-side data as primary, not secondary. The PowerMTA accounting log, the deferral rate per ISP, and the bounce code distribution are realtime signals that do not depend on Gmail's observability layer. When that layer disrupts (as in the January 24 incident), the MTA data continues to be reliable.

The retirement did not make deliverability harder. It did make the diagnostic work more distributed and the responsibility for synthesising signals more squarely the sender's. Programmes that already had mature MTA-side monitoring and cross-provider data adapted quickly; programmes that relied on the Postmaster Tools dashboards as their primary deliverability instrument experienced a more painful transition.

For organisations that operate dedicated email infrastructure, the most important takeaway from six months of post-retirement experience is that the MTA layer and the Postmaster Tools layer serve different functions, and the relative importance of MTA-side observability has increased. The accounting log was always the source of truth for what happened during sending; in the absence of a Gmail reputation label, it is also the most direct source of truth for whether sending behaviour is producing the expected ISP responses. Investing in MTA-side monitoring — per-IP deferral rate tracking, per-ISP bounce code distribution analysis, anomaly detection on connection latency — produces operational leverage that the old reputation label partly substituted for during its lifetime.

Looking Ahead

Google has not announced specific plans for new dashboards in 2026 beyond what is already in v2. The pattern across the past 18 months — bulk sender requirements in February 2024, full enforcement in June 2024, Microsoft alignment in May 2025, retirement of reputation in September 2025, escalation to permanent rejections in November 2025 — suggests the trajectory is toward stricter compliance enforcement rather than richer behavioural data. The signal Google is communicating to senders through the cumulative changes is that compliance and engagement matter more than reputation, and that reputation should be earned through behaviour rather than measured against a label.

Whether that framing is correct or self-serving is debatable. What is not debatable is that operators who built their monitoring practice around the old reputation labels have had to adapt, and that the adaptation has favoured operators with mature MTA-side data, cross-provider monitoring, and disciplined trend analysis over those who relied on a single dashboard as the source of truth.

Related operational notes covering the post-Postmaster Tools v1 era: Why Inbox Placement Is a Lagging Indicator, Gmail Bulk Sender Requirements: Enforcement Lessons, How to Read Microsoft SNDS Data for Operational Decisions, Building Observable Email Infrastructure, and Separating Signal from Noise in SMTP Accounting Logs. For technical context on Compliance Status implementation, see the PowerMTA technical FAQ and the full operational notes series.