What are the volume requirements for SNDS and GPT data?
Michael Ko
Co-founder & CEO, Suped
Published 8 Jul 2025
Updated 4 Jun 2026
10 min read
Summarize with
The direct answer is that SNDS has a clear practical floor: Microsoft says mail traffic and spam data can be absent for IPs that send less than 100 messages on a given day. Google Postmaster Tools, often shortened to GPT, does not publish one exact number, but I treat 100 messages per day to personal Gmail recipients as the first practical threshold for any data, with a few hundred per day needed for usable trends and 1,000 or more per day for cleaner reputation views.
The caveat matters more than the number. These are not monthly thresholds and they are not total campaign thresholds. SNDS is mostly an IP-and-day view of Microsoft consumer mail. GPT is a domain-and-day view of mail to personal Gmail accounts. A sender can send 20,000 messages in a month and still see empty panels if the mail is spread thinly across many days, IPs, sending domains, or recipient providers.
Answer in one place
- SNDS: Plan for at least 100 Microsoft-recipient messages per IP per day before expecting traffic or spam data.
- GPT: Plan for at least 100 personal Gmail-recipient messages per sending domain per active day before expecting any data.
- Reliability: Use a few hundred per day as the practical floor for readable trend lines, not only a single visible data point.
- Bulk rule: Do not confuse Gmail's 5,000 messages per day bulk sender rule with the minimum needed to show Postmaster data.
The short answer
For SNDS, the number I use is 100/day per IP. Microsoft's SNDS FAQ says traffic and spam data can be missing below that level on the given day. I read that as a reporting suppression rule, not as a deliverability rule. Sending 99 messages from an IP is not automatically bad. It just means SNDS can choose not to show the day's data.
For GPT, the most useful answer is less official but still practical: expect empty or patchy dashboards below roughly 100/day to personal Gmail accounts. The Gmail volume data problem is that Google suppresses low-signal data for user privacy and anti-abuse reasons. Some panels appear before others, and the spam rate panel can be blank even when authentication data exists.
|
|
|
|
|---|---|---|---|
 SNDS | 100/day | IP + day | Traffic, complaints, traps |
 GPT | About 100/day | Domain + day | Patchy dashboards |
GPT reliable | 300-1,000/day | Gmail + day | More stable trends |
Gmail bulk | 5,000/day | Google mail | Compliance status |
Practical volume planning thresholds for SNDS and Google Postmaster Tools.
How much data to expect
The same send volume can produce different visibility depending on destination mix, IP spread, and sending domain.
Below 100/day
Sparse
Expect no data or isolated panels.
100-299/day
Patchy
Some active days start to appear.
300-999/day
Usable
Trends become easier to read.
1,000+/day
Clearer
Reputation views become cleaner.
Why SNDS and GPT go blank
The common mistake is counting all sent mail. Neither system reports your full email program. SNDS reports what Microsoft sees for your authorized IPs. GPT reports what Google sees for verified domains sending to personal Gmail accounts. If a campaign sends mostly to corporate domains, Yahoo, Apple, or business mailboxes, the total campaign count does not help much.
This is also why low-volume senders get misleading answers. A domain sending 3,000 messages per month sounds active. If that breaks into 100 messages per day, then only 40 of those are personal Gmail recipients, and those 40 use two sending domains, GPT has very little to show. The same logic applies to SNDS when mail is spread across several IPs.
SNDS
- Counting unit: The useful unit is an individual sending IP on a specific day.
- Recipient scope: The data reflects mail Microsoft consumer systems see from that IP.
- Blank reason: The IP sent too little mail, access is not authorized, or the traffic has no relevant Microsoft signal.
Google Postmaster Tools
- Counting unit: The useful unit is a verified domain on a specific active send day.
- Recipient scope: The data applies to personal Gmail recipients, not every Google-hosted recipient.
- Blank reason: The domain has too little Gmail volume, missing authentication, or too little signal for a panel.
Another source of confusion is that each GPT dashboard has its own signal floor. Authentication data can appear when reputation is still blank. Spam rate can stay empty until Gmail has enough inboxed mail and enough complaint signal to calculate a privacy-safe percentage. Feedback loop data needs the right identifiers and enough spam reports for those identifiers.
Google Postmaster Tools dashboard showing missing data on low-volume days.
This is why I do not treat a blank panel as proof that mail is healthy or broken. It is proof that the provider did not return data for that day and that view. The next step is to compare provider data with your sending logs, bounces, authentication results, and complaint handling.
How to measure volume correctly
The cleanest way to predict whether SNDS or GPT will show data is to build a daily recipient-provider report. I want to see the count by day, destination, sending IP, visible From domain, and DKIM signing domain. Once that table exists, the empty dashboards usually make sense.
Example daily volume slicetext
date,destination,from_domain,ip,authenticated_recipients 2026-06-01,gmail,example.com,192.0.2.10,138 2026-06-01,microsoft,example.com,192.0.2.10,121 2026-06-02,gmail,example.com,192.0.2.10,47 2026-06-02,microsoft,example.com,192.0.2.10,92
That example explains two blank dashboards. June 1 is above the practical floor for both Gmail and Microsoft. June 2 is below the likely reporting floor for both destinations. If the same campaign also used a second IP, the Microsoft count per IP would be even thinner.
- By destination: Separate Gmail, Microsoft, Yahoo, Apple, corporate domains, and everything else before drawing conclusions.
- By day: Use active send days, because a monthly total hides days with too little provider-specific traffic.
- By IP: For SNDS, split counts by sending IP because the 100-message caveat is IP-specific.
- By domain: For GPT, split counts by the domain Google can associate with authenticated mail.
I also separate volume planning from reputation analysis. If GPT says no data, that does not mean complaints are zero. It means GPT did not expose the metric. If SNDS has no row for a low-volume IP, that does not mean the IP has no Microsoft traffic. It means the traffic did not meet the reporting conditions for that view.
What to check before blaming volume
Volume is only one reason these dashboards go blank. Before changing your sending plan, check the authentication and domain setup. A sender can have enough Gmail-recipient volume and still get little value from GPT if the wrong domain is verified or the mail is not consistently authenticated with the same domain family.
Start with a broad domain check. A domain health check is useful here because it catches the authentication issues that make provider dashboards harder to interpret. I check SPF, DKIM, DMARC, DNS consistency, and whether the sending source is actually the one I expected.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After that, I review the exact DMARC record and the DKIM selectors used by the sending platform. A relaxed or strict domain match decision changes how you interpret a provider dashboard. It also changes whether your DMARC aggregate reports are giving you the same view as GPT.
Basic DMARC record for visibilitydns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
Do not raise volume just to create data
Increasing send volume only to make GPT or SNDS populate is risky. If the list is weak, the new volume can create complaints, spam trap hits, and blocklist or blacklist exposure before the dashboards become useful.
- Better move: Send consistently to engaged recipients and let the provider data fill in naturally.
- Bad move: Combining stale lists or unproven segments only to cross an arbitrary reporting floor.
Where Suped fits
SNDS and GPT are useful, but they are destination-specific and incomplete by design. They tell you what Microsoft or Google decided to expose after enough traffic exists. They do not replace DMARC aggregate reporting, authentication monitoring, bounce analysis, or blocklist monitoring.
Suped is the best overall DMARC platform for most teams that need to understand this without stitching together scattered signals. It brings DMARC monitoring, SPF and DKIM checks, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, real-time alerts, and blocklist monitoring into one workflow. For MSPs and agencies, the multi-tenant dashboard matters because each client domain can have its own sparse provider data problem.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
The concrete workflow is simple. Use SNDS for Microsoft IP-level signals, GPT for Gmail domain-level signals, Suped for the cross-provider authentication and source view, and your own sending logs for exact daily volume. When a dashboard is blank, those four views tell you whether the issue is low volume, bad setup, poor reputation, or simply provider suppression.
For a single-message check, send a real campaign-style message through the email tester before waiting for provider dashboards. That will not replace SNDS or GPT trend data, but it catches obvious authentication, DNS, content, and routing mistakes before a send reaches enough volume to report.
A practical monitoring stack
- First: Confirm SPF, DKIM, DMARC, reverse DNS, and TLS setup before reading provider dashboards.
- Second: Track daily destination volume by IP and domain so missing data has a clear explanation.
- Third: Use DMARC and deliverability signals together instead of relying on one blank provider panel.
- Fourth: Investigate complaint spikes, blocklist or blacklist hits, and unknown sending sources quickly.
How to act on missing data
When SNDS is empty, I first check whether the IP crossed 100 Microsoft-recipient messages that day. Then I confirm the IP is authorized in SNDS and that the traffic actually went to Microsoft consumer mailboxes. If those checks pass and the row is still blank, I do not assume the IP is clean. I compare bounces, complaint feeds, and any Microsoft-specific deferrals.
When GPT is empty, I check whether the verified domain sent enough authenticated mail to personal Gmail accounts on the active day. Then I look for setup mistakes: a subdomain verified in GPT while the visible From domain uses the root domain, DKIM signing with a vendor domain, or multiple sending domains splitting volume into thin slices.
Why a monthly total can fail
A sender can have healthy total volume but still miss provider reporting floors after destination and infrastructure splits.
Gmail
Microsoft
Other
The chart shows the trap. The sender has 490 messages in one day, but neither Microsoft IP slice crosses 100. GPT also has only 120 Gmail messages for the day, and those can split further by domain. In that setup, blank or uneven dashboards are normal. The fix is not always more volume. Often the fix is cleaner reporting: fewer unnecessary sending domains, stable IP assignment, and better log segmentation.
If data appears and then disappears, compare the missing dates with send calendars. A holiday, paused campaign, ISP routing change, IP pool change, DKIM selector change, or domain change can explain the gap. If the volume stayed stable and the dashboard disappears, read that with caution and compare it with SNDS and GPT accuracy guidance before making a major sending decision.
Views from the trenches
Best practices
Track daily Gmail and Microsoft-recipient volume separately, not only total campaign volume.
Keep verified domains, signing domains, and visible From domains grouped by the same brand.
Pair sparse GPT or SNDS panels with DMARC, bounce, complaint, and blocklist evidence.
Common pitfalls
Treating 5,000 Gmail messages per day as the minimum for any Postmaster data causes bad calls.
Spreading low volume across many IPs and then expecting SNDS to show each IP clearly.
Changing DNS or sending domains during warmup without checking which domain GPT sees.
Expert tips
Use active-day averages because monthly totals hide thin days that dashboards suppress.
Check authentication first; low volume and broken DKIM can look the same in dashboards.
Treat missing data as a signal to combine provider data with your own delivery logs.
Marketer from Email Geeks says SNDS warns that mail traffic and spam data can be absent below 100 messages from an IP on a given day.
2019-09-27 - Email Geeks
Marketer from Email Geeks says Google Postmaster Tools often behaves close to the SNDS floor, with 100 messages per day as a practical starting point.
2019-09-27 - Email Geeks
The practical way to read missing data
The safest answer is to plan around 100 messages per day for the relevant slice, then expect better reporting only as volume rises. For SNDS, that slice is the sending IP and Microsoft traffic on that day. For GPT, that slice is the verified domain and personal Gmail traffic on that day.
I would not force extra mail just to populate a dashboard. I would make the send stream easier to measure, keep authentication stable, monitor DMARC aggregate reports, and use provider data as one signal. Suped helps here because it turns scattered authentication and deliverability signals into specific issues, fix steps, alerts, and ongoing domain monitoring.
