Using Google Postmaster Tools

7 April 2026 · 12 min read

Google Postmaster Tools is the only place Google lets you see, from the inside, how Gmail treats mail from your domain. DMARC aggregate reports tell you what authentication results receivers observed; Postmaster Tools tells you something different and complementary: how Gmail's own reputation systems score your sending domain and IPs, what proportion of your authenticated mail actually passes, and how often real Gmail users mark your messages as spam. If you run any meaningful volume of mail to consumer Gmail addresses, this is a dashboard you should be reading weekly, and it pairs directly with the authentication work DMARC Engine automates.

This article is specifically about reading and acting on Postmaster Tools, not a general deliverability lecture. It assumes you already have SPF, DKIM and DMARC publishing. If you do not, start by confirming your records with the DMARC checker, SPF checker and DKIM checker, then come back, because almost everything Postmaster Tools shows you depends on Gmail being able to authenticate your mail in the first place.

What Postmaster Tools is, and what it is not

Postmaster Tools is a free Google product at postmaster.google.com. It reports aggregate statistics about mail that Gmail received claiming to be from a domain you have verified ownership of. It covers consumer Gmail (the @gmail.com audience) and, with caveats, Google Workspace recipients whose admins have not opted their organisation out of contributing data.

It is genuinely useful for a specific set of questions:

Is Gmail authenticating my mail (SPF, DKIM, DMARC pass rates)?
Does Gmail consider my domain and sending IPs reputable?
Are real Gmail users marking my mail as spam, and how often?
Is my mail being encrypted in transit (TLS)?
Are there delivery errors Gmail is rejecting or deferring on?

It is not a per-message log. You will never see which recipient complained, which subject line triggered a spam flag, or whether a specific campaign landed in the inbox or the Promotions tab. Postmaster Tools deliberately does not report inbox-versus-spam placement at all. That is a common misunderstanding worth stating plainly: a green "High" reputation does not mean your mail reaches the primary inbox, and Postmaster Tools will not tell you your tab placement. It tells you whether Gmail trusts you and whether users complain, which are inputs to placement, not placement itself.

It is also a thresholded product. Most dashboards only populate once you send a sustained volume to Gmail, on the order of hundreds of messages a day. Below that, you will see "Not enough data" on most charts. That threshold is a privacy measure: Google will not show statistics it could trace back to a handful of recipients. Low-volume senders get little from Postmaster Tools and should lean instead on DMARC aggregate data, which has no such floor.

Setting it up: verify the right domain

You add a domain and verify ownership by publishing a TXT record (or CNAME) that Google provides, exactly the same mechanism as Search Console. Two points that trip people up:

Verify the domain that appears in the From header, not the sending service's domain. Postmaster Tools keys everything on the header_from domain, the same domain DMARC aligns against. If your newsletters go out from news.example.com, verify news.example.com. If your application mail comes from example.com, verify that. If you send from several distinct From domains and subdomains, add each one separately; they are scored independently by Gmail and you want to see them independently.

Use a DNS TXT verification you can keep. Do not remove the verification record after it goes green. If it disappears, your dashboard eventually stops updating. If you delegate DNS to DMARC Engine, the verification record sits alongside your other authentication records and is not disturbed by the SPF, DKIM and DMARC management.

Once verified, expect a lag. Data is delayed by two to three days and is shown per UTC day. You are always looking slightly into the past, which matters when you are trying to correlate a reputation drop with a specific send.

The dashboards, and how to read each one

Postmaster Tools presents several charts. Taken individually each is a blunt instrument; taken together they form a coherent diagnostic. Here is what each one means and, crucially, what action it should drive.

Spam rate

This is the single most important number on the entire dashboard. It is the proportion of your authenticated mail that Gmail users marked as spam, by clicking "Report spam" or by Gmail moving it to spam on their behalf, measured against mail that landed in the inbox.

Google's own bulk-sender requirements set a hard line here: keep your user-reported spam rate below 0.10%, and never let it reach 0.30%. These are not vanity targets. Since the February 2024 Gmail and Yahoo bulk-sender rules, exceeding them puts your delivery to Gmail at direct risk. A spam rate that touches 0.3% is the kind of thing that turns into mail silently landing in spam folders within days.

A practical reading of the chart:

Consistently under 0.1%: healthy. Leave it alone.
Drifting up towards 0.2% to 0.3%: investigate now, do not wait. Usually this is a list-hygiene or consent problem: you have started mailing an older segment, bought or imported a list, or removed a clear unsubscribe path.
Spiking on a specific day: correlate with what you sent two to three days earlier (remember the lag). A single bad segment or a misjudged campaign shows up as a spike.

The fix for a high spam rate is almost never technical authentication; it is who you are mailing and whether they asked for it. But authentication is the prerequisite for the number to even be meaningful: Gmail only attributes spam complaints to a domain it can authenticate. This is one reason getting to a clean DMARC p=reject posture matters, covered in reaching p=reject without breaking email.

Domain reputation and IP reputation

Gmail reports reputation in four bands: High, Medium, Low, Bad. There are two separate scores, one for your sending domain and one for each sending IP, and they can disagree, which is informative.

Domain reputation reflects how Gmail judges the From domain over time: complaint history, authentication, consistency of sending, and content signals. This follows your domain even if you change sending infrastructure, which is exactly why a warmed, reputable domain is an asset you protect.
IP reputation reflects the specific IP addresses your mail comes from. If you use a shared pool at an ESP, this score is partly hostage to other senders on the same IPs. If you use dedicated IPs, it is yours alone to build and to wreck.

How to read the combinations:

Domain High, IP High: the goal state. Nothing to do.
Domain High, IP Low or Bad: your content and audience are fine, but the IPs are dragging you down. On a shared ESP pool, this can be a noisy-neighbour problem; raise it with the provider or consider a dedicated IP if your volume justifies one. On your own IP, you may have a compromised account or a warm-up that went too fast.
Domain Low or Bad, IP High: the infrastructure is clean but Gmail distrusts the From domain itself. This is the worse situation, because domain reputation is slower to repair. It usually traces back to a sustained spam-rate problem or a period of sending to bad addresses.
Anything showing Bad: treat as an incident. Stop low-value sending, mail only your most engaged, recently-active recipients, and let the score recover over days to weeks.

Reputation moves slowly and asymmetrically: it falls faster than it climbs. There is no button to reset it. The only lever is sustained good behaviour over time.

Authentication: SPF, DKIM and DMARC

These three charts show the percentage of your mail to Gmail that passed each mechanism. This is where Postmaster Tools overlaps with DMARC aggregate data, and where the two should agree. If they disagree wildly, one of your sources is misconfigured.

What "good" looks like:

SPF, DKIM and DMARC pass rates at or very near 100% for mail you actually send. Anything materially below that means a sending source is not aligned.
A DKIM pass rate well below 100% typically means one sending stream is unsigned or signs with a key Gmail cannot find. Confirm the selector with the DKIM checker and review DKIM selectors explained.
An SPF pass rate below 100% can mean a sender is missing from your SPF record, or you have crossed the ten-lookup limit and Gmail is hitting a PermError. See fixing SPF PermError and the SPF checker.
A DMARC pass rate that lags both SPF and DKIM points at an alignment problem rather than a raw-authentication problem: SPF or DKIM passes, but on a domain that does not match your From domain. This is the alignment trap, and DMARC alignment explained is the article for it.

One important nuance: Postmaster Tools shows authentication for the mail Gmail received under your domain, which can include forwarded mail and, occasionally, spoofed mail. A small percentage of authentication failure is often legitimate forwarding rather than a misconfiguration on your side. To tell the difference, you need the per-source breakdown that DMARC aggregate reports give you. Paste your reports into the DMARC report analyzer and you can see which specific senders fail, something Postmaster Tools cannot show. The relationship between report data and real-world failures is covered in forwarding and DMARC and why DKIM fails after forwarding.

Encryption (TLS)

This chart shows the percentage of your outbound mail to Gmail that was delivered over a TLS-encrypted connection. In practice this should be at or near 100% for any modern sending platform, because Gmail and every reputable ESP negotiate STARTTLS by default.

If this number is meaningfully below 100%, you have an outbound MTA or relay that is sending in the clear, which is both a privacy problem and an increasingly visible deliverability signal. The structural fix for guaranteeing encryption to your domain is MTA-STS, which tells sending servers to require TLS and refuse to fall back to plaintext. You can check whether your domain publishes a policy with the MTA-STS checker, and the hosted MTA-STS product manages the policy and reporting for you.

Delivery errors

This chart breaks down the reasons Gmail rejected or temporarily deferred your mail, as a percentage of attempts. Common buckets include rate limiting ("our system has detected an unusual rate of unsolicited mail"), reputation-based rejection, and policy rejections.

A rising error rate is an early-warning light. Rate-limiting deferrals during a big send are normal and self-correct as your sending paces out. Reputation rejections that persist are not normal and mean Gmail has decided to throttle you; they almost always coincide with a Low or Bad reputation band and a high spam rate, and they are resolved by fixing those underlying problems, not by retrying harder.

Postmaster Tools and DMARC: use both, for different jobs

It is worth being explicit about the division of labour, because teams often think one replaces the other. They do not.

DMARC aggregate reports are sent by every participating receiver, not just Gmail: Yahoo, Microsoft, corporate mail systems, and thousands of others. They tell you, per sending source IP, exactly which senders are authenticating and aligning and which are not, across your whole sending estate and across the whole internet. They are the tool for discovering shadow IT, catching spoofers, and safely tightening your policy from p=none to p=reject.

Postmaster Tools is Gmail-only and aggregated at the domain level. It cannot tell you which individual source failed. But it tells you things DMARC reports never will: Gmail's reputation verdict, the user-reported spam rate, and TLS coverage to Gmail specifically.

A concrete workflow that uses each for what it is good at:

Use DMARC aggregate reports (via the report analyzer) to find and fix every unaligned sending source, then move to enforcement. This is the foundation.
Use Postmaster Tools spam rate as your ongoing health metric for the Gmail audience, watching the 0.1% line.
When Postmaster Tools shows a reputation or authentication dip, cross-reference the DMARC data to find the specific source responsible, because Postmaster Tools tells you that something is wrong and DMARC tells you which source.
Use DMARC Engine monitoring to get told about changes automatically rather than logging into either dashboard hoping to spot a trend by eye. See monitoring and change alerts and the monitor feature.

A practical action plan when something goes wrong

Reputation drops and spam-rate spikes feel alarming because the dashboard offers a verdict but no explanation. Here is a disciplined response that works far more often than panic.

If the spam rate spikes:

Identify the send that landed two to three days before the spike (account for the reporting lag).
Ask the only question that matters: did those recipients ask to hear from you, recently? Re-engagement sends to dormant lists are the most common cause.
Stop mailing the implicated segment. Tighten to engaged recipients only (opened or clicked in the last 30 to 90 days).
Confirm there is a one-click unsubscribe header and a visible unsubscribe link. Since the 2024 bulk-sender rules, one-click list-unsubscribe is mandatory for bulk senders to Gmail. Its absence drives complaints because the only way to stop your mail becomes the spam button.

If domain or IP reputation drops to Low or Bad:

Confirm authentication is still at 100% on the SPF, DKIM and DMARC charts. A sudden authentication failure (an expired DKIM key, a broken SPF record after a vendor change) can tank reputation fast. Re-check with the DMARC checker and review DKIM key rotation.
Check the DMARC aggregate data for a new sending source you did not authorise. A compromised account, a rogue marketing tool, or actual spoofing all show up here first. Unknown sources are explained in DMARC reports show unknown sources.
Reduce volume to your best recipients and hold steady. Reputation recovers through consistent, low-complaint sending, not through dramatic action.

If authentication pass rates are below 100%:

This is the one category where the fix is squarely technical and squarely in DMARC Engine's wheelhouse. Work through your sources with the report analyzer, bring every legitimate sender into alignment, and confirm with the relevant checker. The enforcement journey documents the full path from broken authentication to a clean p=reject.

Where Postmaster Tools fits in the bigger picture

Postmaster Tools is a window into Gmail's opinion of you, and Gmail is a large enough audience that its opinion is worth tracking closely. But it is a read-only window. It diagnoses; it does not fix. Every problem it surfaces is solved upstream: by authenticating every sender so the authentication charts read 100%, by enforcing DMARC so spoofers cannot borrow your reputation, by requiring TLS so the encryption chart stays green, and by mailing only people who want your mail so the spam rate stays under 0.1%.

That upstream work is exactly what DMARC Engine is built to do, and to keep doing without you watching dashboards every day. The authentication that makes Postmaster Tools' charts meaningful, getting SPF, DKIM and DMARC to align across every sending source and holding a safe path to p=reject, is managed for you, with emailed monitoring that flags a reputation-relevant change before it shows up as a spike on Google's graph. See whether you are configured correctly for Gmail's requirements on the sender requirements page, and verify your current setup in two minutes with the DMARC checker.

The practical takeaway: add Postmaster Tools, verify the domain in your From header, and read three numbers in order every week, spam rate first (stay under 0.1%), then domain and IP reputation, then your authentication pass rates. When any of them moves, do not act inside Postmaster Tools, because you cannot; act on your authentication and your sending list, and let the dashboard confirm, a few days later, that the fix worked.