Google Postmaster audit: what to look for & what to fix

Google Postmaster is the highest-signal free tool in outbound deliverability, and most operators look at it exactly once — when something breaks. That’s backwards. The audit below is what I run every Monday morning before anything else on the outbound stack.

It takes 12 minutes. It catches 80% of the deliverability problems at least 3–4 weeks before anyone notices a reply-rate drop.

Here are the seven Postmaster signals I read, what “healthy” looks like on each, what each red flag actually means, and the specific fix I go to.

Before you start: you need verified ownership of the domain in Postmaster, and at least 14 days of send volume from mailboxes on that domain to Gmail inboxes. If you just bought the domain or haven’t been sending to Gmail yet, you’ll see “Not enough data” on most tabs — that’s normal, wait it out.

Signal 1 — Domain reputation

What healthy looks like

High, green, for at least 14 consecutive days. Occasional dips to Medium are tolerable if volume changed (e.g. weekend send throttling) — sustained Medium is the real signal.

Red flags

• Sustained Medium (> 7 days). You’ve been hitting complaint thresholds or spam traps. Sending volume is probably too high, copy is triggering spam filters, or some of your targets flagged the email.
• Low, any duration. You’re in trouble. Gmail is already filtering your mail to spam for most Gmail recipients. Do not keep sending from this domain — you’re compounding the problem.

Fixes in priority order

1. Pause the affected domain’s sending for 72 hours. Let the reputation stabilise before anything else. Yes, this costs you a day of pipeline. It’s cheaper than burning the domain.
2. Check your complaint rate (signal 3 below) first. Most domain-reputation drops trace back to a complaint spike. Fix the complaint source before resuming send.
3. Cut send volume by 50% on resume. Ramp back over 5–7 days. Don’t jump straight back to the pre-drop volume — your domain is already on thin ice.
4. Check the copy changes in the 7 days before the drop. Did anyone on the team change the opener, add an attachment, add tracking pixels, swap a CTA link host? Any of those can tank reputation on its own.

Signal 2 — IP reputation

What healthy looks like

High and stable. If you’re on a well-managed sending service (Instantly, Smartlead, Quickmail, Mailshake), this is usually consistent — the vendor manages the shared IP pool.

Red flags

• Sustained Medium or Low. Different from domain reputation because it’s not fully in your control. Your sending provider’s IP pool has a bad actor somewhere.
• Wide variance day-to-day. Suggests you’re on a dynamic IP pool and the vendor is rotating you through IPs with different reputations.

Fixes

1. If you’re on a shared pool with a sending vendor: open a support ticket asking which IP(s) your mail is sending from, and whether any are currently flagged. Half the time they know already. The other half they don’t, and you’ve just alerted them to a problem affecting multiple customers.
2. If you’re on dedicated IPs: same problem as domain reputation. Pause 72h, halve volume on resume, ramp back. Dedicated IPs give you control but also give you 100% of the blame.
3. If you’re shared-pool and the vendor won’t or can’t fix it: move sending providers. This is a 2-week project (reconfigure DNS, rewarm domains, move sequences), but a bad IP pool you can’t fix is a recurring tax on every campaign.

Signal 3 — User-reported spam rate

What healthy looks like

Under 0.10% sustained. Gmail’s own threshold for problems starts around 0.30%; you want a buffer below that.

Red flags

• Above 0.30%, any day. Gmail will start filtering to spam, possibly already is. Fix this first, before anything else in the stack.
• Above 0.10% for 3+ days. Trending the wrong direction. Not a fire yet, but the upstream source of complaints is probably consistent (a bad list, a wrong opener, a stuck sequence).

Fixes in priority order

1. Identify the spike’s source campaign. Use your sequencer’s dashboard to find which campaign(s) sent in the 48 hours before the complaint spike. Pause those.
2. Audit the list. Specifically: are there rows that shouldn’t be outbound targets? Press email addresses, support@, info@ addresses treated as personal inboxes, ex-employees, people who’ve already replied negatively? These all produce disproportionate complaints.
3. Audit the opener. First-line openers that sound like marketing spam (“Hope this finds you well,” “Would love to connect,” pushy framing) drive complaints at 3–5x the rate of specific signal-based openers. See Signal-based opener library.
4. Audit the unsubscribe flow. Count how many replies asked to unsubscribe but never received a response. Every one of those becomes a complaint eventually. Reply to every unsubscribe request within 24 hours. Nobody clicks “report spam” on an email they already opted out of.

Signal 4 — Authentication rate (SPF / DKIM / DMARC)

What healthy looks like

100% passing on all three. Period.

If you see anything other than 100% on each graph, you have an authentication problem — even if deliverability is currently fine, this will bite you eventually.

Red flags

• SPF < 100%. Usually because you added a new sending service and didn’t update the SPF record, or you’re exceeding the 10-lookup limit. The record is technically valid but not all sends pass.
• DKIM < 100%. Either the DKIM signing isn’t configured on the new service, or the key rotation didn’t propagate to DNS.
• DMARC < 100%. Usually means SPF or DKIM is failing and the alignment isn’t met.

Fixes

1. Pull your current SPF record (dig txt your-domain.com). Count the lookups — includes + MXs count toward the 10-lookup limit.
2. For each sending service, verify both SPF inclusion and DKIM public key are published correctly. Most services have a “verify configuration” page; use it.
3. Set DMARC to at least p=quarantine with reporting addresses. For outbound domains specifically, p=reject is often better because it shuts down spoofing attempts on your outbound domain. See DMARC setup for outbound for the full walkthrough.

Signal 5 — Encryption rate

What healthy looks like

99–100% inbound and outbound TLS. Gmail reports this on the Encryption tab.

Red flags

Below 99% outbound encryption means some of your mail is being sent unencrypted because the receiving server doesn’t support TLS (or your sending service is falling back to unencrypted send). In 2026, this is rare and concerning.

Fixes

1. If it’s the sending service’s issue: confirm their TLS policy in their docs or via a support ticket. Most reputable vendors enforce TLS by default.
2. If it’s recipient-domain specific: some small-business domains genuinely don’t support modern TLS. This isn’t your problem to fix, but it’s worth noting — those recipients are also more likely to have spam filtering quirks and lower reply rates generally.

Signal 6 — Delivery errors

What healthy looks like

A small, steady stream of soft bounces (temporary failures — out of office, mailbox full, rate limit). Hard bounce rate under 2%.

Red flags

• Hard bounce rate above 5%. Your list verification is failing. Either you’re not running a verifier, or the verifier you’re using isn’t working for the domains on this list.
• Spike in deferrals (temp failures). Usually rate-limiting. You’re sending too many messages to the same recipient domain too fast. Gmail pushes back; you should, too.
• Spike in rejections with specific SMTP error codes. Different error codes mean different things — take them seriously, don’t ignore them. The most common ones to fix:
• 421 / 451: rate-limited. Slow down.
• 550 5.7.1 blocked: listed on a blocklist or IP-blocked by Gmail. Fix IP reputation (signal 2).
• 550 5.4.1 not authorized: alignment issue. Fix authentication (signal 4).

Fixes

1. For bounce spikes: push the list back through a verifier (NeverBounce, ZeroBounce). Anything marked invalid, drop. Anything marked catch-all, move to a slower send schedule.
2. For rate-limiting: check your sender-to-recipient throttle settings. Default is often too aggressive. I use 30–60 sends per hour to any single recipient domain as a ceiling.
3. For specific error codes: look them up in the Gmail SMTP error reference and fix the underlying issue. Do not ignore error codes on the assumption they’re transient — sometimes they are, often they’re not.

Signal 7 — Feedback loop (FBL) data

What healthy looks like

FBL complaints < 0.05% of sent volume.

This is a separate data source from user-reported spam in signal 3. FBL captures complaints routed through Gmail’s automated feedback program. It’s noisier than the user-reported signal but catches complaints faster.

Red flags

• FBL > 0.1% sustained. Precedes a user-reported spam spike by 3–7 days in my experience. Fixing this early prevents the bigger problem downstream.
• FBL mismatch with domain reputation. If FBL is low but domain reputation is dropping, the problem isn’t complaints — look at signal 4 (auth), signal 2 (IP reputation), or signal 6 (bounces). Diagnose before you patch.

Fixes

Same as signal 3 — identify the campaign(s) driving complaints, pause, audit the list + opener + unsubscribe handling. FBL just gives you a head start.

The 12-minute Monday audit

Here’s the order I run them every Monday, and what decision each produces:

12 minutes, once a week. It’s the cheapest insurance on the outbound stack.

What Postmaster doesn’t tell you

One thing worth keeping honest about: Postmaster shows Gmail data only. It doesn’t cover Outlook, iCloud, Yahoo, corporate mail servers, or any of the regional providers. That’s most of your sending.

For full-stack deliverability you need to pair Postmaster with:

• GlockApps inbox placement tests weekly, to spot-check non-Gmail inboxes.
• Spam-trap monitoring (via your sending service or a tool like BoxSpout).
• Blacklist monitoring (MXToolbox, Spamhaus) — weekly automated check.

The Postmaster audit is the first 30% of a deliverability ops practice. It’s the 30% that catches most problems early. The other 70% is what keeps the campaign alive when Gmail is fine but Outlook is silently filtering.

When this is enough and when it isn’t

Postmaster alone is enough for a stable, mid-volume outbound program (1k–10k sends/week) where Gmail is ~50–70% of recipients. Once you’re over 10k/week or heavily Outlook-skewed, add seed list testing and blacklist monitoring to the stack — the Monday Postmaster audit alone stops being sufficient.

But you still do it. Because the minute you stop, the problem you should have caught two weeks ago shows up in a pipeline review and you’re explaining why reply rates collapsed.