Why Google Postmaster Tools Still Shows "Issues Detected" After You Fix DKIM

You fixed a missing Google Workspace DKIM record, you sent a test email, and Gmail's "Show original" now shows `dkim=pass` and `spf=pass`. You open Google Postmaster Tools expecting confirmation, and the dashboard still says "Issues Detected" with a "Last Modified" date that has not moved in over a week. The fix looks real, the dashboard looks broken, and you cannot tell which one to trust.

The short answer: the dashboard is a delayed sampled view, not a live status indicator. A stale "Issues Detected" badge after a confirmed DKIM fix almost always means the dashboard has not caught up yet, not that your fix failed. Verify the fix in your own data, then let the dashboard catch up on its own schedule.

What "Issues Detected" actually means in Postmaster Tools v2

Postmaster Tools is a summary view of Gmail's aggregate traffic for a domain. The "Issues Detected" badge is not a live check against your DNS. It is a rolling-window signal that reflects what Gmail has observed from your domain over the recent reporting period.

The "Last Modified" date is the date Google last updated the view. It is not the date you fixed anything, and it is not the date Google checked your DNS. When the date does not move for a week, that is a normal signal that the underlying reporting window has not produced a new aggregate yet.

The Gmail volume threshold you may be under

Postmaster Tools has a documented minimum-volume floor. To populate the dashboard with live data at all, a domain needs to send at least 100 messages per day to Gmail addresses. Below that floor, the dashboard shows "No data found" or, more confusingly, stale data from a previous window.

If you are a new sender setting up authentication for the first time, you are very likely under that floor. Many small businesses send fewer than 100 messages a day to Gmail recipients. Marketing operations teams that send mainly to corporate inboxes on Microsoft 365 may also be under the floor for Gmail-specific data. The result is a dashboard that does not reflect your current state, and an "Issues Detected" badge that may be left over from a window before your fix landed.

The threshold exists because Postmaster Tools aggregates and anonymizes traffic. Below 100 messages a day, the sample is too small to be meaningful, and Google declines to publish a live signal. Hitting the floor is itself a milestone; until you do, treat the dashboard as advisory, not diagnostic.

How long Postmaster Tools actually takes to refresh

For senders above the volume floor, the practical refresh window is one to four weeks after a real change. The dashboard does not refresh in real time, and it does not refresh on demand. Google rolls up traffic on a weekly cadence, applies its own validation and aggregation passes, and only then updates the view. A two-week delay is common. Four weeks is not unusual for a domain whose sending pattern is bursty.

If you are under the volume floor, the dashboard may never refresh until you cross it. There is no setting that forces an update.

How to verify the fix in real time

Stop relying on the badge. Verify the fix directly using two sources that do not depend on Google's reporting pipeline: the message headers and your DMARC aggregate reports.

Check the message headers. From a Gmail inbox, open any test message you sent from the fixed domain and click "Show original" (the three dots menu in the message, then "Show original"). In the raw headers, look for two lines:

• `dkim=pass header.d=yourdomain.com` confirms the message was signed with a key that matches your domain.
• `spf=pass smtp.mailfrom=...` confirms the sending IP is allowed by your SPF record.

If both lines show `pass` and the domains in the headers match your `From:` address, the fix is real. The `Authentication-Results` section also shows alignment between the signing domain and the visible From domain, which is the value DMARC actually checks.

Check the DMARC aggregate report. If your DMARC record includes a `rua` tag pointing to a working report endpoint, you will receive XML reports from every receiver that handles your mail. The reports arrive daily and include a per-source breakdown of which IPs sent on your behalf, whether they passed DKIM and SPF, and whether those signatures were aligned with your domain. A daily report with all sources showing `dkim=pass` and `spf=pass` and aligned `From` domains is the strongest signal that the fix is working, independent of any dashboard.

Reading raw XML aggregate reports by hand is workable but tedious. A practical way to turn those daily reports into a clear, current view of your DKIM and SPF alignment across all your sending sources is a tool like DMARCFlow, which parses the reports and surfaces the same pass/fail picture in seconds. The point is the principle, not the vendor: stop waiting on a delayed Google dashboard and use your own reporting data.

When the dashboard is actually showing a real problem

A stale dashboard is one thing. A real, unfixed authentication problem is another. The way to tell the difference is to look at the same sources you would use to verify the fix:

• A live SPF or DKIM fail in the message headers means the fix is not complete. Common causes include a record published on the wrong host (for example, a Google Workspace DKIM record published at `_domainkey.mail.yourdomain.com` when Google expects `_domainkey.yourdomain.com`), a missing trailing dot, a stale cached record at the receiver, or a DKIM key that does not match the one your mail server is actually using.
• A header pass plus a stale dashboard means the fix worked and the dashboard is just behind. Wait for the next weekly rollup.
• A header pass plus an aggregate report that still shows `dkim=fail` from a specific source means that source is still using the old key. Identify the source in the report and fix the record on that specific subdomain or service.

Headers plus aggregate reports cover the ground the dashboard does not, and they do so on a daily cadence rather than a weekly one.

FAQ

How long does Google Postmaster Tools take to update after I fix DKIM?
For senders above the 100 messages per day to Gmail threshold, expect one to four weeks. The dashboard updates on a weekly rollup cadence, not in real time.

Does a stale "Issues Detected" badge mean my fix did not work?
Not necessarily. The most reliable check is the message headers. If `dkim=pass` and `spf=pass` show up in "Show original" for a test message and the signing domain matches your `From:` address, the fix is real and the dashboard is just lagging.

Is the 100 messages per day threshold the same as the 5000 messages per day bulk-sender threshold?
No. The 100 messages per day floor is the minimum to populate Postmaster Tools with live data at all. The 5000 messages per day threshold is a separate Gmail sender guideline that triggers additional requirements (one-click unsubscribe, DMARC policy on the sending domain). A new sender can be under one and well over the other.

Can I trigger a manual refresh of the Postmaster Tools dashboard?
No. The dashboard updates on Google's schedule, not on user action. If you need a faster signal, use message headers and DMARC aggregate reports instead.

Why does the Last Modified date not change when I edit my DNS?
The "Last Modified" date reflects when Google last updated the view from its aggregate traffic data, not when you changed your DNS. If your sending volume is below the floor or the reporting window has not rolled over yet, the date will stay put even though the underlying fix is real.

Bottom line

The Postmaster Tools "Issues Detected" badge is a confirmation tool, not a verification tool. Use it to spot-check that a working authentication setup continues to look healthy over time. Do not use it as the only evidence that a fix worked. Verify with message headers and DMARC aggregate reports first, then let the dashboard catch up.