Google Postmaster Tools is a free service from Google that reports what Gmail's filters have concluded about the domains you send from. It is the only place Google publishes any part of that judgment back to a sender. Everything else you can measure about Gmail placement is inference, so this is worth setting up properly even when the graphs come back empty.
Sender reputation is the standing a mailbox provider assigns your sending domain and your sending IP, built from how it has seen you send and how its users have responded to you. Google reports its version of that as a band rather than a score. Nobody outside Google sees the underlying model, and no other provider publishes anything comparable.
This page covers the whole tool. How to add and verify a domain, which domain to add, what each dashboard is measured on, how long the data lags, what the tool does not cover at all, and what I do with the readings once they arrive. I have written it in the order you actually meet these problems, starting with setup and ending with the two readings that most often get interpreted backwards.
One thing shapes how I read all of it. I monitor Postmaster across a large set of client domains through the API rather than opening dashboards one at a time, so I see the distribution of what these graphs look like across many senders instead of the shape of a single account. That changes what counts as normal, and several of the numbers below come out of that dataset.
Google Postmaster Tools is a free Google service that reports how Gmail treats mail from domains you own. It shows domain and IP reputation, user-reported spam rate, authentication pass rates, encryption, delivery errors and compliance with Google's sender requirements. The data covers messages sent to personal Gmail accounts only, and you verify each domain through DNS.
It runs no tests and makes no recommendations. It is a reporting surface for measurements Google was already taking, published back to the domain owner in aggregate form so that individual recipients stay private. Most people arrive expecting something that will tell them what to fix.
That framing matters because it sets what the tool can be used for. Postmaster answers questions of the form "what has Gmail observed about my sending recently". It does not answer "why is this message in spam", and it never will, because the data is aggregated by design rather than by omission.
Google makes it necessary in practice as well. Its sender guidelines tell bulk senders to keep the spam rate reported in Postmaster Tools below 0.3%, which means the published threshold every large sender is measured against is only observable here. A sender above 5,000 messages a day to personal Gmail accounts is being held to a number they cannot see anywhere else.
Sign in at the Postmaster Tools site with a Google account, open Manage Domains, click Add new domain, and enter the domain you authenticate mail with. Google then gives you a TXT or CNAME record to publish in that domain's DNS. Verification usually completes immediately, and Google says it can take up to ten minutes.
You need either a Google account or a Google Workspace account, and nothing else. There is no application and no minimum size to qualify. The setup cost is one DNS record per domain.
Once a domain is verified you can add other people to it, which is worth doing at the start rather than later. Access is granted per domain and only on verified ones, so an agency or a contractor can be given the reporting view without anyone sharing a login. This is how I get read access to a client's real data instead of working from screenshots.
The part that trips people up is not the mechanics. It is that the tool starts recording from the moment Google has traffic to report, not from the moment you sign up, so a domain added during an incident gives you an incident with no baseline behind it. Adding every sending domain you own before you need them is the single highest-value thing you can do with this tool, and it takes a few minutes per domain.
Add the domain that authenticates your mail, which is the DKIM signing domain in the d= tag or the SPF domain in the Return-Path. That is frequently not the domain in your From address. Google states this directly, and adding the wrong one produces an empty dashboard that looks identical to having no traffic.
On most sending platforms these are different domains. Your From address might be hello@yourcompany.com while the Return-Path resolves to a subdomain your platform controls, and the DKIM signature may be issued by either. If you added yourcompany.com and your platform signs as mail.yourcompany.com, Google has data and you are looking at the wrong page.
Reading the headers of a message you actually sent settles it in under a minute. Send yourself a copy through the platform in question, open the original, and look at the d= value in the DKIM-Signature header and the Return-Path address. Those are the domains to add. If you want the same information without reading headers, the DNS and authentication checker resolves the authentication records for a domain and shows which ones are actually published.
Add all of them where they differ. There is no penalty for having several domains verified, each gets its own reputation history, and a sender running marketing mail on a subdomain and transactional mail on the root domain needs both graphs to make sense of either. Reputation follows each domain separately, which is the whole reason subdomain separation is worth doing in the first place.
Usually because you are not sending enough mail to Gmail for Google to report on it. Google withholds data on low-volume days to protect user privacy, and it does not publish the volume required. An empty dashboard is a statement about your volume far more often than it is a statement about your setup.
This is the most common question I get about the tool, and the answer is more reassuring than people expect. Of 160 domains connected to Postmaster in my monitoring account, 104 produce no reporting data at all. Only 56 send enough mail to Gmail for Google to report anything, which is why "my Postmaster is empty" is usually a volume fact rather than a setup fault.
Google's own wording is that data might be missing if the total number of messages for a given day is too low, and that this is to protect users' privacy. It has never published the threshold. My reading of the dataset is consistent with that: the domains producing data are the ones with real Gmail volume, and the ones producing nothing are not broken.
There are three causes and they are easy to tell apart, which is worth doing before you conclude anything about your sending.
A fourth possibility is worth naming because it produces partial rather than empty data. Postmaster reports sparsely at low volume, so a domain sitting just above the reporting floor gives you readings on some days and nothing on others. Consecutive readings in that situation are not consecutive days, and any trend you draw through them is drawn through gaps.
Postmaster Tools has eight dashboards. Compliance Status, Spam Rate, IP Reputation, Domain Reputation, Feedback Loop, Authentication, Encryption and Delivery Errors. Each one reports a different measurement on the same traffic, and they disagree with each other often enough that reading only the reputation graph is how most senders miss what is actually happening.
Google's own definitions are worth having in one place, because several of them are narrower than the dashboard name suggests.
| Dashboard | What Google says it measures | What I use it for |
|---|---|---|
| Compliance Status | Compliance with the email sender requirements in Google's sender guidelines | A fast read on whether the bulk-sender requirements are met before I look at anything else |
| Spam Rate | The percent of your messages that recipients manually mark as spam in Gmail | The number Google holds you to, read next to volume rather than alone |
| IP Reputation | The quality rating for the IP addresses you use to send email | Whether the problem belongs to a shared pool rather than to you |
| Domain Reputation | The quality rating for the domains you use to send email | The slow signal that tells me how long a recovery will take |
| Feedback Loop | Email campaign messages that recipients have marked as spam | Which specific campaign or customer is generating the complaints |
| Authentication | The percent of your email that passes SPF, DKIM and DMARC authentication | Confirming alignment holds across all mail, not just the test message I sent |
| Encryption | The percent of your email that is sent over an encrypted SSL or TLS connection | Rarely the problem, and a quick sanity check on a misconfigured relay |
| Delivery Errors | The percent of all authenticated messages that were rejected or temporarily failed | Gmail rejecting mail at its own edge, which is a different event from a bounce on your list |
Two of these are narrower than they look. Delivery Errors counts rejections and temporary failures at Gmail's edge, so it is not a bounce rate in the sense your sending platform uses that phrase, and the two numbers will never match. If you want the distinction between the failure types your own platform reports, that is soft bounce versus hard bounce, and a specific rejection like 550 5.7.1 means something different again.
The Spam Rate dashboard has a measurement detail that changes how the graph should be read, and it catches experienced senders. Google's spam rate is measured against messages delivered to the inbox rather than against everything sent. As more mail is filtered to spam the denominator shrinks, so the reported rate can rise while the absolute number of complaints falls. I have written up how that interacts with filtering in how the Gmail spam filter actually decides, which covers the scoring side of this in more depth than belongs here.
Read it as a slow-moving band rather than a daily score. Google reports domain reputation and IP reputation separately, each as bad, low, medium or high, and the band reflects sending history rather than your last campaign. A single day tells you almost nothing. Two weeks of readings tells you what you need.
Google defines the four bands by spam history. High is a history of very low spam rates and compliance with the sender guidelines. Medium is a history of legitimate email that occasionally sends spam. Low is a history of sending a significant volume of spam regularly, and bad is a history of sending a high volume of spam regularly.
The word history is doing the work in all four definitions. Across 50 domains I monitor in Google Postmaster Tools, the reported reputation band changed 13 times in 703 consecutive readings over a seven-week window in 2026. A band is a slow-moving state. One day's reading tells you very little, and two weeks of them tell you almost everything.
That stability is the practical reason to check reputation early even though you cannot move it quickly. Knowing on day one that you are looking at a multi-week recovery changes what you do in week one, and it stops you from reading normal day-to-day noise as a response to something you just changed.
It also helps to know what the distribution looks like, because a single account gives you no sense of whether your reading is unusual. Across 753 domain-days of Postmaster readings on the domains I monitor, 66.5% sat at high reputation, 14.9% at medium, 10.2% at low and 8.4% at bad. Those are domain-days rather than domains, so a domain reporting on many days weighs more than one reporting once, and the figure describes the shape of the data rather than the share of senders.
A low or bad band is not a verdict on your business, and it is not permanent. It is a statement that Gmail's recent history of your domain contains enough spam signal to sit below the line, and the same slowness that makes it hard to fix quickly also means it does not collapse from one bad day. The six causes that put a domain there are covered in the most common causes of Gmail spam placement.
Add a Feedback-ID header to your outgoing messages, in the form a:b:c:SenderId, where the last field identifies you and the earlier ones identify a campaign, a customer or a mail type. Your mail must be DKIM signed by a domain verified in Postmaster Tools. Google then reports spam rates per identifier.
This is the most underused part of the tool and the one that answers the question senders actually have. The Spam Rate dashboard tells you that complaints happened. The Feedback Loop dashboard tells you which stream of mail produced them, which is the difference between knowing you have a problem and knowing where it is.
Google aggregates on the first four fields of the header reading from the right, and the rightmost field, the SenderId, is required and runs five to fifteen characters. The three fields to the left of it are yours to define. Google's own suggestion is campaign, customer and mail type, which is a sensible default if you have no strong opinion.
Two conditions gate the data appearing. The mail must be DKIM signed by a domain you have verified in Postmaster Tools, which is Google's protection against a sender claiming another sender's identifiers, and the identifier needs both a certain volume of mail and distinct user spam reports on a given day before a report is generated. A low-volume identifier will show nothing for the same reason a low-volume domain does.
Setting this up costs one header on the sending side and nothing else. Most sending platforms either set it for you or expose a field for it, and if yours does neither, that is worth knowing before an incident rather than during one.
Google says data is typically updated within 24 hours but can take longer, and that compliance status changes can take up to 7 days to appear. Treat every graph as a description of the recent past. Nothing you change today shows up today, which matters when you are trying to attribute a movement to a send.
The compliance lag is the one that causes the most confusion. A sender fixes a DMARC record, refreshes Compliance Status, sees no change and concludes the fix did not work. It can take a week, and republishing the record in the meantime adds a second change to attribute rather than clarity.
The general lag has a subtler effect on how you read reputation. Because the data describes the recent past and a band already reflects a rolling history, a reputation reading is a lagged view of a lagging measure. When I want to know whether something changed after an intervention, I plan on reading it a week later rather than the next morning.
This is also why the tool is poor at telling you about right now and good at telling you about the last month. During a live incident I use Postmaster to establish what state the domain was in going into it, then work from signals that move faster. Reputation is the context. It is rarely the thing that tells you what happened yesterday.
Everything except mail to personal Gmail addresses. Google states the data applies only to accounts ending in gmail.com or googlemail.com, so recipients on Google Workspace domains are outside it and a business sender can be reading a dashboard built from a small minority of its own traffic. There is also no per-message detail.
The Workspace exclusion is the one that changes conclusions. A company selling to other companies may send most of its mail to addresses at corporate domains, many of which run on Google Workspace and are filtered by Google's infrastructure. None of that appears here. The dashboard is real, and it describes a slice of the audience that may not be the slice having the problem.
Nothing outside Google appears at all, which sounds obvious and still catches people. Microsoft, Yahoo and every other receiving system run their own filters against their own thresholds. A clean Postmaster account tells you Gmail is comfortable with you. It is silent on everyone else, and provider divergence is common enough to be diagnostically useful in its own right.
There is no per-message data and never will be. You cannot ask why a specific message was filtered, which recipients complained, or which segment of a list is dragging the average. The aggregation is deliberate, since the alternative would expose individual Gmail users' behaviour to the people mailing them.
The last gap is the one that matters most in practice. Postmaster reports symptoms and does not attribute causes, so every reading it gives you is the start of a question rather than the end of one. The method I use to turn those readings into a cause is the complete diagnostic guide, which runs six checks in a fixed order and stops at the first one that fires.
If you send from more than a handful of domains, yes. The API returns the same metrics the dashboards show, and version two adds date ranges instead of single days, compliance status for SPF, DKIM and DMARC, and statistics for multiple domains in one call. For a single domain, the web dashboards are enough.
The threshold is about upkeep rather than engineering. What decides it is whether checking every domain by hand is something you will still be doing in three months. Opening one dashboard weekly is sustainable. Opening thirty is not, and the domains that stop getting checked are reliably the ones that develop problems quietly.
This is how my own monitoring runs, and it is the reason several of the numbers on this page exist. Reading the same metrics across a large set of domains on a schedule produces a distribution rather than an anecdote, and a distribution is what tells you whether a reading is unusual. A single account cannot tell you that an empty dashboard is normal or that most monitored domain-days sit at high reputation. Many accounts can.
The gain that matters is timing. A threshold crossing gets noticed on the day it happens rather than at the next manual check, which for a slow-moving measure like reputation is often the difference between a correction and a recovery. Version two's batch query makes that cheap enough to run daily across every domain at once.
Send mail that Gmail users want, to people who asked for it, at a volume your engagement supports. Reputation is built from recipient behaviour, so the levers are list quality and send discipline rather than anything you can configure. Authentication is a prerequisite you clear once and then stop thinking about.
That last sentence is worth defending with numbers, because it contradicts where most senders spend their effort. Across 56 domains I monitor, 51 pass SPF, DKIM and DMARC on 100% of measured mail on a median day, and 2 fall below 95% on any of the three. Authentication is almost never the thing that is broken. It is checked first because it is the fastest to rule out, not because it is the most likely cause.
So the Authentication dashboard is usually green. A green Authentication dashboard means the cheapest thing on the list came back clean, and it carries no information about the causes further down. If you do have a genuine authentication fault, the ones I see most often are covered in the SPF mistakes that make things worse, and the mechanisms themselves in what DKIM is and what DMARC is.
The complaint rate is the reading that actually moves things, and the population I see is not reassuring on this point. Of the domains that come to me for monitoring, 16 of the 19 for which Gmail reports a user-reported spam rate at all sit at or above Google's 0.3% line on a typical reporting day, and the median of those domains' own medians is 0.8%. That is not what a healthy sender looks like. It is what most senders look like by the time they call me.
Google's guidance is stricter than the headline number implies. The sender guidelines state 0.3% as a violation line to avoid ever reaching, and recommend staying below 0.1%, which is the actual headroom rather than the threshold. Treating 0.3% as a target is how senders end up living permanently at the edge of a limit they should never approach.
What moves the number is unglamorous. Stop mailing addresses that have not engaged in months, and make the unsubscribe easy enough that complaining is the harder option. Then raise volume only as fast as engagement holds up at each step, which is the whole argument in what most warmup guides get wrong and applies to an established domain as much as to a new one.
If your IP reputation is the weak reading rather than your domain reputation, the lever is different and may not be yours to pull. That case is shared IP pools and when your reputation is not yours.
Both of these look like good news on the graph, and both are the moment to slow down rather than to relax. They come up often enough that I check for them specifically before accepting any improvement in a Postmaster account.
The first is a spam rate that drops to zero after a spike, which is not automatically good news. Too little inbox-delivered volume to register a rate produces the same reading as no complaints, so a zero after a spike is verified against send volume before it is called a recovery. Heavy filtering can empty the denominator entirely, and a domain whose mail is now almost all going to spam can report a cleaner number than it did while it was still reaching people.
The second is the Authentication dashboard at 100%. It measures the mail that arrived at Gmail in enough volume to be reported on, which is not the same as all the mail you send. A sending source that never reaches Gmail cannot fail here, and a stream too small to report cannot fail here either. I have looked at accounts showing perfect authentication where an entire secondary sending platform was misconfigured and simply invisible to the dashboard.
Both readings share a structure worth naming, because it generalises to everything in this tool. Postmaster reports on the mail Google saw, in the volumes Google was willing to report, after a delay. A number that improves because the underlying population changed is a different event from a number that improves because your sending got better, and the graph shows you both the same way.
The way to tell them apart is to read every metric against volume. Not against the previous reading, and not against a threshold. Volume is what the denominators are built from, and it is the one column that makes an improving number legible as either a recovery or a symptom getting worse.
Yes. It costs nothing and needs only a Google account or a Google Workspace account. There is no paid tier, no sending relationship with Google required, and no connection to Google Ads or Search Console. The only setup cost is publishing a verification record in the DNS of each domain you want reported on.
No. Google states that the data applies only to messages sent to personal Gmail accounts, meaning addresses ending in gmail.com or googlemail.com. Mail you send to a company running on Google Workspace is filtered by Google but does not appear in these dashboards. A business-to-business sender can be reading a dashboard built from a small minority of its own traffic.
Yes, and you usually should. Each domain you add is verified and reported on separately, so a subdomain used for marketing mail gets its own reputation graph rather than being folded into the parent. Add whichever domain appears in the DKIM signature or the Return-Path of the stream you want to watch, since that is the domain Google reports against.
Because they are two separate judgments about two separate things. Domain reputation follows your sending domain wherever it sends from. IP reputation belongs to the address the mail left from, which on most sending platforms is a pool shared with other tenants. A high domain reputation on a low-reputation shared IP is common, and it means the pool is the part you do not control.
Google's own documentation is worth reading directly rather than through summaries, since it changes and most third-party guides do not track it. The pages that matter are Set up Postmaster Tools, Postmaster Tools dashboards for the metric definitions, Email sender guidelines for the requirements you are measured against, and the Postmaster Tools API overview if you are reading this programmatically.
On this site, the scoring side of Gmail placement is how the Gmail spam filter actually decides, the symptom-first version of the diagnostic method is the six checks I run when emails are going to spam, and the remedial sequence once you know the cause is how to stop emails going to spam. If you would rather have your own readings interpreted than interpret them yourself, the diagnostic reads them against your sending history and names the cause underneath.