Why does SNDS show more message recipients than I sent?
Updated on 14 Aug 2026: We corrected how SNDS message recipients relate to RCPT and DATA commands and added the latest reporting changes.
SNDS can show more message recipients than your sending report because the two systems often count different things. SNDS counts recipients on messages actually transmitted from an IP. An ESP report might count campaign rows, unique contacts, or messages. Other traffic on the IP, a different reporting window, and a genuine retransmission can also increase the SNDS total.
Treat the mismatch as a signal to investigate, not as proof that extra mail was delivered. The useful question is: "How many recipients were on messages transmitted from this IP during the SNDS activity period?" That total does not always match a campaign's message count or unique audience.
Fast answer
If SNDS is higher than your ESP send count, check these areas before assuming abuse or a reporting error.
- Reporting unit: Confirm whether the ESP counts messages, unique contacts, or recipient events.
- Shared or rotated IP: SNDS reports by IP, so the total can include other traffic on that route.
- Hidden sources: Transactional mail and automations can use the same outbound IP.
- Time and SMTP outcome: Normalize the reporting window, then check logs for an actual retransmission.
What SNDS is counting
Microsoft SNDS is an IP-based view of traffic reaching Outlook.com consumer mail infrastructure. If an ESP sends through an IP, SNDS attaches the data to that IP. It does not know your campaign name, segment size, sending domain ownership, or the counting rules used in your ESP dashboard.
Microsoft SNDS screen with IP-level recipient and filter data.
|
|
|
|---|---|---|
Different reporting unit | Transmitted recipients | Recipient export |
Shared or rotated IP | All traffic on the IP | ESP route |
Different time window | SNDS activity period | Normalized timestamps |
Retransmission | Another transmitted copy | SMTP logs |
Common reasons SNDS recipient totals exceed campaign totals.
The SNDS fields describe separate SMTP stages. RCPT commands count recipient requests, DATA commands count message-content transfers, and message recipients count recipients on messages actually transmitted by the IP. Message recipients are not necessarily unique people. For a deeper Microsoft-specific workflow, use SNDS troubleshooting alongside your ESP logs.
Do not compare the wrong totals
One message addressed to ten recipients can contribute ten message recipients in SNDS. A dashboard that records that event as one sent message will therefore show a lower number.
- Campaign count: The rows, messages, or unique contacts shown by the ESP.
- RCPT commands: Recipient requests made during SMTP sessions, including repeated attempts.
- DATA commands: Message-content transfers after the recipient stage.
- Message recipients: Recipients on messages actually transmitted from the IP.
How retries affect SNDS counts
A temporary 4xx response tells the sender to try again. If Microsoft defers the recipient at the RCPT stage, the retry increases RCPT commands, but the deferred attempt does not become a message recipient because no message was transmitted. A retry increases message recipients only when another copy is actually transmitted, such as after the sender misses or cannot confirm the final SMTP acknowledgement.
Simplified retry sequencetext
RCPT TO:<user@example.com> 451 4.7.500 temporarily deferred retry: RCPT TO:<user@example.com> 250 2.1.5 recipient accepted DATA 250 2.0.0 message accepted
Campaign send log
- Audience: The ESP can show one intended recipient.
- Message: The campaign can still show one sent message.
- Detail: A summary dashboard can omit intermediate SMTP events.
Microsoft receiving view
- RCPT activity: The deferred request and later retry are separate commands.
- Transmission: Only the accepted message transfer adds a recipient.
- Duplicate transfer: A second transmitted copy can add another recipient event.
This distinction is why raw SMTP logs matter even when the campaign report looks normal. Ask the ESP for RCPT responses, DATA events, final acknowledgements, retransmissions, and the exact outbound IP used for the send. If the ESP only provides aggregate campaign reporting, request a support export for the relevant activity period.
Example of how IP traffic exceeds one campaign
An illustrative 10,000-recipient campaign can sit beside other IP traffic and confirmed retransmissions.
Campaign recipients
Other IP traffic
Retransmitted recipients
Shared IPs and ESP reporting gaps
If you send through an ESP, confirm whether the IP is dedicated to you. On a shared, pooled, or rotated IP, SNDS can include traffic belonging to other customers using the same route. 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, pooled, or rotated.
- Route scope: Ask whether transactional and marketing mail share the route.
- Reporting basis: Ask what the ESP's sent number counts and which time zone it uses.
- Event export: Request raw events for the SNDS activity period that 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 your domain's sources
SNDS shows Microsoft traffic for an IP. DMARC aggregate reports show source IPs using your domain, reported message volume, authentication results, and domain matching. The reports can identify extra traffic tied to your domain, but they do not reveal unrelated domains sharing an IP and will not reconcile one-for-one with SNDS.
If your domain publishes a DMARC record with an 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; adkim=s; aspf=s
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's product turns DMARC aggregate reports into source breakdowns, authentication results, volume views, and issue lists. In this workflow, Suped helps confirm whether the SNDS IP sent as your domain and whether another approved or unknown source explains traffic outside the campaign report.
What to look for in DMARC data
- Source IP: Compare IPs reported for your domain with the SNDS IP.
- Reported volume: Check for traffic when no campaign was scheduled.
- Domain match: Confirm whether SPF or DKIM used the visible From domain.
- Unknown traffic: Investigate sources that nobody on the team recognizes.
If you do not yet have a reporting view, Suped's DMARC monitoring can organize aggregate reports before you move to stricter policy enforcement. Use the source data to explain your domain's traffic, while keeping shared-IP traffic outside your domain as a separate question.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A practical investigation workflow
Start by confirming the metric and activity period, then identify the IP route and compare SNDS message recipients with transmitted-recipient events. Use RCPT responses to diagnose deferrals. Change throttling, segmentation, or policy only after the evidence identifies a cause.
SNDS recipient-count investigation across IP routing, SMTP logs, and DMARC sources.
- Confirm the metric: Check whether the comparison uses messages, unique contacts, or recipients.
- Confirm IP ownership: Ask whether the IP in SNDS is dedicated, shared, pooled, or rotated.
- Pull SMTP events: Get RCPT responses, DATA events, acknowledgements, and retransmissions.
- Compare activity periods: Normalize time zones before matching SNDS with campaign and automation traffic.
- Check DMARC: Use aggregate reports to identify sources sending as your domain.
- Fix the cause: Correct reporting, clean up sources, or ask the ESP to adjust the route.
A real seed message helps confirm the current sending path and authentication results. Suped's email tester provides the headers and checks needed to inspect the message instead of inferring its route from SNDS alone.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If SNDS shows traffic during an activity period where the ESP shows no campaign activity, expand the review. Check triggered journeys, password resets, invoices, account notifications, support tooling, and every platform that can send as the domain. DMARC reports can identify the sources visible for your domain.
When to worry and when to ignore it
A higher SNDS recipient count is not automatically bad. It needs investigation when the difference is persistent, unexplained, tied to poor filter results, or visible alongside complaint changes, authentication failures, unusual traffic patterns, or blocklist and blacklist signals.
Practical mismatch triage
These are investigation bands, not Microsoft-published thresholds.
Explainable
Low concern
Matches the reporting unit, IP route, activity period, or a logged retransmission.
Unclear
Investigate
The ESP cannot confirm its counting rules, timestamps, or outbound route.
Reputation issue
Urgent
The high count appears with red filter results, complaints, or listings.
Microsoft moved SNDS to its new portal and deprecated the old automated-access URLs. Microsoft also stopped including trap-hit counts in the SNDS Data Report. Refresh automated exports and do not treat a missing trap-hit field as evidence of zero hits.
Usually explainable
- Reporting basis: The ESP and SNDS count different units or activity periods.
- Shared route: The IP carries traffic outside the campaign.
- Stable reputation: Filter results and complaint signals remain stable.
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 or blocklist data changes at the same time.
Check the broader domain setup because weak authentication makes a reputation investigation slower. A domain health check can confirm whether DMARC, SPF, and DKIM are present before deeper log analysis.
SNDS is an aggregate, provider-specific view. Compare message recipients with SMTP transmission logs and use DMARC reports for domain-source context before making a reputation decision. For more detail on that limitation, see SNDS accuracy and apply the same caution to day-by-day changes.
How Suped fits into this workflow
Suped does not replace SNDS because SNDS has Microsoft-side IP data. Suped adds domain authentication and source visibility. When a sender says "I sent 20,000, but SNDS shows 35,000", Suped helps identify which source IPs sent as the domain, whether the messages authenticated, and whether unknown domain traffic contributes to 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 activity period.
- Find issues: Use issue detection to spot failing SPF, DKIM, or domain matching.
- Stage policy: Use hosted DMARC to move toward enforcement while preserving reports.
- Track reputation: Monitor domain and IP blocklist or blacklist signals in the same workflow.
Views from the trenches
Best practices
Compare SNDS message recipients with transmitted-recipient events, not campaign row totals.
Normalize ESP timestamps to the SNDS activity period before comparing daily volume.
Ask whether the SNDS IP is dedicated, shared, pooled, or rotated for each route.
Common pitfalls
Treating message recipients as RCPT attempts makes ordinary deferrals look like deliveries.
Comparing campaign message rows with recipient totals hides multi-recipient messages.
Expecting DMARC totals to expose unrelated domains sharing the same outbound IP.
Expert tips
Save daily SNDS exports with SMTP logs because the portal is not a long-term log archive.
Compare RCPT commands, DATA commands, and message recipients before assigning a cause.
Document time zones and outbound IPs so daily totals can be matched during an audit.
Marketer from Email Geeks says SNDS message recipients count recipients on messages transmitted by the IP, not RCPT attempts.
2026-06-04 - Email Geeks
Marketer from Email Geeks says aggregate DMARC reports help identify which sources sent mail using the domain.
2026-06-05 - Email Geeks
Bottom line
SNDS showing more message recipients than your sending report usually means the reports count different units or cover different traffic. SNDS counts recipients on messages actually transmitted from the IP. Multi-recipient messages, shared or rotated IP traffic, hidden sources, activity-period differences, and confirmed retransmissions can make that total higher.
Line up SNDS message recipients with transmitted-recipient logs for the same IP and activity period. Use RCPT commands to analyze deferrals, then use DMARC reports to identify sources sending as your domain. The mismatch is actionable once those views point to the same cause.
