Google Postmaster Tools Deliverability Analysis, Explained

The Deliverability Analysis section in Google Postmaster Tools sits below the Compliance Status table and names the exact reason a batch of your mail was rejected or delayed, things like a rate limit, suspected spam, or a listing on a public blocklist, plus a recommended action for each one. It answers a narrower question than Compliance Status does. Compliance Status tells you whether your domain setup meets Gmail's baseline requirements. Deliverability Analysis tells you what happened to messages you actually sent. Reading the two together, instead of treating one as a stand-in for the other, is what keeps you from fixing the wrong problem.

What the Deliverability Analysis section shows and where it sits in Postmaster Tools

Deliverability Analysis sits directly underneath the Compliance Status table on the main Postmaster Tools dashboard. For any domain you've verified, it lists the delivery-error issues Gmail found over the reporting window, each one paired with a recommended action, rather than a single pass or fail score for the domain as a whole.

That placement matters. Compliance Status is where you check whether your infrastructure, SPF, DKIM, DMARC, TLS encryption, unsubscribe handling, meets Gmail's stated requirements for senders. Deliverability Analysis is downstream of that: it reports on the mail you've already sent, aggregated daily rather than broken out per campaign. You can be fully compliant on paper and still see an active issue here, because compliance is a structural check on your setup, and Deliverability Analysis is a read on real message outcomes.

Both dashboards use the domain you verified in Postmaster Tools, and Gmail is the only mailbox provider either one reports on. Nothing here reflects Outlook, Yahoo, or any other provider's view of your mail.

If you haven't opened the tool yet, it lives at Postmaster Tools, and you'll need a verified sending domain before either dashboard populates with data.

The delivery-error reasons it names, and what each one means

Postmaster Tools documentation names ten distinct rejection and temporary-failure reasons that can surface in this section. This section covers five of them in detail:

• Rate limit exceeded: Gmail throttled your sending IP or domain because your volume, or the speed at which it ramped up, outran the reputation you'd built. The fix is a slower warmup schedule, not more sending infrastructure.
• Suspected spam: Gmail's content and behavioral filters flagged the message pattern itself, separate from your authentication status. A domain can pass every Compliance Status check and still trip this one if recipients aren't engaging.
• Bad or unsupported attachment: the message carried a file type or format Gmail won't deliver.
• Sender DMARC policy: your own domain's DMARC record, not a Gmail rule, told the receiving server to reject or quarantine mail that failed alignment. This reason means your own policy is doing what you configured it to do.
• Domain or IP listed in public RBLs: your sending domain or IP appears on a third-party blocklist that Gmail checks against, independent of anything Postmaster Tools calculates on its own.

None of these five require a Compliance Status failure to appear, and a Compliance Status failure doesn't guarantee any of them will show up either.

Deliverability Analysis vs. Compliance Status: what's covered and what isn't

Compliance Status and Deliverability Analysis check different things, and neither substitutes for the other. Compliance Status is a structural pass or fail on setup: SPF, DKIM, DMARC policy and alignment, message formatting, forward and reverse DNS, TLS encryption, spam rate, and unsubscribe handling. Google specifically outlines eleven separate requirements feeding that score. Deliverability Analysis is a read on what happened to individual messages once they left your servers.

	Deliverability Analysis	Compliance Status
What it measures	Why specific mail was rejected or delayed	Whether your domain setup meets Gmail's baseline requirements
What it names	Rate limits, suspected spam, bad attachments, sender DMARC policy, public RBL listings	SPF, DKIM, DMARC policy, DMARC alignment, message formatting, DNS, TLS encryption, spam rate, unsubscribe handling
Granularity	Per named error reason, aggregated over the reporting window	Per requirement: Compliant, Needs work, or No data found
A clean read means	Gmail found no active rejection reasons in this window	Your domain's authentication and policy setup meets Gmail's requirements

The line worth drawing explicitly: a public RBL listing is something Gmail checks against your sending infrastructure, and it shows up in Deliverability Analysis, but it isn't one of the requirements Compliance Status scores. The same goes for rate limiting and suspected spam. If you only ever check Compliance Status, you'll never see these reasons at all, even though they're actively affecting delivery right now.

What to do when an error appears

1. Confirm which reason is firing before you change anything. The five error reasons call for different fixes, and treating them interchangeably wastes a sending cycle you can't get back.
2. For rate limit exceeded, pull volume back to your prior baseline and ramp up again more slowly, the same discipline that applies to any domain approaching Gmail and Yahoo's bulk-sender thresholds.
3. For suspected spam, look at engagement and list hygiene before you look at your servers. If verified addresses are still bouncing or going unopened, that's a stronger signal than anything in your send configuration.
4. For sender DMARC policy, check your own DMARC record's policy and alignment settings; this reason means your policy is working as configured, and the fix is on your own domain's DMARC setup rather than anything Gmail controls.
5. For a public RBL listing, identify which blocklist flagged the IP or domain and follow that list's own delisting process. Postmaster Tools tells you the reason fired, not which list is holding the listing.
6. For a bad or unsupported attachment, convert or remove the file type before resending the message.
7. Recheck the next day. Deliverability Analysis reports update daily and reflect the prior day's aggregated performance, not the send in progress, so a fix made this morning won't show clean data until tomorrow.

Checking Compliance Status again afterward is still worth doing separately. Fixing a Deliverability Analysis error doesn't automatically move a Compliance Status requirement, and the reverse is also true.

FAQs

What is the Deliverability Analysis section in Google Postmaster Tools?

It's the panel below the Compliance Status table that names specific delivery-error issues Gmail found for your domain, such as a rate limit or a suspected-spam flag, each with a recommended action attached. It reports what actually happened to sent mail, rather than scoring your domain's overall setup the way Compliance Status does.

Where do I find the Deliverability Analysis tab in Postmaster Tools?

It sits on the main dashboard, directly underneath the Compliance Status table, for any domain you've verified. It won't show data until you've sent enough verified mail through that domain for the reporting window to populate.

Can a domain pass Compliance Status and still show errors in Deliverability Analysis?

Yes. Compliance Status checks structural requirements like SPF, DKIM, DMARC alignment, and TLS encryption against your setup. Deliverability Analysis reports what happened to messages you actually sent, so issues like suspected spam or a rate limit can appear even on a fully compliant domain.

What does "domain or IP listed in public RBLs" mean?

Your sending domain or IP address appears on a third-party blocklist that Gmail checks against incoming mail. It's a signal Gmail consults from outside its own Compliance Status requirements, which is why Postmaster Tools surfaces it in Deliverability Analysis rather than in the compliance table.

How often does the Deliverability Analysis data update?

Reports update daily and reflect the prior day's aggregated performance rather than data from an individual campaign. A fix made today typically won't show up as a clean reading until the following day's report.