Google Postmaster Tools is the one place where Gmail reports on your mail in its own numbers. It is free, it lives at postmaster.google.com, and for most of its life people opened it for a single chart, domain reputation, the four-step verdict that ran from bad to high. That chart is on its way out. Google has been moving everyone to a new interface (it calls it v2), and the new one has no domain or IP reputation at all. The old interface is still reachable because Google put its retirement on hold, but the deprecation notice says in so many words that the reputation dashboards will be retired. Google also writes that a new version will replace them, with no date given, so for now I build no habit around either.
What is left is more useful than it sounds.
Adding your domain
You sign in with a Google account, press "Add new domain" and type the domain your mail authenticates with. Google's setup page says it should be the DKIM d= domain or the SPF domain from the Return-Path. For a lot of senders neither of those is the From domain. If your platform signs with its own domain, or your bounces go to something like bounces.yourplatform.net, adding yourbrand.com verifies without complaint and then shows you nothing. I have watched people wait a month for data that was never going to arrive under that name.
So look at the headers of a message you actually sent before you pick. DKIM-Signature carries d=, and Return-Path carries the bounce domain. If neither is yours, the fix is custom DKIM on your sending platform, and until you have it Postmaster Tools has nothing to attach to you.
Verification is a DNS record. The tool gives you a TXT record (or a CNAME, if your DNS host makes TXT awkward), you publish it and press Verify. It usually goes through at once; Google allows up to ten minutes.
Subdomains confuse people. Once the parent domain is verified you don't have to verify each subdomain, but you can still add news.yourbrand.com as its own entry and watch it separately. I do that whenever marketing and transactional mail leave from different subdomains, because one combined line hides which stream is misbehaving.
Why every chart is empty
Almost everyone hits this in the first week, and I did too. The domain is verified, mail is going out, and each dashboard says there is no data.
Postmaster Tools reports only on mail to personal Gmail accounts, and on days with low volume it may leave data out to protect the privacy of Gmail users. Google doesn't publish the cutoff. In practice a sender with a few hundred Gmail recipients a week gets gaps and lonely dots, while a sender mailing thousands of Gmail addresses every day gets continuous lines.
Three more things make the charts look broken when they are not, and only the third one costs you anything. Days are counted in UTC, so a campaign that went out on Monday evening in California lands on Tuesday. Data usually arrives within 24 hours and sometimes later, which means today is always blank. And the spam rate and the feedback loop count only DKIM-signed mail, so an unsigned stream is invisible rather than bad.
If you send too little for any of this to fill in, the tool can't help you yet, and testing the message itself is a better use of the afternoon. I described how I run such a test in the post on testing deliverability.
Compliance status
This dashboard in the new interface answers one question. Does your mail meet Gmail's sender guidelines? Each requirement gets one of three states, Compliant, Needs work or No data found.
Every sender gets five rows, for SPF and DKIM authentication, DNS records, message formatting, encryption and the user-reported spam rate. Bulk senders get three more. Google counts you as bulk at close to 5,000 messages or more a day to personal Gmail accounts, and from then on DMARC authentication, one-click unsubscribe and honoring unsubscribe requests are checked too.
Two details from the dashboard documentation matter once you start fixing things. A change can take up to seven days to show up, so a row that is still red the morning after you edited DNS tells you nothing yet. And the status is reported for the primary domain only while the data behind it includes subdomains, which means one badly configured subdomain can paint the whole brand red.
Most of these rows describe a property of a single message, and that part doesn't need a week of Gmail data. SPF and DKIM passing, a DMARC record on the From domain, TLS on the connection, the List-Unsubscribe and List-Unsubscribe-Post headers from RFC 8058, all of it is visible in one message before the send. Email Spam Tester checks exactly that part. You mail it the real message, it runs 42 checks, and its compliance group lines up with these rows. The spam rate and honoring unsubscribes are a different kind of requirement. They exist only after real people have had the mail for a while, so Postmaster Tools is the only place to see them.
Spam rate
Google's definition is narrower than most people assume. It is the percentage of your messages delivered to the inboxes of engaged recipients that those recipients then marked as spam by hand, counting DKIM-authenticated mail only.
The sender guidelines draw two lines. Stay below 0.1%, and never reach 0.3%. Above 0.3% you lose eligibility for Google's mitigation support, and you get it back only after seven days in a row under that line. In round numbers 0.3% is three complaints per thousand messages that reached an inbox, and one careless send can do that to a small list. The Gmail rules around this number are listed in full in the post on Gmail's spam folder.
One consequence of the definition took me a while to accept. Mail that Gmail has already filtered never reached an inbox, nobody could report it, and it doesn't count. That is my reading of the definition rather than something Google spells out, but it matches what I see. A sender who is mostly filtered can have a calm chart. When the spam rate drops while opens and clicks drop with it, I take it as filtering getting worse.
At low volume the line jumps around. Two complaints on a quiet day draw a spike that means very little, so for anything under the red line I look at a whole week before I react.
When the spam rate climbs
First I put the spike next to the send log. A jump almost always has a date, and the date almost always has a campaign. From the years I spent on the sending side, I can say the cause is nearly always on a short list. Somebody mailed a segment nobody had touched for a year, a signup form without confirmation got filled in by bots, a new schedule quietly doubled the frequency, or the unsubscribe link opened a login page.
Then I narrow it down to one stream. The feedback loop dashboard does this well, provided it was set up before the trouble started. Without it, separate subdomains per stream are the next best thing.
The remedy depends on the cause, though a few moves come up nearly every time:
- Stop mailing people who haven't opened or clicked in months, starting with the next send rather than after a cleanup project.
- Make leaving easy, with one-click unsubscribe in the headers, a visible link in the body and no confirmation page asking for anything.
- Use confirmed opt-in wherever the signups come from a form you don't fully control.
- Keep volume steady while you recover. A burst in a bad week looks like the start of a spam run.
What I don't do is move to a fresh domain. The complaints follow the list and the content to the new domain, which also arrives with no history at all.
Feedback loop
You choose the identifiers here yourself and put them in a Feedback-ID header, and the dashboard breaks the spam rate down by them. The format is on Google's feedback loop page:
Feedback-ID: 2026-10-newsletter:eu:promo:acme01The last field is the sender ID, required, 5 to 15 characters. Up to three optional identifiers go in front of it. The mail has to be DKIM-signed by a domain you own and have verified in Postmaster Tools. The sending IPs also have to be in that domain's SPF record and have PTR records, and the data covers @gmail.com recipients only. An identifier shows up for a day only when it had enough volume and enough spam reports, so small campaigns may never appear at all.
I give each identifier a meaning I will still understand at two in the morning (campaign type and audience, usually), because a spike on an ID called c1 helps nobody. The view can be grouped by From header domain or by all signed domains, and comparing the two is a quick way to catch mail signed by some domain other than the one readers see.
Authentication and encryption
SPF, DKIM and DMARC pass rates live on the authentication dashboard, as a share of all your mail. Google's own note is that senders with a correct setup typically reach 95% or higher on DKIM and DMARC. Below that, go hunting. The culprit is rarely the main campaign, and the DMARC aggregate reports name the IPs that sent the failing mail. The fix lives in DNS and in that tool's settings, and the alignment part is covered in the SPF, DKIM and DMARC post.
Encryption shows how much of your authenticated mail travelled over TLS, inbound and outbound. On any current sending platform it sits at the top of the chart and stays there. A dip usually means some old relay still speaks plain SMTP.
Delivery errors
Here Gmail lists the reasons it rejected or deferred your mail. They are rate limit exceeded, suspected spam, possibly spammy content and a bad or unsupported attachment. The rest are about your setup rather than the message, which covers the DMARC policy of the sending domain, low IP or domain reputation, a domain or IP on public blocklists, and a bad or missing PTR record.
I trust this dashboard more than the others. Every line on it is a decision Gmail made and then told you about. Rate limit errors right after a volume jump mean slow down and spread the send over more hours. A blocklist reason sends me to the checks in the blocklist post. A PTR reason is a ticket for whoever controls the IP range.
Low reputation is still on that list, so Gmail goes on making the judgement while the chart that showed it waits for its replacement.
The reputation charts, and the API
The deprecation notice explains the decision. According to Google, reputation data was hard to act on for most senders, it moved slowly after behaviour changed, and it could mislead, because reputation is only one of many factors in delivery. I don't find that unfair. I have seen "High" domain reputation next to a campaign sitting in spam over a single broken DKIM key, and a sender whose mail kept landing in the inbox while its chart said "Low".
If you pulled reputation into your own dashboards through the v1 API, the v2 API has nothing to replace that series with yet. It covers everything else, and the v1 API is scheduled to go, so a script that still calls it needs moving before Google picks the date.