Google Retired Domain Reputation in Postmaster Tools

Google removed the Domain Reputation and IP Reputation dashboards from Postmaster Tools. They are not hidden, moved or renamed in version 2. They are gone, and the reason Google gives is that reputation data "is not easily actionable for most senders."

If you have been treating a green domain reputation as your all-clear signal, that signal no longer exists. And if you run cold email, there is a second problem underneath it that most people have never noticed: your domains were probably never generating Postmaster data in the first place.

What Google actually removed

The v2 migration notes are direct about it. All the dashboards from the old Postmaster Tools carried over to v2 with one exception, and that exception is the Domain and IP Reputation pair.

The API tells the same story more precisely. The v2 interface publishes the complete list of metrics it can return, and reputation is not among them:

The old version had a ReputationCategory field returning HIGH, MEDIUM, LOW or BAD for your domain and for each sending IP. There is no v2 equivalent. The legacy interface was retired in September 2025, so the migration is not optional and there is no fallback view.

Google's stated reasoning deserves a moment, because it is more defensible than it first looks. A domain reputation of MEDIUM told you something was wrong and nothing about what. It moved slowly, lagged the behaviour that caused it, and gave you no lever to pull. Plenty of senders watched it drop for a week with no idea which campaign, list or mailbox was responsible.

The threshold nobody calculates

This is the part that catches operators out, and it has nothing to do with the v2 change.

Postmaster Tools only reports on domains that send Gmail a meaningful amount of mail. Google's API documentation states the floor plainly: only domains that send mail to at least 50 users per day receive statistics. Note the unit. It is fifty recipients, at Gmail specifically, per domain, per day. Volume to Outlook, Yahoo or anywhere else does not count toward it. Operators who watch these dashboards closely generally report needing more than the stated minimum before charts fill in reliably.

Do the arithmetic on your own setup rather than assuming either way, because the answer swings hard on one number: how much each mailbox sends.

Start from the floor and work backwards. Fifty Gmail recipients a day, from one domain. If roughly a third of your list sits on Google Workspace or Gmail, that domain needs to send about 143 emails a day in total to produce fifty Gmail recipients.

Now split that across the mailboxes on the domain:

Ten mailboxes at fifteen sends each clears it comfortably and that domain will report normally. Ten mailboxes at three sends each produces around ten Gmail recipients a day, nowhere near the floor, and that domain reports nothing at all.

Two things move the answer, and both vary enormously between agencies. The first is sends per mailbox, which ranges from a very cautious three to a fairly ordinary twenty-five. The second is what share of your list is actually on Google. Selling to small businesses might put you at half; selling to enterprise, where Microsoft 365 and security gateways dominate, can drop it well below a third and push the required send volume much higher.

There is a real tension underneath this. Spreading low volume across many domains is a core defensive tactic in cold email. It limits the blast radius when one domain gets burned, and it is why rotation setups buy new domains before the old ones degrade. The more thinly you spread, the less likely any single domain clears Google's reporting bar. You could concentrate sending onto fewer domains to get Postmaster data, but you would be trading a real deliverability practice for a dashboard, which is a bad trade.

Why the empty dashboard is worse than no dashboard

When a domain falls below the threshold, the API does not return an error. It returns a success response with no statistics for the dates it has nothing for. Individual metrics go missing rather than showing zero.

Read that failure mode carefully, because it is the dangerous one. An empty chart looks exactly like a healthy chart to anyone glancing at it. There is no banner, no warning, no "insufficient volume" state to tell you that you are looking at an absence rather than a result.

Anyone who has connected Postmaster Tools, seen flat empty graphs, and concluded that things must be fine has made a reasonable inference from a bad interface. The graph was never measuring anything.

One more limitation worth knowing even when you do have data: the user-reported spam ratio only covers mail authenticated with DKIM. If part of your sending is not DKIM-signed, that portion is invisible to the metric.

What to watch instead

Split your signals into two groups by a single question: does this signal need volume to exist?

Signals that need volume, and are worth checking when you have it

If you do run a domain over the threshold, whether that is a client's main corporate domain or a higher-volume sending domain, three v2 metrics are worth your attention.

Spam rate. The closest thing to a reputation replacement, and more actionable than reputation ever was, because it moves quickly and points at recent sending. Google has long advised keeping complaint rates below a low fraction of a percent, and the direction of travel matters more than the absolute number on any single day.

Authentication success rate. A drop here usually means something changed in your DNS rather than something changed about your reputation. That is a fixable class of problem, and often a vendor changed something upstream rather than you changing anything.

Delivery errors. The most useful and most ignored of the three. The error types are specific enough to act on, including rate limiting, suspected spam, spammy content, DMARC policy problems, and the domain or IP appearing on a blocklist. A rising SUSPECTED_SPAM share is the signal reputation used to summarise, arriving sooner and naming its cause.

Signals that work at any volume

These matter regardless of which side of the threshold your domains fall on, because they do not care how much mail you send.

Authentication correctness. SPF, DKIM and DMARC either resolve correctly or they do not. Two things break here more often than people expect. A second SPF record on the same domain makes SPF fail permanently no matter how correct either record looks alone, and most "is my SPF set up" checkers still show green because a record exists. Separately, SPF has a hard limit of ten DNS lookups, and nested includes from your sending platform, your CRM and your helpdesk quietly stack up until you cross it. Neither failure announces itself. Our SPF, DKIM and DMARC guide covers the setup, and the free deliverability checker will resolve a domain's records for you.

Blocklist status. Whether a sending domain is listed on Spamhaus or a similar list is a public fact, checkable at any volume, and one of the few signals that is both binary and urgent. Start with how to check a domain on Spamhaus and get it delisted.

Bounce rate, watched against a threshold that reflects reality. Receivers start filtering harder above roughly two percent, and a bounce spike is usually the first visible symptom of a list problem rather than a sending problem. See what counts as a good bounce rate.

Reply rate against each campaign's own baseline. This is the signal nothing else gives you, because it requires a comparison rather than a threshold. A campaign that was pulling three percent replies and now pulls half a percent is telling you something before any authentication check fails. Sending platforms notify you when a reply arrives. None of them notify you when replies stop, because an arriving reply is an event and silence is not.

Placement testing. If you genuinely need to know where mail is landing rather than inferring it, seed testing is the only method that works at low volume. It costs money per test and it samples rather than measures, but it answers the question Postmaster Tools cannot answer for a domain sending thirty emails a day.

What about Microsoft?

Microsoft's Smart Network Data Services is the usual suggestion, and for most cold email senders it does not apply.

SNDS reports on IP addresses. Access is granted to whoever is responsible for the IP range according to public registration and routing records. If you send through Google Workspace, Microsoft 365 or a sending platform, your mail leaves from shared provider infrastructure. You do not own those IPs, you cannot claim them, and the reputation of a shared pool would not be attributable to your sending anyway.

There is no domain-level Microsoft equivalent of Postmaster Tools. For Microsoft recipients, your usable signals are the volume-independent ones above, plus watching whether outcomes differ between Google and Microsoft recipients on the same campaign, which is often the first sign of a problem specific to one ecosystem.

The practical takeaway

Reputation was a lagging summary of things you could have measured directly. Losing it is an inconvenience, not a crisis, and Google's justification for removing it is fair.

The real lesson is the one underneath: a monitoring signal you cannot generate is not a monitoring signal. Run the arithmetic on your own domains before you decide how much weight Postmaster deserves in your stack. If they sit below the floor, this change removed a metric you were never receiving, and the empty charts you have been reading were never telling you anything either way.

Build your monitoring on things that exist at your volume. Authentication that resolves correctly, domains that are not blocklisted, bounce rates measured against where filtering actually starts, and reply rates compared against each campaign's own history. Those work whether a domain sends thirty emails a day or thirty thousand.

If you run several client workspaces and checking all of that by hand across each one is the part that never quite happens, that is the job ColdOps does automatically, on every sync, across Instantly, Smartlead and EmailBison.