Google Postmaster Tools: Setup and Reading the Reputation, Spam Rate, and Encryption Dashboards
Postmaster Tools is Gmail's own telemetry leaking back to you — the only place Google shows the reputation, spam-complaint, and TLS numbers it judges your mail on. Here's how to verify the right domain, force enough volume to get data, and read each panel as a leading or lagging signal with concrete action thresholds.
EvilMail TeamJuly 13, 202611 min read
The one number Gmail actually shows you — and why it's usually blank
Every "our emails go to spam at Google" ticket starts the same way: someone forwards a screenshot of a message sitting in their own spam folder and asks you to fix it. You can stare at headers all day, but Gmail's spam classifier is a black box reading signals you can't see from the outside — user complaints, engagement, spam-trap hits, per-domain reputation history. There is exactly one place Google leaks those signals back to the sender, and it's Google Postmaster Tools.
Set expectations before you log in. Postmaster Tools is diagnostic telemetry, not a control panel. There is no button that says "deliver my mail." What you get is the reputation, complaint, authentication, and encryption numbers Gmail computes on *your* traffic, and four facts govern everything you'll read there:
It reports on the authenticated domain, not your brand. The scored domain is the DKIM d= domain and the SPF-aligned RFC5321.MailFrom (Return-Path), never the visible From: header your recipients see.
The dashboards need roughly 100+ messages per day to the same Gmail/Workspace domain before any chart renders. Below that you get a blank panel — which low-volume senders constantly misread as "we're healthy." Blank is *no data*, not a clean bill.
The data lags about 24 hours, and some panels 2–3 days. By the time the reputation bucket turns red, you've already been foldering for a while.
It covers Gmail and Google Workspace only. Outlook/Hotmail deliverability lives in Microsoft SNDS; Yahoo has its own feedback loop. Postmaster tells you nothing about either.
That last-mile scoring detail burns more senders than anything else, so pin it down before touching DNS.
If you send through a shared ESP subdomain that also signs mail for a spammer down the hall, *their* complaints land on the reputation bucket you share. Running your own signing domain — the whole point of self-hosted infra like evilmail.pro — is what gives you a reputation nobody else can poison.
Verifying the domain (TXT vs. the Search Console shortcut)
Go to postmaster.google.com, click the "+", and enter the domain. You have two verification paths.
DNS TXT record. Google hands you a token; publish it on the domain apex:
dns
evilmail.pro. IN TXT "google-site-verification=xxxxxxxxxxxxxxxxxxxx"
Confirm it's live before clicking Verify — propagation delay is the usual reason verification "fails":
Search Console inheritance. If the domain is already a verified property in Google Search Console, Postmaster Tools accepts that verification with no new record. Fastest path if your web team already owns the property.
The gotcha that catches engineers: verify the sending domains, not just the website apex. Postmaster scores whatever domain appears in d= and Return-Path. If you sign as evilmail.pro, bounce through bounce.evilmail.pro, and run a marketing stream signed as mail.evilmail.pro, those are three separate reputation entities. Add each as its own property:
Once verified, use delegation to add teammates read-only instead of sharing one login. Support and marketing should see the dashboards without holding DNS-level access to your zone.
Reading the Domain Reputation panel
Four buckets, each mapping to a real placement outcome:
High — Gmail trusts this domain. Inbox placement is as good as it gets. Ship.
Medium — a problem is *brewing*. Content, list hygiene, or an engagement dip is pushing you toward the edge. Audit now, while placement is still fine.
Low — you're already foldering a meaningful share of mail. Freeze cold-list and reactivation traffic; send only to engaged recipients until it recovers.
Bad — effectively near-blocked at Gmail. Stop the sends causing it and remediate before you burn the domain further.
Two properties matter operationally. First, it's scored per authenticated domain, so a single bad segment on mail.evilmail.pro won't necessarily drag evilmail.pro. Second, it trails and recovers slowly — reputation degrades on days of complaints and spam-trap hits, and climbs back only over days-to-weeks of clean, engaged volume. There is no fast reset. That's why it's a lagging indicator: the spam folder gets you *before* the bucket goes red.
Don't confuse it with the IP Reputation panel beside it. IP reputation matters for dedicated sending IPs — a self-hosted relay on a static address, exactly the evilmail.pro model. On a shared ESP pool your mail rides hundreds of other IPs and the panel is near-meaningless noise. On your own relay it's the first thing to check after a hosting migration or a new IP allocation.
Spam Rate — the only number your recipients control
Spam Rate is user-reported: spam-marks divided by messages delivered to the inbox. It's the single metric your recipients drive directly by hitting "Report spam," and Google weights it heavily.
The numbers to memorize, straight from Google's 2024 bulk-sender requirements (still enforced in 2026 for anyone sending 5,000+ messages/day to Gmail):
Keep it under 0.10%. That's your operating target.
0.30% is the enforcement line. Cross it and Gmail throttles and folders in bulk. Treat 0.30% as a fire alarm, not a ceiling to aim for.
Read it as a spike detector, not an average. One bad campaign to a stale segment shows up as a single-day cliff, not a gentle slope — so scan the shape, not just today's value. The pressure-release valve is one-click unsubscribe (RFC 8058): make leaving trivial and people unsubscribe instead of complaining, which keeps marks off this chart.
One counterintuitive trap: the denominator is inbox-delivered mail. When your reputation improves and more mail reaches the inbox instead of spam, the visible spam rate can *rise* even though nothing got worse — you've simply exposed more mail to the "Report spam" button. Read it alongside reputation, never in isolation.
Authentication & Encryption dashboards
The Authentication panel shows a pass percentage per mechanism — SPF, DKIM, and DMARC — each as a share of your Gmail-bound volume. Read them like SLOs:
SPF or DKIM below ~99% means a stream is misconfigured or mail is being forwarded (forwarding breaks SPF and sometimes DKIM). Find the stream — a transactional path signing with the wrong selector, a third-party tool sending as you without a DKIM key, a marketing platform outside your SPF include.
DMARC alignment failures here predict quarantine. If DMARC pass sits well under SPF/DKIM pass, you have *authenticated but unaligned* mail — the d= or MailFrom domain doesn't match From:. That's precisely what a p=reject policy will drop.
Verify your records from the shell before trusting the panel:
Strict alignment (adkim=s; aspf=s) is the right posture once your streams are clean — it's what makes the Postmaster DMARC number trustworthy. fo=1 sends a failure report whenever any auth mechanism fails, which is gold when hunting a leaky stream.
The Encryption panel shows inbound and outbound TLS percentages. Target 100% outbound. A dip means a downstream MTA hop negotiated cleartext — usually a receiver with a broken or expired certificate, or your own relay falling back. On Postfix the baseline is opportunistic TLS, upgraded to DANE where the receiver publishes DNSSEC-signed TLSA records:
ini
# opportunistic (baseline)
smtp_tls_security_level = may
smtpd_tls_security_level = may
# DANE — authenticated TLS via DNSSEC/TLSA (preferred where available)
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
Close the loop with MTA-STS and TLS-RPT so *your* inbound mail can't be silently downgraded, and so you get reports when someone tries:
dns
_mta-sts.evilmail.pro. IN TXT "v=STSv1; id=20260704T000000;"
_smtp._tls.evilmail.pro. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
The MTA-STS policy lives at https://mta-sts.evilmail.pro/.well-known/mta-sts.txt with mode: enforce. Together they turn "we hope TLS happened" into a number you can audit, and the Encryption panel becomes your outbound proof.
A weekly reading routine
Open the panels in causal order, not alphabetical order. When something looks off, you're tracing a chain backwards from symptom to cause.
Open Spam Rate first. Scan for a single-day spike. Under 0.10% is green; anything approaching 0.30% is a stop-sends event.
Then Domain Reputation. High = continue. Medium = audit list and content this week. Low = freeze cold traffic. Bad = halt and remediate.
If reputation dropped, correlate. Reputation dip → find the Spam Rate spike → identify which campaign or segment fired that day → check the Auth panel for a broken stream at the same time.
Check Authentication. SPF/DKIM under 99%, or DMARC lagging behind them, means a misconfigured or forwarded stream. Confirm with dig, not the panel alone.
Check Encryption. Below 100% outbound → find the downstream hop doing cleartext; cross-reference TLS-RPT.
Cadence: weekly as a baseline; daily during an IP/domain warmup or in the 72 hours after any large send.
Keep the leading-versus-lagging frame in front of you the whole time. Spam Rate and the Auth panels move first — they're your early-warning system. The reputation bucket is trailing confirmation that the damage already landed. If you're only watching the color of the reputation label, you're reading yesterday's news about a fire that started last week.
