Why Gmail Postmaster Tools shows no data: DKIM/SPF attribution, subdomains, and volume thresholds

gmaildkimspffaqtutorial

Gmail Postmaster Tools is useful only when Gmail can connect the messages it receives to the domain you added. That sounds obvious, but it is the reason many otherwise legitimate senders see empty charts, missing authentication data, or a persistent No data found status.

The domain in the visible From: address is not always the domain Gmail uses for Postmaster Tools attribution. The tool follows the authenticated identities in the message, and it reports only enough aggregated data to protect Gmail users' privacy. A verified domain can therefore have no visible data even while mail is being sent every day.

This guide explains what Gmail is measuring, how DKIM and SPF identify a sending domain, why subdomains need careful handling, and how to troubleshoot an empty dashboard without guessing.

The short answer

When Postmaster Tools shows no data, check these questions in order:

  1. Is the domain verified in Postmaster Tools?
  2. Is the mail going to personal Gmail accounts, rather than only Google Workspace accounts?
  3. Does the domain you added match the DKIM d= domain or the SPF Return-Path domain used by the messages?
  4. Are the messages reaching Gmail with a passing DKIM or SPF result?
  5. Are you looking at the right subdomain and dashboard scope?
  6. Has enough qualifying traffic arrived on a given day for Gmail to publish an aggregate result?
  7. Have you allowed at least 24 hours, and sometimes longer, for the data to appear?

The 5,000 messages per day figure is often blamed for empty Postmaster charts. It is important, but it is not a published universal threshold for every Postmaster Tools dashboard. It is Gmail's bulk-sender threshold. Postmaster Tools may show data below that volume, while low-volume days can still be omitted for privacy.

An empty chart is not proof that SPF or DKIM is broken. First prove that Gmail is receiving qualifying messages and that the selected Postmaster domain matches an authenticated identity.

What Postmaster Tools actually covers

Postmaster Tools reports on outgoing mail sent to personal Gmail accounts, usually addresses ending in @gmail.com or @googlemail.com. It does not provide the same visibility for mail sent only to Google Workspace accounts at a company or school domain.

That distinction can make a large sending program look invisible. For example, a company might send 100,000 messages per day to customer addresses hosted on Google Workspace, but only a handful to personal Gmail accounts. The Postmaster data set is based on the latter, not the total volume in the company's mail logs.

The available dashboards cover different signals, including:

  • spam rate
  • IP reputation
  • domain reputation
  • feedback loop data
  • SPF, DKIM, and DMARC authentication
  • encryption
  • delivery errors

They do not all use exactly the same message population. Some dashboards are based on DKIM-authenticated messages, and some views use the domain in the From: header or the authenticated DKIM and SPF domains. A blank authentication chart and a blank reputation chart do not necessarily have the same cause.

Google also attempts to exclude forwarded messages, although its documentation notes that some dashboards can still include forwarded traffic. Forwarding and mailing-list transformations can change authentication results, so do not use a forwarded copy as the only test message.

Verification is not attribution

Postmaster Tools has two separate concepts that are easy to combine accidentally:

  • Verification: proving control of a domain by publishing a Google-provided DNS TXT or CNAME record.
  • Attribution: giving Gmail a domain identity it can associate with received messages.

Verification gives your Google account permission to view a domain. It does not make unrelated messages appear in that domain's charts. After adding a domain, verify it in Postmaster Tools. Google says verification is typically immediate but can take up to about 10 minutes to update.

For the data itself, Google instructs senders to add either the domain used in the DKIM signature's d= value or the SPF Return-Path domain. If the DKIM and SPF domains are identical, messages authenticated by SPF, DKIM, or both can contribute to the selected domain's data.

This is the key operational rule:

Add the domain Gmail sees as an authenticated sender, not merely the domain displayed to the recipient.

The visible From: domain still matters for DMARC alignment and Gmail sender requirements, but it is not automatically the domain used for every Postmaster Tools chart.

DKIM attribution: follow the d= value

DKIM identifies a message with a signature such as:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

The d= value is the signing domain. The selector s= tells Gmail where to find the public key, normally at:

selector1._domainkey.example.com

For Postmaster Tools troubleshooting, the important field is d=, not the selector and not the address after From:. If a message has this header:

From: alerts@example.com
DKIM-Signature: ... d=mailer.example.net; ...

then the message is signed by mailer.example.net. A DMARC policy might still pass if the domains are aligned under the applicable relaxed-alignment rules, but adding only example.com to Postmaster Tools may not show the DKIM-attributed data you expected. Add and verify the domain that actually appears in d= when that is the identity you want to inspect.

If an email service provider signs with its own domain instead of your domain, the message can be validly DKIM-authenticated while the Postmaster data belongs to that provider-owned signing identity. The practical fix is to configure domain signing for your own domain, publish the corresponding public key, and confirm the resulting d= value in a message delivered to a personal Gmail test account.

The Authentication dashboard has a View by DKIM and SPF domains option. Use it when you need to see whether Gmail is observing your domain as an authenticated identity. Use the From header domain view when the question is whether the visible sender domain is being authenticated in an aligned way.

SPF attribution: follow the Return-Path

SPF authenticates the domain used in the SMTP envelope, not usually the address displayed in the message body. That envelope domain is commonly visible as the Return-Path header after Gmail accepts the message:

From: invoices@example.com
Return-Path: bounces@mail.example.net

In this example, SPF is evaluated for mail.example.net, assuming that is the envelope sender domain. The SPF record is looked up for that domain, and the resulting SPF identity may be the one relevant to Postmaster Tools attribution.

This is why a message can look as if it is from example.com while the SPF-authenticated domain is mail.example.net. The two domains may be aligned for DMARC if they share the same organizational domain and relaxed alignment is in use, but they are still different identities for troubleshooting and reporting.

Inspect the delivered message's Authentication-Results header as well as Return-Path:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@mail.example.net designates ...)
       smtp.mailfrom=bounces@mail.example.net;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

The useful fields are:

  • smtp.mailfrom or the envelope sender, for SPF
  • header.d, for DKIM
  • header.from, for the visible sender and DMARC alignment

If the selected Postmaster domain matches none of those authenticated identities, an empty dashboard is expected.

Why both SPF and DKIM can confuse the picture

Many senders use different domains for the visible From address, DKIM, and SPF:

From: news@example.com
DKIM: d=sign.example.com
SPF:  Return-Path=bounces.example.net

That arrangement is not automatically wrong. DMARC asks whether at least one authenticated identity aligns with the visible From domain. Postmaster Tools asks a different operational question: which authenticated domain should receive the aggregate signal for a selected dashboard?

For bulk senders, Gmail requires both SPF and DKIM authentication and requires direct messages to have the From organizational domain aligned with either the SPF or DKIM organizational domain. Passing one aligned method does not mean both methods are attributed to the same Postmaster entry.

For easier operations, use a deliberate identity plan:

  • sign DKIM with a domain you control and recognize
  • use an SPF Return-Path domain you control and recognize
  • align at least one of them with the visible From domain
  • add the actual authenticated domain or domains to Postmaster Tools
  • document which dashboard represents each sending stream

If DKIM and SPF use separate subdomains, it can be useful to add each exact authenticated domain when you need independent views. Do not expect a parent-domain entry to reproduce every exact-subdomain chart.

Subdomains have two different behaviors

Subdomains create two related but distinct questions: what does Gmail count together, and what can you inspect separately?

Bulk-sender counting uses the primary domain

Gmail's bulk-sender FAQ says messages sent from the same primary domain count together toward the approximately 5,000-message daily classification. Mail from example.com and promotions.example.com therefore contributes to the same primary-domain total.

A subdomain is not a way to split one large program into several identities and remain below the bulk-sender threshold. If the total traffic under the primary domain reaches the threshold, Gmail can classify the sender as a bulk sender even when each individual subdomain sends less.

Independent dashboard views use the exact subdomain

If news.example.com sends mail and you want its dashboards separately from example.com, add news.example.com to Postmaster Tools as its own domain. Google recommends adding subdomains after adding the primary domain. When the primary domain is verified, its subdomains do not need separate ownership verification.

The exact domain still has to be relevant to the message's authentication. For example:

From: newsletter@example.com
DKIM-Signature: ... d=news.example.com; ...
Return-Path: bounces@bounce.example.com

Adding news.example.com can expose the DKIM-attributed stream. Adding bounce.example.com can expose the SPF-attributed stream. Adding only the parent example.com may not give an equivalent exact-domain view, especially in dashboards that report the exact DKIM or SPF domain.

Compliance status is primary-domain data

The newer Compliance status dashboard is different. Google says it reports status for primary domains only, while using subdomain traffic as part of the primary-domain compliance calculation. If you need an independent subdomain view, use the other Postmaster dashboards rather than treating the Compliance status page as a subdomain report.

This explains an apparent contradiction:

  • adding a subdomain can create an independent authentication or reputation view
  • the primary-domain compliance status can still include that subdomain's traffic

The two views are not inconsistent. They answer different questions.

The volume threshold people often confuse

There are three different volume ideas to keep separate.

1. Gmail's bulk-sender threshold

Gmail defines a bulk sender as a sender that sends close to 5,000 or more messages to personal Gmail accounts within a 24-hour period. Messages from the same primary domain count together, including its subdomains. Once a sender is classified as a bulk sender, Google's FAQ says that classification is permanent.

This threshold determines which bulk-sender requirements apply, such as publishing DMARC and supporting one-click unsubscribe for relevant promotional traffic. It does not mean Postmaster Tools will always show a chart below 5,000 messages, nor does it guarantee data above 5,000.

2. Dashboard privacy suppression

Google does not publish one universal number that guarantees a visible data point in every dashboard. It states that dashboards might omit data on days when the total outgoing volume is too low, to protect Gmail users' privacy.

The practical result is that a low-volume sender can see:

  • data on some days but not others
  • one dashboard populated while another is blank
  • a chart with gaps across a date range
  • No data found even though a few test messages were delivered

Do not solve this by sending unwanted test campaigns. Use legitimate, opted-in traffic and interpret the gaps as a privacy-preserving limitation rather than a precise pass/fail threshold.

3. Qualifying Gmail traffic

Your total outbound volume is not the relevant denominator. The data must be traffic Gmail can associate with the selected domain and dashboard. Messages sent to non-Gmail recipients, messages sent only to Workspace accounts, messages with failed or unrelated authentication, and messages suppressed by forwarding or filtering can all reduce the qualifying population.

The safest expectation is not "send N messages and a chart must appear." It is "send a consistent stream of correctly authenticated mail to personal Gmail recipients, then allow the dashboard to populate when Gmail has enough data to publish it."

How long should data take to appear?

Postmaster Tools is not real-time telemetry. Google's dashboard documentation says data is typically updated within 24 hours, but can take longer. Timestamps use Coordinated Universal Time, so a local midnight is not necessarily the end of the reporting day you are viewing.

The Compliance status dashboard has an additional delay. It uses rolling data gathered over multiple days, and Google says changes can take up to seven days to be reflected after an issue is fixed.

Use this timing model:

  • DNS verification: often immediate, sometimes up to about 10 minutes
  • ordinary dashboard data: typically within 24 hours, but not guaranteed
  • compliance status after a sending or configuration fix: allow up to seven days
  • low-volume periods: may remain blank regardless of waiting

If a message sent this morning is not visible this afternoon, that is normal. If a correctly authenticated message sent several days ago is still absent, investigate attribution, scope, volume, and the selected date range before assuming the data pipeline is broken.

A reliable troubleshooting checklist

Work through these checks in order. Keep a copy of the test message and its complete headers so that each conclusion is based on evidence.

1. Confirm the Postmaster entry

  • Sign in to Postmaster Tools.
  • Confirm that the domain is present under Manage domains.
  • Confirm that its status is verified.
  • Confirm that the domain is spelled exactly as intended, without a protocol, path, or accidental extra label.
  • If multiple Google accounts need access, confirm that each account has been granted access to the verified domain.

Verification proves control, but it does not prove that this is the identity used by the traffic.

2. Confirm the recipient population

  • Send or inspect legitimate mail delivered to a personal @gmail.com or @googlemail.com account.
  • Do not count mail sent only to Google Workspace domains.
  • Check that the message was actually accepted by Gmail, rather than deferred or rejected.
  • Test direct delivery, not only an automatically forwarded copy.

If the sending program rarely reaches personal Gmail, an empty dashboard may be expected.

3. Inspect the delivered headers

In the Gmail message, choose Show original and record:

  • From: domain
  • Return-Path: domain
  • DKIM d= domain
  • DKIM selector s=
  • Authentication-Results values for spf, dkim, and dmarc

Look for spf=pass and dkim=pass. A domain that appears only in From: but not as a passing authenticated identity is not enough for Postmaster attribution.

4. Compare the selected domain with the authenticated identities

Use this small comparison table:

Message identityHeader or DNS locationPostmaster question
Visible senderFrom: and header.fromIs the displayed domain aligned?
DKIM signerDKIM-Signature: d= and header.dIs this the domain added for DKIM data?
SPF identityReturn-Path and smtp.mailfromIs this the domain added for SPF data?

If the selected entry matches only the visible From domain while DKIM and SPF use other domains, add the relevant authenticated domain entries and verify them as required.

5. Check DNS from outside the sending platform

Use a DNS checker or command-line queries from an independent network. Confirm:

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Replace the names with the actual SPF domain, DKIM selector domain, and DMARC domain. Confirm that:

  • the SPF record is published at the SPF identity's domain
  • there is one valid SPF record, not several competing records
  • the DKIM public key is at the selector and d= domain shown in the message
  • DNS answers are consistent across authoritative nameservers
  • recent DNS changes have had time to reach the resolver used by the sender and Gmail

DNS being correct now does not prove that the message Gmail evaluated used the current configuration. The message headers and Postmaster data both reflect what Gmail observed at receipt time.

6. Check the subdomain scope

  • Add each sending subdomain when you need its dashboards independently.
  • Use the primary domain for the primary-domain compliance view.
  • Do not expect a parent-domain chart to be an exact substitute for a subdomain chart.
  • Remember that subdomain volume still contributes to the primary-domain bulk-sender count.
  • Check the exact authenticated domain, not just the brand's apex domain.

7. Check the dashboard and date range

Postmaster Tools supports ranges such as 7, 30, 60, 90, and 120 days. Check a broader range after the normal reporting delay, but do not interpret an old populated range as proof that today's traffic is correctly attributed.

Also check the dashboard type. The Authentication view, Domain Reputation view, Spam Rate view, and Compliance status view have different scopes and minimum-data behavior.

8. Wait without changing three things at once

After fixing authentication or adding a domain, wait at least 24 hours before judging ordinary charts. For compliance status, allow up to seven days. During that period:

  • keep sending legitimate, wanted mail at a consistent rate
  • save message headers from fresh personal Gmail deliveries
  • monitor SMTP deferrals and bounces in your own logs
  • avoid changing DKIM, SPF, the visible From domain, and sending volume simultaneously

If the live headers are still wrong, waiting will not fix the configuration. If the live headers are correct and the dashboard is merely delayed, making more changes can make diagnosis harder.

Common cases and the right interpretation

"The message says From example.com, but example.com has no data"

Inspect DKIM d= and SPF smtp.mailfrom. The visible From domain is not necessarily the authenticated domain. Configure aligned domain signing or add the actual authenticated domain to Postmaster Tools.

"The apex domain is verified, but the subdomain chart is empty"

Add the subdomain separately for an independent view, then confirm that it is the domain in DKIM d= or the SPF Return-Path. Primary-domain verification can cover ownership, but it does not turn every subdomain into an independently populated chart.

"We send more than 5,000 messages, but there is still no data"

The 5,000 figure is not a guarantee of dashboard visibility. Confirm that the traffic is going to personal Gmail accounts, that it is attributed to the selected domain, that authentication passes, and that you have waited for reporting delay. Also check whether the dashboard is using the primary-domain or exact-subdomain scope.

"We send fewer than 5,000 messages, so Postmaster Tools should be empty"

That conclusion is also too strong. The bulk-sender threshold and dashboard privacy suppression are different rules. Smaller senders can receive data when Gmail has enough qualifying traffic, but low-volume days can be omitted.

"SPF and DKIM are configured, but the Authentication dashboard is blank"

Configuration in DNS is not the same as passing authentication on received mail. Inspect a Gmail-delivered message, confirm the result is pass, and compare the exact d= and envelope domains to the Postmaster entry. A domain configured but not used for sending can correctly show no authentication data.

"The dashboard was populated yesterday and is blank today"

Check whether today's traffic fell below the privacy-preserving data level, whether the message mix changed to a different authenticated domain, and whether the chart is using UTC. A single missing day is not enough evidence of an outage.

Use Postmaster data with other evidence

Postmaster Tools is an aggregate view of Gmail's observations, not a replacement for message-level and infrastructure checks. Pair it with:

  • complete Show original headers from personal Gmail test messages
  • SMTP acceptance, deferral, and rejection logs
  • DNS queries for SPF, DKIM, and DMARC
  • delivery reports from your sending system
  • campaign-level complaint or feedback identifiers where applicable
  • DMARC aggregate reports for broader receiver coverage

The Gmail email sender guidelines and Postmaster Tools dashboard documentation are the authoritative references for current Gmail scope, requirements, and dashboard behavior. The Postmaster Tools setup guide documents domain attribution and verification, while Google's sender requirements FAQ explains primary-domain bulk counting and subdomains.

The practical conclusion

Postmaster Tools does not promise a chart for every domain that appears in a From address. It needs a verified entry, qualifying mail to personal Gmail accounts, a match to the DKIM or SPF identity used by that mail, enough volume to meet Gmail's privacy protections, and time to process the data.

The most effective troubleshooting habit is simple: start with a real Gmail-delivered message, read its From, Return-Path, DKIM d=, and authentication results, then compare those identities with the domain and dashboard you selected. Treat subdomains as separate views but part of the same primary-domain volume story. Finally, allow for reporting delay before deciding that a verified and correctly configured stream is missing.

Previous Post