Why does SNDS show more message recipients than I sent?
Michael Ko
Co-founder & CEO, Suped
Published 13 Jun 2026
Updated 13 Jun 2026
8 min read
Summarize with
SNDS can show more message recipients than you sent because it counts recipient attempts seen by Microsoft at the IP level, not just the number of campaign addresses in your ESP. Deferrals and retries are the most common reason on a dedicated IP. Shared IP traffic, forwarding, resend behavior, and mail you did not know was using the same IP can also increase the number.
I treat the mismatch as a signal to investigate, not as proof that extra mail was sent. The right question is not only "how many people were in the campaign?" It is "how many recipient-level delivery attempts did Microsoft see for this IP during that day?" Those two numbers are related, but they are not the same metric.
Fast answer
If SNDS is higher than your ESP send count, check these four areas before assuming abuse or a reporting error.
- Deferrals: Temporary Microsoft responses cause retries, and retries add recipient attempts.
- Shared IP: SNDS reports by IP, so another sender on the same pool can affect the count.
- Hidden sources: Transactional mail, automations, and forgotten tools can send through the same domain or IP.
- Wrong baseline: Campaign sends, accepted deliveries, and recipient attempts are separate numbers.
What SNDS is counting
Microsoft SNDS is an IP-based reputation and traffic view for mail accepted or attempted against Microsoft consumer mail infrastructure. The important detail is IP-based. If your ESP sends through an IP, SNDS attaches the data to that IP. It does not know your campaign name, your segment size, or whether the ESP dashboard is counting unique recipients, accepted recipients, or attempted recipients.
Microsoft SNDS screen with IP-level recipient and filter data.
|
|
|
|---|---|---|
Deferrals | Retry attempts | Bounce logs |
Shared IP | Pool traffic | ESP route |
Automations | Extra sends | DMARC data |
Forwarding | New attempts | Headers |
Common reasons SNDS recipient totals exceed campaign totals.
The SNDS field that confuses people most is message recipients. In practice, I read it as recipient-level attempts that Microsoft observed for the IP in the reporting window. It is closer to RCPT TO activity than to a campaign audience count. For a deeper Microsoft-specific workflow, use SNDS troubleshooting alongside your ESP logs.
Do not compare the wrong totals
A campaign sent to 10,000 addresses can generate more than 10,000 recipient attempts if Microsoft defers part of the traffic and the ESP retries those recipients.
- Campaign count: How many recipients you targeted in the send.
- Accepted count: How many recipients the receiving system accepted.
- Attempt count: How many delivery attempts were made after retries and routing.
The most common cause: deferrals and retries
On a dedicated IP, deferrals are the first place I look. A deferral is a temporary 4xx response. It tells the sender to try again later. The message was not accepted yet, so the ESP keeps retrying. Each retry can include the same recipient again, and SNDS can count those recipient attempts.
Simplified retry sequencetext
RCPT TO:<user@example.com> 451 4.7.500 temporarily deferred retry 1: RCPT TO:<user@example.com> retry 2: RCPT TO:<user@example.com> 250 2.1.5 recipient accepted
Campaign send log
- Audience: The ESP shows one intended recipient.
- Status: The final event can show delivered or accepted.
- View: The dashboard often hides every intermediate retry.
Microsoft receiving view
- Attempt one: The first recipient attempt is temporarily deferred.
- Attempt two: A later retry reaches the same recipient.
- View: SNDS sees multiple recipient attempts for one address.
This is why the bounce and SMTP logs matter even if the campaign report looks normal. Ask your ESP for Microsoft-specific deferral counts, retry counts, final acceptance counts, and the exact outbound IP used for the send. If they only provide aggregate campaign reporting, ask for a support export for the relevant date.
Example of how one campaign grows in SNDS
An illustrative 10,000-recipient campaign can create more recipient attempts after deferrals and retries.
Original audience
Retry attempts
Other IP traffic
Shared IPs and ESP reporting gaps
If you send through an ESP, the next question is whether the IP is dedicated to you. On a shared or pooled IP, SNDS can include traffic that belongs to other customers using the same sending infrastructure. Your ESP dashboard can show your campaign volume while SNDS shows all traffic Microsoft associated with the IP.
Ask the ESP for IP context
- IP type: Confirm whether the IP is dedicated, shared, or rotated.
- Route scope: Ask whether transactional and marketing mail share the same route.
- Retry policy: Ask how long Microsoft deferrals are retried and how they are counted.
- Event export: Request raw events for the date where SNDS looks high.
This also matters for reputation checks. A shared IP with poor traffic can create Microsoft filtering pressure and can appear on a blocklist or blacklist even when your own campaign was small. Suped's blocklist monitoring helps track IP and domain listings while you work through the SNDS evidence.
Use DMARC reports to verify the source
SNDS tells you what Microsoft saw for an IP. DMARC aggregate reports tell you which sources sent mail using your domain, how SPF and DKIM evaluated, and whether the mail matched your domain. That is the fastest way to check whether the extra volume came from your ESP, another approved source, or something unauthorized.
If your domain publishes a DMARC record with a rua destination, aggregate reports are already being sent somewhere. The reporting address usually points to an internal mailbox or a DMARC platform. If nobody on the team knows where the reports go, check DNS first.
DMARC record with aggregate reportingdns
_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=s; aspf=s
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
This is where Suped's product is useful in a concrete way. Suped turns XML aggregate reports into source breakdowns, authentication results, sending volume, and issue lists. For most teams, Suped is the best overall DMARC platform for this investigation because it connects DMARC monitoring, SPF and DKIM checks, hosted DMARC, hosted SPF, hosted MTA-STS, real-time alerts, and blocklist (blacklist) monitoring in one place.
What to look for in DMARC data
- Source name: Find every platform sending as your domain.
- IP match: Compare the SNDS IP with IPs in aggregate reports.
- Volume trend: Look for traffic on days when no campaign was scheduled.
- Authentication: Check whether SPF and DKIM passed and matched the domain.
If you do not yet have a reporting view, start with DMARC monitoring before moving to stricter policy enforcement. The count mismatch is easier to explain once you can see every source using the domain.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A practical investigation workflow
I use a simple sequence when SNDS volume looks higher than expected. Start with the IP, then confirm the route, then compare accepted deliveries against recipient attempts. Only after that does it make sense to change throttling, segmentation, or policy.
Flowchart for investigating high SNDS recipient counts.
- Confirm IP ownership: Ask whether the IP in SNDS is dedicated to you or shared with other senders.
- Pull ESP events: Get accepted, deferred, bounced, and retried recipient events for Microsoft domains.
- Compare days: Check whether high SNDS days match actual send days, retry windows, or automation traffic.
- Check DMARC: Use aggregate reports to identify every sender using the domain.
- Test a message: Send a real email and inspect SPF, DKIM, DMARC, headers, and routing.
- Fix the cause: Tune sending pace, clean up sources, or ask the ESP to adjust the Microsoft route.
A real seed message helps confirm whether the current sending path is authenticating correctly. Suped's email tester gives you a practical way to inspect the message rather than guessing from SNDS alone.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If SNDS shows traffic on days where your ESP shows no campaign activity, expand the review. Check triggered journeys, password resets, invoices, account notifications, support tooling, and any platform that can send as the same domain. DMARC reports are usually the quickest way to find the missing source.
When to worry and when to ignore it
A higher SNDS recipient count is not automatically bad. It becomes a concern when the difference is persistent, unexplained, tied to poor filter results, or visible alongside complaint spikes, trap hits, authentication failures, or blocklist and blacklist signals.
How I triage the mismatch
These are practical investigation bands, not Microsoft-published thresholds.
Explainable
Low concern
Matches known Microsoft deferrals or retry windows.
Unclear
Investigate
No obvious retry pattern or the ESP cannot confirm routing.
Reputation issue
Urgent
High count appears with red filters, complaints, or listings.
Usually explainable
- Retry evidence: ESP logs show Microsoft 4xx deferrals.
- Shared route: The IP belongs to a pool with other senders.
- Stable reputation: No filter, complaint, or trap problem appears.
Needs investigation
- Unknown source: DMARC data shows a sender nobody owns.
- Bad filtering: SNDS filter results turn red on high-volume days.
- Reputation signal: Complaint, trap, or blocklist data changes at the same time.
I also check the broader domain setup, because weak authentication makes every reputation investigation slower. A domain health check can confirm whether DMARC, SPF, and DKIM are present before you spend time on deeper log analysis.
SNDS is useful, but it is still a sampled, provider-specific view. Compare it with your own logs and DMARC reports before making a reputation decision. If you need more context on that limitation, see SNDS accuracy and use the same caution when reading day-by-day changes.
How Suped fits into this workflow
Suped does not replace SNDS, because SNDS has Microsoft-side IP data that belongs in the investigation. Suped fills the gap around domain authentication and source visibility. When a sender says "I sent 20,000, but SNDS shows 35,000", Suped helps answer which platforms sent, whether they authenticated, and whether unauthorized traffic is part of the mismatch.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Useful Suped workflow
- Compare volume: Review source-level DMARC volume beside the SNDS day.
- Find issues: Use automated issue detection to spot failing SPF, DKIM, or domain matching.
- Stage policy: Use hosted DMARC to move toward enforcement without losing visibility.
- Track reputation: Monitor domain and IP blocklist or blacklist signals in the same workflow.
Views from the trenches
Best practices
Compare SNDS counts with ESP accepts, deferrals, and retries before changing policy.
Keep DMARC aggregate reports flowing so source volume is visible outside SNDS each day.
Ask the ESP whether the SNDS IP is shared, pooled, dedicated, or changing by route.
Common pitfalls
Treating message recipients as campaign sends hides retries and shared IP traffic.
Ignoring 4xx deferrals makes one campaign look larger than it was at Microsoft receivers.
Relying only on domain reports misses IP-based data that SNDS reports by design daily.
Expert tips
Save a daily SNDS export beside ESP bounce logs so timing patterns stay visible later.
Review RUA destinations in DNS before assuming nobody has DMARC reporting access.
Separate Microsoft recipient attempts from accepted deliveries in internal reporting.
Marketer from Email Geeks says SNDS counts recipient attempts at the IP level, so a dedicated IP points attention toward retries and deferrals.
2026-06-04 - Email Geeks
Marketer from Email Geeks says aggregate DMARC reports are the fastest way to check which sources sent mail under the domain.
2026-06-05 - Email Geeks
My bottom line
SNDS showing more message recipients than you sent is usually an accounting mismatch between campaign recipients and Microsoft recipient attempts. Deferrals and retries explain many cases, especially on a dedicated IP. Shared IP traffic explains many ESP cases.
The fix is to line up three views: SNDS for IP-level Microsoft data, ESP logs for deferrals and retries, and DMARC reports for source-level domain activity. Once those agree, the cause is usually clear enough to act on.
