Google Postmaster Tools compliance status: “Needs work” and “No data found”
Treat Google Postmaster Tools Compliance status as a delayed, Gmail-only view of a sending domain—not as a live verdict on today's campaign. Start with the failing row, verify current message or DNS evidence, record when the change became observable, and allow up to seven days before judging whether the dashboard recovered. “No data found” is unknown, not a pass or a failure.
- Read Compliant, Needs work and No data found literally; an empty row is unknown, not a clean bill of health.
- Use each row to select the smallest current evidence set, then make one bounded change and verify it on a new received message.
- Keep Gmail's delayed aggregate separate from a message-specific Flash result, and wait through the documented seven-day correction window before declaring the dashboard stuck.
Primary sources for this guide
- Google Postmaster Tools dashboards — Dashboard scope, state meanings, update delay, primary-domain behavior and troubleshooting.
- Google sender requirements and Postmaster Tools FAQ — Evidence surfaces for authentication, formatting, DNS, TLS, spam and unsubscribe issues.
- Gmail email sender guidelines — All-sender and bulk-sender requirements and their scope.
- Postmaster Tools API domains.getComplianceStatus — Authorized domain and subdomain response fields and required permission scope.
- Folderly Flash scoring and privacy methodology — Product evidence boundary between deterministic setup checks and provider-observed placement.
Read the three states literally
Google's dashboard covers personal Gmail accounts, is not real-time, may omit low-volume days and can use a rolling average. Updates typically appear within 24 hours; corrected Compliance status can take up to seven days. The view reports the primary domain even when subdomain traffic contributes, so a green row does not clear every stream and an empty row does not mean zero problems.
| State | What it means | Operator response |
|---|---|---|
| Compliant | Gmail considers the requirement met for the traffic and window it evaluated. | Preserve the evidence. Do not assume every mailstream, recipient or future message is healthy. |
| Needs work | Gmail says the requirement is not met and shows an action for that row. | Identify the affected identity or stream, make one bounded fix, verify it on a new received message, then watch the dashboard. |
| No data found | Gmail has no qualifying data for that requirement. Received messages may be insufficient or may not meet requirement-specific filters; configuration rows reflect settings observed when those messages arrived, not necessarily current DNS. | Keep the field unknown, verify current evidence independently and do not manufacture volume just to populate a dashboard. |
Map each row to evidence you can actually collect
Do not respond to a red dashboard by changing several unrelated systems. Use the row to choose the smallest evidence set. Google's requirements FAQ maps failure classes to Authentication, Encryption, Spam Rate, Feedback Loop and Delivery Errors dashboards, while its sender guidelines separate all-sender from bulk-sender requirements; do not turn a bulk-only row into a universal rule. Flash contributes bounded, deterministic evidence from the received message and its observed identities, with provider placement reported only when the configured quorum is met.
| Compliance area | Current evidence to collect | What one Flash test can and cannot add |
|---|---|---|
| SPF and DKIM | Received Authentication-Results, active Return-Path, DKIM d= domain and selector, and the DNS records those identities reference. | Flash can show message-level verdicts and bounded DNS findings. One pass does not prove every stream uses the same path. |
| From alignment / DMARC | Visible From domain, authenticated SPF or DKIM identity, message-level DMARC verdict and alignment, and the published domain policy. | Flash separates the tested message's verdict from bounded DNS-policy evidence. It cannot inventory every sender using the domain. |
| DNS records | Forward DNS and PTR for sender-owned infrastructure; confirm whether an IP is dedicated or provider-managed. | Flash can expose reverse-DNS and HELO evidence for the observed connection. It does not establish the health of every IP in a pool. |
| Message formatting | Gmail SMTP response or delivery-error evidence, the exact received message and its sending platform. | Flash can inspect the representative message structure it received. It cannot reproduce every Gmail rejection or campaign variant. |
| Encryption | Postmaster's Encryption dashboard and transport logs from the responsible mail system. | One successful encrypted path does not prove all outgoing Gmail traffic uses TLS. |
| User-reported spam rate | Postmaster Spam Rate and Feedback Loop data, segmented by campaign or mailstream where eligible. | Flash does not observe recipient complaints or consent. A clean setup grade cannot clear a complaint-rate incident. |
| One-click / honor unsubscribe | For applicable bulk marketing or subscribed mail, collect received List-Unsubscribe headers, authenticated coverage, an authorized synthetic POST, server logs and confirmation that the request was honored within 48 hours. | Flash can inspect headers and authentication. It does not execute the endpoint or prove suppression. |
- Folderly Flash scoring methodology
- Read the authentication breakdown
- Verify one-click unsubscribe evidence
Reconcile Postmaster Tools with a live test
When the two surfaces disagree, compare their scopes before deciding which one is wrong. Flash's total is not proof of Gmail-wide health, while Gmail's aggregate cannot overrule current received-message evidence.
- Postmaster says Needs work, but the new message passes: the dashboard may include earlier traffic, another subdomain or platform may be failing, or the correction may be too recent. Preserve the passing message, inspect other active streams and recheck after the documented window.
- Postmaster says Compliant, but the new message fails: act on the received-message failure. A delayed aggregate cannot make a failed DKIM signature, misaligned identity or required header missing for the applicable sender or message class pass. Fix the path, retest and then watch the dashboard.
- Postmaster says No data found, but the new message passes: record the passing message and missing aggregate verdict separately. Check current DNS and message evidence; do not call the domain compliant or increase volume merely to force a result.
- Both surfaces pass: treat that as useful setup evidence, not an inbox guarantee. Reputation, recipient behavior and local classification still matter, and placement should remain unknown when provider evidence is insufficient.
Use a seven-day change log
Connect the dashboard row to one remediation and one controlled retest. Preserve the baseline before editing anything, then keep the following fields together so another operator can reproduce the decision.
| Field | Record |
|---|---|
| Domain and mailstream | Primary domain, visible From domain, ESP or MTA, and message class. |
| Postmaster baseline | Exact row, state, observed UTC date and affected dashboard window. |
| Current-message baseline | Test ID, timestamp, SPF, DKIM and DMARC verdicts, relevant headers and observed provider evidence. |
| Change | One DNS, ESP, message or endpoint change, its owner and deployment time. |
| Immediate verification | A new received message proving whether the targeted field changed. |
| Deferred verification | A Postmaster recheck date no later than seven days after the fix became observable. |
| Decision | Resolved, partially resolved, not resolved or inconclusive, with the next owner and rollback condition. |
A complete troubleshooting sequence
Keep the diagnosis bounded and make every status change traceable to an observation.
- Confirm the exact verified domain and UTC date shown in Postmaster Tools.
- Open the failing row and copy its stated action into the incident record.
- Identify every active platform or subdomain that can contribute mail under the primary domain.
- Send one authorized, representative message through the affected production path.
- Compare the received identity, authentication, headers and transport evidence with the failing row.
- Make one observable change and assign one owner.
- Run a comparable message-level retest after the change is live.
- Recheck Postmaster Tools within its normal update window and again at seven days before declaring the dashboard stuck.
- If the status still conflicts, confirm primary-domain scope, other sending streams, delivery errors and Feedback Loop evidence before another change.
Use the API only through an approved integration
The Postmaster Tools API exposes authorized domain and, when available, subdomain compliance data. Use it only through an existing approved integration; do not create credentials for a one-off diagnosis.
Limitations
This workflow does not prove organic demand, inbox placement for every Gmail recipient, compliance at other mailbox providers or the cause of a reputation incident. Postmaster Tools is Gmail-specific and aggregate; a Flash result is message-specific and bounded by the evidence observed for that run. Neither surface measures permission or guarantees future delivery.