Summary
Discrepancies between Microsoft's SNDS (Smart Network Data Services) and Salesforce Marketing Cloud (SFMC) reports regarding email delivery data are a common challenge for email marketers, particularly during IP warming. While SFMC might indicate emails as 'delivered', SNDS can show significantly lower receipt volumes (RCPT and DATA columns), or even no data at all for a period when blocks occurred. This divergence often leads to confusion, as marketers struggle to reconcile their sending platform's success metrics with the insights provided by the recipient domain's postmaster tools.
Key findings
- Data lag: SNDS data can be delayed, sometimes by several hours or even a full day, which means real-time deliverability issues might not immediately reflect in its reports.
- Timezone differences: Email sending times and the timezone used by SNDS can lead to data being attributed to different days, causing apparent discrepancies.
- Silent drops: Microsoft may sometimes accept emails at the SMTP level (leading SFMC to report 'delivered') but then silently drop them or filter them to spam before they appear in the SNDS DATA column, especially during reputation challenges.
- Incomplete SNDS data: On occasion, SNDS itself may fail to report complete data for certain days, regardless of sending volume or status.
- Bounce clarity: While hard blocks typically result in immediate SMTP bounces (visible in SFMC), temporary rate limits (4xx bounces) can delay bounce reporting for up to 72 hours, creating a temporary mismatch.
Key considerations
- Consult SMTP logs: For definitive proof of what was accepted by Microsoft, the most reliable source is the raw SMTP logs from your sending platform. SFMC should have access to these, even if they're not directly exposed to users.
- Distinguish bounces: Understand the difference between hard bounces (permanent failures), soft bounces (temporary issues that might retry), and silent drops. SFMC's bounce reports should differentiate these.
- SNDS RCPT vs. DATA: The RCPT (recipients) column in SNDS indicates how many recipients were attempted, while DATA (messages) indicates how many messages were successfully transferred. A large difference suggests rejections at the data transfer stage, which is still a block. However, if both are low compared to sent volume, it could indicate pre-SMTP filtering or 'silent drops'.
- Proactive monitoring: Regularly cross-reference your ESP's delivery reports with postmaster tools like SNDS to catch discrepancies early. For more on monitoring SNDS data, refer to our guide on how to get SNDS and JMRP data.
- Engage your ESP: While ESPs may not directly support third-party tools, they should be able to clarify their own internal reporting and provide deeper insights into message acceptance, especially if their reported 'delivered' counts don't align with recipient-side data. For details on how SFMC identifies failed email sends, this Medium article offers useful pointers.
What email marketers say
Email marketers often find themselves in a challenging position when their sending platform's delivery metrics don't align with the data reported by postmaster tools like SNDS. This can be particularly frustrating when trying to understand deliverability to major ISPs like Microsoft. Marketers frequently rely on their ESP's 'delivered' status, but then find that SNDS shows a different picture, leading to confusion about where emails are truly landing, if at all. The lack of transparent reconciliation from ESPs on these discrepancies can further complicate troubleshooting efforts.
Key opinions
- SFMC 'delivered' isn't inboxed: Many marketers observe that even if Salesforce Marketing Cloud reports emails as 'delivered' to Microsoft domains, they are actually ending up in the spam folder or not being received at all.
- SNDS data can be unreliable or missing: There are instances where SNDS data is incomplete or simply not available for certain days, making it difficult to track reputation and delivery precisely.
- Silent drops are a real concern: Marketers suspect that a significant volume of emails might be silently dropped by Microsoft, meaning they are accepted at the SMTP level by SFMC but never truly reach a recipient's inbox or even the SNDS DATA count.
- IP warming complexity: During IP warming, these data discrepancies add a layer of complexity, as it becomes harder to gauge the actual progress of reputation building.
- Need for ESP support: Marketers emphasize the need for ESPs like SFMC to provide more granular data and support in reconciling these external reports, rather than simply stating that SNDS is not their product.
Key considerations
- Verify SFMC reports: Marketers should thoroughly check SFMC's deliverability by domain reports and bounce logs. For inconsistencies, tools that track individual email results can be helpful.
- Understand deferred bounces: Be aware that some temporary blocks (4xx bounces) may not appear in SFMC's bounce reports for up to 72 hours, which can initially skew delivery numbers.
- Continuous sending (with caution): While some recommend continuing to send to provide Microsoft with data, simply hoping issues resolve themselves without addressing underlying problems is generally not an effective remediation strategy. For more on general deliverability issues, see our guide on email deliverability issues.
- Analyze engagement metrics: Low open rates at Microsoft domains, even with reported delivery, are a strong indicator that emails are going to spam. This can be more telling than raw delivery counts alone.
- Push for transparency: Advocate for better data visibility from your ESP, especially regarding SMTP level logs and reasons for divergences with postmaster tools.
An Email Geeks marketer noted that after being blocked, their SNDS data showed significantly lower RCPT and DATA volumes than their 10,000 daily sending volume to Microsoft, even though SFMC reported deliveries. This suggests an issue beyond simple bounces, potentially with how Microsoft processes or reports accepted mail.
A deliverability professional from Email Geeks mentioned that sometimes SNDS data is simply missing, implying that not all deliverability events are consistently recorded or presented in the tool.
What the experts say
Deliverability experts often point out that the reporting mechanisms of ESPs and recipient-side postmaster tools operate at different points in the email delivery chain, which naturally leads to discrepancies. While an ESP's 'delivered' status typically means the email was accepted at the SMTP handshake, a postmaster tool like SNDS provides insight into what happened after that point, including internal filtering, spam folder placement, or even 'silent drops' where messages are accepted but never truly processed for delivery to the inbox or spam folder. Understanding these nuances is crucial for accurate troubleshooting and maintaining sender reputation.
Key opinions
- SMTP acceptance vs. Inbox placement: An ESP reporting 'delivered' means the receiving mail server accepted the message via SMTP. It does not guarantee inbox placement, which is a key reason for discrepancies with postmaster tools that reflect a deeper level of filtering.
- Postmaster tools are secondary indicators: While useful, SNDS and similar tools provide an aggregate view and can have their own data processing quirks, delays, or even occasional outages, impacting data accuracy.
- Silent drops are a reality: Major ISPs, including Microsoft, can employ 'silent drops' where messages are accepted without an SMTP bounce code but are then discarded or heavily filtered before reaching the recipient's mailbox, leading to a discrepancy between ESP and postmaster tool counts.
- Engagement is the ultimate metric: Even if a volume appears 'delivered' by the ESP or accepted by SNDS, low open and click rates are the truest indicator of poor inbox placement or heavy filtering. This is covered in our article on why emails are not appearing in the inbox.
Key considerations
- Holistic view: Do not rely on a single data source. Combine ESP reports, SNDS, Google Postmaster Tools, and engagement metrics for a comprehensive view of your deliverability.
- Address underlying reputation issues: If discrepancies point to consistent filtering or silent drops, focus on improving sender reputation through list hygiene, content optimization, and authentic engagement, rather than just raw volume. Our guide on why your emails fail provides expert advice.
- Understand postmaster tool limitations: Be aware that tools like SNDS may not always provide perfect real-time or complete data. They offer trends and indicators, not absolute counts of every single email.
- Proactive IP warming: During IP warming, gradual increases in volume and careful monitoring of feedback loops (FBLs) and SNDS data are paramount. Sudden volume spikes, especially with a new IP, can trigger aggressive filtering, regardless of initial 'delivered' statuses.
- Leverage ESP expertise: Work closely with your ESP's deliverability team to interpret discrepancies and understand their internal reporting mechanisms and any known issues with specific ISPs.
A deliverability expert from Word to the Wise suggests that an ESP's reported delivery rate merely indicates successful SMTP hand-off, not necessarily inbox placement. Discrepancies arise because recipient servers can still filter or discard mail after acceptance, which won't be reflected in the sender's logs.
An Email Geeks deliverability professional stated that they have observed more cases of 'silent drops' at Microsoft lately, where the DATA column in SNDS does not reflect the full volume sent. They noted this indicates a processing issue beyond typical SMTP bounces.
What the documentation says
Official documentation from email service providers (ESPs) and ISPs outlines how delivery data is collected and presented. SFMC's 'delivered' status generally means the email was successfully handed off to the recipient's mail server via SMTP. Microsoft's SNDS, on the other hand, provides insights from the receiving end, including volume of messages processed, spam complaints, and reputation status. The discrepancies often arise from the different stages of processing an email goes through once accepted by the receiving server, which may include internal filtering, deferrals, or discarding before actual inbox delivery.
Key findings
- SMTP acceptance definition: Most ESPs define 'delivered' as receiving a 2xx SMTP response from the recipient's mail server, indicating acceptance of the message. This acceptance does not, however, guarantee inbox placement.
- SNDS data types: SNDS provides data points like RCPT (number of unique recipients attempted by an IP) and DATA (number of messages successfully transferred). These numbers reflect Microsoft's view of traffic and can differ from ESP 'delivered' counts due to Microsoft's internal processing.
- Spam classification: Emails classified as spam by Microsoft's filters will still count towards RCPT and DATA if they are initially accepted, but they will be routed to the junk folder. Significant differences between ESP 'delivered' and SNDS 'DATA' can suggest pre-SMTP rejection or deeper filtering.
- Bounce codes: Documentation typically outlines that 5xx SMTP codes are hard bounces, while 4xx codes are temporary failures. ESPs will retry 4xx errors, and these may not be reported as final bounces until retry attempts are exhausted (e.g., 72 hours).
Key considerations
- Reference official guides: Consult Microsoft's official SNDS documentation and Salesforce Marketing Cloud's help articles for precise definitions of metrics and troubleshooting steps. This can help clarify what each platform's data represents.
- SMTP log review: ESP documentation confirms that SMTP transaction logs are the most granular source of information about what occurred during the hand-off between sending and receiving servers. These logs are often what postmaster tools process for their reports.
- Latency awareness: Understand that data in postmaster tools is not always real-time. There can be a delay between when an email is sent/processed and when its corresponding data appears in SNDS reports.
- Filtering complexities: ISP documentation highlights that mail goes through multiple layers of filtering (connection, content, reputation) after initial SMTP acceptance, and a clean SMTP hand-off doesn't mean successful inboxing. This explains why an ESP's 'delivered' count might be high, while inbox placement is low.
Microsoft's Smart Network Data Services (SNDS) documentation specifies that the DATA column represents the count of messages that were successfully transferred via SMTP and processed by their systems. Discrepancies with sending ESPs often arise if mail is accepted but then filtered internally before full processing.
The Salesforce Marketing Cloud documentation on email delivery states that an email is considered 'delivered' once the receiving mail server sends back a 250 OK response, signifying successful receipt of the message. This is a crucial distinction, as it doesn't guarantee inbox placement.
