What are the limitations of Amazon SES regarding Microsoft SNDS access and is there a workaround?
Published 7 May 2025
Updated 21 Oct 2026
12 min read
Summarize with
Updated on 21 Oct 2026: We updated the SES SNDS workflow for Microsoft's portal changes, trap-data limits, complaint-rate interpretation, and delivery incident escalation.
Amazon SES does not let customers add leased SES dedicated IPs to their own Microsoft SNDS account. This applies to standard and managed dedicated IPs. The supported path is to view SES-provided SNDS metrics in Amazon CloudWatch, not to request direct authorization through the SNDS portal. There is no customer-side setting that overrides this for leased SES IPs.
The practical workaround is partial but official. Amazon publishes SNDS data for dedicated IPs into CloudWatch, including recipient commands, DATA commands, message recipients, spam rate, and complaint rate. The current AWS SNDS metrics documentation describes regional access and also lists SNDS.TrapHits. Check its current availability before relying on trap-hit monitoring, because Microsoft removed trap counts from its SNDS Data Report.
The short version
If you need direct Microsoft SNDS portal control, SES leased IPs are the wrong control point. If you need a daily Microsoft reputation signal for SES dedicated IPs, CloudWatch is the supported control point.
Why SES dedicated IPs lack direct SNDS access
The limitation exists because Amazon owns and operates the SES IP space. Leasing a dedicated IP gives your account exclusive sending use and control of its sending reputation, but it does not transfer ownership of the address or the Microsoft authorization path. Microsoft asks the party responsible for the IP range to approve SNDS access, and AWS does not delegate that approval to SES customers.
SES domain verification, production access, and IAM permissions do not authorize access to Microsoft SNDS. The restriction concerns responsibility for the sending IP range. SES gives you a defined set of SNDS-derived metrics through CloudWatch, but it does not give you the complete SNDS account relationship with Microsoft for those leased IPs.
- You cannot add SES leased dedicated IPs to your own Microsoft SNDS account through normal Microsoft verification.
- SES surfaces a defined set of SNDS metrics in CloudWatch for dedicated IPs in each AWS Region.
- You do not get the same portal view, access controls, or JMRP feed administration available to an authorized IP operator.
- Use CloudWatch for SES IP telemetry, or send the affected mail through IPs that your organization can authorize directly in SNDS.
|
|
|
|
|---|---|---|---|
Daily IP signal | Yes | Yes | Use CloudWatch |
Portal control | No | Yes | Use authorized IPs |
Raw context | Limited | Broader | Add SES logs |
JMRP administration | No direct access | In the portal | Use SES complaints |
SES SNDS access compared with direct Microsoft SNDS access.
Which SES IP pools expose SNDS data
The answer depends on the SES IP pool. Shared IPs do not give an SES customer a stable, exclusive address to monitor. Standard dedicated IPs expose per-IP SNDS metrics in CloudWatch. Since Amazon's managed-IP observability update, managed dedicated pools also expose their allocated IP addresses and per-IP SNDS metrics.
|
|
|
|
|---|---|---|---|
Shared | Addresses can change | No per-customer IP view | AWS manages the shared reputation |
Dedicated standard | Known static IPs | Per-IP CloudWatch metrics | No direct portal authorization |
Dedicated managed | Allocated IPs are visible | Per-IP CloudWatch metrics | Pool membership can scale |
SNDS visibility by Amazon SES IP pool type.
Managed pools can still use shared IPs
During warmup, sudden volume changes, or low-volume periods, a managed dedicated pool can route some mail through the SES shared pool. Its dedicated-IP SNDS metrics describe the dedicated portion, not every message sent with that configuration set. Compare them with the managed pool's dedicated sending percentage before attributing all Microsoft results to one IP.
What Amazon SES gives you instead
The CloudWatch route gives a measurable Microsoft-side signal without granting customer access to AWS-controlled IP authorization. Use it as a reputation alarm source, not as a complete forensic record.
SNDS metrics listed in AWS documentationtext
CloudWatch path: Metrics > All metrics > SES > IP Metrics Scope: One selected dedicated IP SNDS.RCPTCommands SNDS.DATACommands SNDS.MessageRecipients SNDS.SpamRate SNDS.ComplaintRate SNDS.TrapHits
These metrics are updated once a day and carry a timestamp for a 24-hour activity period. They also depend on Microsoft receiving enough qualifying traffic to calculate a value. If an IP sends low volume to Outlook.com, Hotmail.com, Live.com, or related Microsoft consumer domains, CloudWatch can show gaps. Treat missing points as missing telemetry rather than evidence that reputation has recovered.
Check trap-hit data availability
Microsoft announced that trap-hit counts would leave the SNDS Data Report on July 22, 2026. AWS still documents SNDS.TrapHits, so verify fresh CloudWatch points before depending on a trap alarm. A missing series does not establish a clean list. See the SNDS portal for Microsoft announcements.
Treat the data as Outlook.com network telemetry. It covers the consumer domains Microsoft tracks in SNDS, including Outlook.com, Hotmail.com, and Live.com. It is not tenant-level reporting for every custom domain hosted on Microsoft 365.
How to read the core SNDS warning levels
Spam-rate values describe broad filtering categories. They do not measure inbox placement; confirm with SES event logs and recipient-domain outcomes.
Low spam signal
0
SNDS.SpamRate is 0 when fewer than 10% of messages receive a spam verdict in the activity window.
Mixed signal
0.5
SNDS.SpamRate is 0.5 for the middle filtering band, between 10% and 90% spam verdicts. The value does not mean 50% spam.
Severe signal
1
SNDS.SpamRate is 1 when 90% or more of messages receive a spam verdict in the activity window.
Complaint-rate example
0.001 = 0.1%
SNDS.ComplaintRate is a fraction: 0.001 equals 0.1%. Investigate increases against your baseline.
Read SNDS.SpamRate separately for each IP and activity period; averaging category codes obscures the original result. AWS defines complaint rate as a fraction and states that a reported SNDS.ComplaintRate of 0 means less than 0.1%. Keep that interpretation separate from the spam-rate categories.
Amazon CloudWatch metrics screen showing SES SNDS metrics for a dedicated IP.
What you lose without direct SNDS
The missing data matters most during Microsoft-specific incident response. CloudWatch tells you that a problem exists, but it does not always give the portal context that helps explain why it happened. That difference is a real tradeoff for senders with formal incident-review requirements.
CloudWatch SNDS
- CloudWatch keeps the data inside AWS, where you can graph it, alarm on it, and compare it with SES sending metrics.
- The defined metric set does not include every portal control or feedback-loop function.
- Use it for trend monitoring, alarms, and confirmation that Microsoft reputation changed.
Direct SNDS
- Direct access gives IP operators portal controls and JMRP feedback-loop administration.
- Access depends on authorization for the IP range, which SES customers cannot obtain for leased SES IPs.
- Use it when your organization controls the sending IP authorization path.
Microsoft has moved SNDS to a new portal, and the existing SNDS portal address redirects there. Network access now expires 10 months after approval or migration unless it is reattested. These portal changes do not give SES customers authorization for AWS-owned IPs. Verify the current report fields before making direct access a migration requirement.
Do not overread one metric
A severe SNDS value tells you Microsoft saw poor mail behavior for the IP during that window. It does not prove the cause. Check authentication, list source, complaint handling, recent content changes, bounce patterns, and recipient engagement before changing infrastructure.
Practical workaround inside SES
Inside SES, the workaround is to make CloudWatch SNDS one part of a broader evidence set. That does not replace direct SNDS access, but it makes the limitation manageable for many senders.
- Open CloudWatch in the same AWS Region as the SES dedicated IP pool, then select SES and IP Metrics. Shared-only accounts will not have a customer-level IP view.
- Track spam rate, complaint rate, and message recipients together. Include trap hits only if fresh data is available for that metric.
- Alert when the daily spam rate reaches 1 or complaint rate rises above your normal baseline. Check data freshness separately so gaps do not look like recovery.
- Enable SES event publishing for delivery delays, bounces, and complaints, then compare those events with the SNDS activity period and campaign or application release logs. Retain the SES message ID for correlation.
- For managed pools, compare the dedicated sending percentage before treating per-IP SNDS data as a complete view of the stream.
- Use separate dedicated IP pools for transactional and bulk streams when you need IP reputation separation. Configuration sets alone do not provide separate sending IPs.
Daily SNDS alarm and freshness checkstext
Scope: One dedicated IP Alarm period: 86400 seconds Statistic: Maximum Treat missing data: missing If SNDS.SpamRate = 1 for one daily period: pause high-risk campaigns inspect Microsoft-domain delivery delays and bounces check recent list sources and complaints If expected daily SNDS points stop arriving: check Region, IP allocation and Microsoft-bound volume inspect SES events for current delivery outcomes do not infer recovery from missing values
For a message-level configuration check, send a controlled message through the same SES configuration set and inspect it with Suped's email tester. It checks authentication, the sending IP, and reverse DNS for delivery to Suped. It does not show Outlook.com inbox placement or Microsoft's private SNDS data, and managed pools can use different IPs for different receiving providers.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
How to escalate an Outlook.com delivery incident
AWS SNDS troubleshooting states that AWS cannot influence SNDS and directs mitigation requests to Outlook. Use the sender-support route on the SNDS portal when Microsoft consumer-domain delivery problems persist; direct authorization for SES IPs is a separate issue.
- Record the SES Region, pool type, and outbound sending IP shown in rejection diagnostics or received headers.
- Keep complete SMTP diagnostic responses, affected recipient domains, and timestamps with time zones.
- Include recent daily SNDS values and message volumes, plus the authentication and list-quality changes already made.
- Ask AWS Support to investigate missing SES metrics or unexpected pool routing; use Outlook.com sender support for Microsoft mitigation requests.
A CloudWatch alarm identifies a signal to investigate. It does not submit a Microsoft support request or remove a delivery restriction.
When CloudWatch SNDS is enough
CloudWatch SNDS is enough when the job is ongoing reputation monitoring, early warning, or deciding whether an Outlook.com issue is isolated to one dedicated IP. SES remains a practical fit when the sending program has clean permission practices, stable domain authentication, low complaint rates, and enough logging outside SNDS.
A strong SES setup has dedicated IP pool separation, configuration sets for every meaningful mail stream, event publishing for bounces and complaints, and a clear response plan when Microsoft metrics degrade. It also has DMARC reporting outside SES, because CloudWatch SNDS describes Microsoft-side IP behavior rather than domain authentication across receivers.
When to move the mail stream
If direct SNDS and JMRP control are operational requirements, the workaround is not hidden inside SES. Move that mail stream to infrastructure where your organization can prove IP responsibility to Microsoft. That means an IP range you own or a sending setup where the operator supports the Microsoft authorization process for you.
Make that move only after separating the requirement from the frustration. Direct SNDS access helps, but it does not fix poor list quality, weak consent, authentication failures, or a blocklist (blacklist) problem. It gives better evidence and feedback-loop control. It does not create good reputation by itself.
Move only for the right reason
- Move when your incident process requires direct SNDS portal access, JMRP administration, or Microsoft feedback-loop reports.
- Do not move because you assume direct SNDS access will repair inbox placement without changing mail quality.
- Move one Microsoft-sensitive stream first, warm it gradually, and compare results before moving all SES traffic.
For a broader walkthrough on the same access problem at email service providers, see the page on ESP SNDS access. The core rule is the same: Microsoft wants authorization from the party responsible for the IP range.
How Suped fits into the workflow
Suped does not bypass Amazon's SES policy or grant direct Microsoft SNDS access for leased AWS IPs. That control sits between AWS and Microsoft. Suped's product fits around the gap by organizing the authentication and reputation signals you control.
Use Suped's DMARC monitoring to check whether SES traffic passes DMARC and to investigate changes in SPF or DKIM results alongside CloudWatch SNDS. For SES, SPF passing with the default amazonses.com MAIL FROM domain does not satisfy DMARC's domain match for your From address; a matching, valid DKIM signature can satisfy DMARC. Review a custom MAIL FROM domain if you also need SPF to satisfy that check.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Pair SES SNDS metrics with Suped's blocklist monitoring and domain health checker. This helps answer whether the incident is a Microsoft-only IP reputation issue, a blocklist or blacklist event, or a broader authentication problem across the domain.
Keep SES
- Keep SES when you need reliable API sending, CloudWatch metrics are enough, and Microsoft issues are occasional.
- Use SES events, CloudWatch SNDS, Suped DMARC reporting, and blocklist checks together.
Move a stream
- Move a stream when direct SNDS control is required for incident review, compliance, or Microsoft-heavy sending.
- Move the narrowest affected stream first and keep authentication reporting consistent.
Views from the trenches
Best practices
Treat SES CloudWatch SNDS as the official signal, then enrich it with campaign logs.
Separate Microsoft-heavy streams before changing IP pools, providers, or DNS records.
Keep DMARC, SPF, DKIM, and blocklist checks close to SNDS incident timelines in reviews.
Common pitfalls
Do not assume direct SNDS access is blocked because DNS verification was done badly.
Do not move all mail at once when only one stream is causing Microsoft reputation pain.
Do not read a single SNDS spike without matching it to volume, list source, and complaints.
Expert tips
For managed pools, compare SNDS with the percentage routed through dedicated IPs.
Check trap-hit data freshness before relying on alerts; missing points do not prove list quality.
Preserve SMTP diagnostic responses and message IDs to investigate Microsoft throttling incidents.
Expert view
Expert from Email Geeks says Amazon's policy blocks direct customer SNDS access for SES leased IPs, and the CloudWatch metrics are the supported data path.
2022-06-28 - Email Geeks
Marketer view
Marketer from Email Geeks says the CloudWatch data helps, but losing sample MAIL FROM, trap period context, and individual complaint detail limits investigations.
2022-06-28 - Email Geeks
