How to use Gmail Deliverability Analysis
Turn Postmaster Tools feedback into a focused investigation, with clear limits on what each result tells you.
Start with a question you can investigate: is Gmail reporting a configuration problem, delivery failures, or a concern about how recipients respond? Deliverability Analysis can help you choose that starting point. It should sit beside your sending logs and campaign history.
Read the result in context
Google's Postmaster Tools v2 API exposes a deliverabilityStatusVerdict with a reason. The following groups summarize its documented reasons. The investigation steps are SendPoint recommendations, not additional Google status definitions. Source: Google API reference.
Sender requirements
A sender requirement is unmet. API reason: SENDER_.
Find the failing compliance row and test that requirement on the affected sending route.
Delivery errors
Delivery failures are elevated. API reason: SMTP_.
Group full SMTP responses by code, sending IP and message stream.
Spam rate
The reported spam rate exceeds 0.1%. API reason: SPAM_.
Compare the affected dates with campaign launches and audience changes.
Negative feedback
Recipient signals indicate unwanted mail. API reason: USER_.
Review acquisition sources, subscription expectations and sending frequency.
Limited feedback
Recipient actions provide little feedback. API reason: USER_.
Review whether the audience still has a reason to receive this particular subscription.
Positive feedback
Recipient signals are favorable. API reason: USER_.
Keep monitoring individual streams before making a large sending change.
Insufficient volume
There is insufficient outgoing volume. API reason: MESSAGE_.
Use available logs and message samples; do not manufacture traffic to fill a dashboard.
Unspecified reason
No specific explanation is supplied. API reason: REASON_.
Record the result and investigate the observable delivery symptom.
Build a short incident record
Save the domain, observation time, reporting dates shown, exact result and affected message type. Add what changed around the same period: a new automation, sending platform, audience source or campaign schedule.
Then record one hypothesis and the evidence needed to test it. For example, if failures began after a new sending route was enabled, compare that route's SMTP responses with those from the established route. A domain-level warning alone does not identify the responsible campaign.
Choose a measurable next step
Assign the issue to the person who can change it. Infrastructure failures belong with the sending provider or mail administrator. Questions about subscription expectations need the team that controls audience acquisition and messaging.
After a change, compare fresh evidence with the original incident record. Keep the observation date separate from the data's reporting date so an older result is not mistaken for a new failure.
Avoid turning the result into a promise
A positive result is not proof that every message reached the inbox. Low feedback is not a direct reading of your ESP's open-rate metric. Google explicitly cautions against using third-party open rates as a reliable diagnosis of delivery or spam placement. Source: Google sender guidelines.
Use the result to narrow your investigation. Confirm the outcome against the problem you actually set out to solve.
Related guides
- How to read Google Postmaster Tools dashboards
- How to fix Needs work in Gmail compliance status
- Why Google Postmaster Tools shows no data
- How to use Gmail Feedback Loop