Why Microsoft Is the Deliverability Problem SES Senders Underestimated
When Google and Yahoo tightened their bulk sender requirements in February 2024, the email industry scrambled. Documentation, blog posts and compliance checklists appeared everywhere. Amazon SES senders updated their DNS records, enabled Easy DKIM and moved on. Many assumed they were done.
They were not. Microsoft followed with its own enforcement starting 5 May 2025, and the consequences for non-compliant senders were swift. The initial wave routed failing mail to recipients' Junk folders; Microsoft has since escalated toward outright SMTP rejection for non-compliant bulk senders, meaning that a rejected message never reaches the inbox, the junk folder or anywhere else. It simply disappears, often without clear visibility inside SES event logs unless you know exactly what to look for.
This article covers what Microsoft now requires, why the SES shared IP model creates a specific and underappreciated risk, how to read the rejection codes that appear in your SES bounce data, and what a fully compliant SES configuration looks like in 2025 and beyond.
From Gmail and Yahoo to Microsoft: The Enforcement Timeline
Gmail and Yahoo enforced their bulk sender requirements from February 2024, requiring SPF, DKIM and DMARC for anyone sending 5,000 or more messages per day to their consumer mailboxes. Senders who missed the deadline mostly saw mail routed to spam, which gave them a window to diagnose and fix the problem. Google gave senders roughly 21 months of notice before enforcement began.
Microsoft's approach was far more compressed. The announcement arrived on 2 April 2025, giving senders just 33 days of notice before enforcement began on 5 May 2025. That tight timeline caught many legitimate senders off guard. Business mail that had been delivered reliably for years suddenly started appearing in Outlook Junk folders or being rejected outright.
By late 2025, enforcement had tightened further, and Microsoft has continued escalating its filtering standards into 2026. If your deliverability to Outlook, Hotmail or Live.com addresses has degraded over the past year, Microsoft's enforcement is almost certainly a contributing factor.
Microsoft's Requirements for Bulk Senders
The rules apply to anyone sending 5,000 or more messages per day to Microsoft consumer mailboxes: Outlook.com, Hotmail.com, Live.com and MSN.com. Mail to Microsoft 365 business tenants is governed separately, though following these requirements improves deliverability there too. The threshold is counted across your sending domain and its subdomains, so splitting sends across multiple subdomains will not bring you under the limit if the parent domain is collectively pushing 5,000 messages per day.
The core technical requirements are as follows.
SPF
Your sending domain's DNS must include an SPF record that passes for the server delivering the message. The record must accurately list the authorised IP addresses and sending hosts. Staying within the ten DNS lookup limit is a practical necessity: SPF records that exceed this limit fail evaluation, which breaks DMARC alignment through the SPF path.
DKIM
Every message must carry a valid DKIM signature. The signing key must resolve against a published DNS record, and the domain in the DKIM signature must align with the domain in the visible From address to satisfy DMARC through the DKIM path.
DMARC
A DMARC record with at minimum a policy of p=none is required, and the message must achieve alignment through either SPF or DKIM. A DMARC record alone is not sufficient: alignment must pass. Microsoft also applies increasing scepticism to senders who remain at p=none for extended periods, actively down-weighting reputation for domains that linger in monitor-only mode rather than progressing toward p=quarantine or p=reject.
Unsubscribe and Complaint Rate
Microsoft strongly recommends RFC 8058 one-click unsubscribe for bulk mail, and enforcement of this recommendation is expected to follow. Beyond authentication, Microsoft monitors complaint rate. A complaint rate approaching 0.3% triggers active enforcement action, and anything higher damages sending reputation quickly. The practical target is to keep complaint rates well below 0.3%, treating 0.1% as the threshold at which investigation and action are warranted.
Microsoft also requires valid PTR records, TLS encryption on the SMTP connection and RFC 5322-compliant message formatting. Any of these failing can trigger rejection independently of authentication status.
The Shared IP Problem: Why This Bites SES Senders
When you create a new Amazon SES account, your emails are sent from IP addresses shared with other SES users by default. AWS actively manages these shared pools, and for many use cases the arrangement works well. But Microsoft's filtering introduces a specific risk that is less visible on Gmail or Yahoo.
Microsoft places considerable weight on IP reputation through its SmartScreen filtering. Even if your domain authentication is perfect, your deliverability at Outlook can be degraded by the behaviour of other senders sharing the same IP addresses. Another SES customer on the same shared pool who sends to stale lists, generates high complaint rates or hits spam traps at Microsoft can pull down the SmartScreen score for IPs that you also use.
Microsoft's Smart Network Data Services tool (SNDS) shows IP-level behaviour across all senders sharing that address, not just yours. This is a structural limitation of shared infrastructure that no amount of domain-level authentication can fully compensate for. Microsoft is slower to recover reputation than Gmail, so a period of elevated complaints on a shared IP can affect your delivery for weeks after the offending sender has stopped sending.
This is not a theoretical concern. SES senders who pass every authentication check and maintain clean lists sometimes find their Outlook deliverability degrading for no apparent reason. The cause is frequently IP-level reputation bleed from the shared pool.
SMTP Error Codes Decoded
When Microsoft rejects a message, the rejection code appears in the SES bounce event for that message. Understanding what each code means is essential for triaging deliverability problems quickly.
550 5.7.515
This is the primary enforcement code introduced with the May 2025 bulk sender requirements. The full response from Microsoft reads: "Access denied, sending domain does not meet the required authentication level." The domain in the visible From address (the RFC 5322 From header) did not satisfy Microsoft's authentication requirements for high-volume senders. The leading 550 indicates a permanent SMTP rejection. Retrying will not help; the message has been refused and will not reach the recipient. The fix lies in the authentication stack: a missing or misaligned DMARC record, a broken DKIM signature, or an SPF record that does not align with the From domain through a custom MAIL FROM configuration.
550 5.7.509
This code indicates the sending domain has a DMARC policy of p=reject but the message failed DMARC evaluation. It differs from 5.7.515 in that the domain has an existing DMARC record at the reject level, yet SPF or DKIM alignment has broken somewhere in the sending chain. The result is the same: permanent rejection at the SMTP layer.
Other Related Codes
A 550 5.7.1 indicates the sending system was not authenticated at the connection level, a less common error for SES senders but one that appears when SMTP credentials or connection configuration is incorrect. Beyond the individual message impact, a consistent stream of 5.7.515 rejections will rapidly inflate your overall SES bounce rate. That in turn risks triggering SES's own account-level sending limits, compounding the problem well beyond Outlook deliverability alone.
In SES, these rejections appear as hard bounces in your event stream. If you have SES event publishing configured to SNS, SQS, Kinesis Data Firehose or CloudWatch, you will see these bounce subtypes in the notification payload. If you are not publishing SES events, you are effectively blind to these rejections until a customer complains.
SES Compliance Checklist for Microsoft
The following steps address Microsoft's requirements in the context of how SES actually works, including the alignment traps that are specific to SES's architecture.
Step 1: Configure a Custom MAIL FROM Domain
By default, SES uses amazonses.com as the MAIL FROM domain. SPF passes for amazonses.com, but because that domain differs from your visible From domain, SPF does not satisfy DMARC alignment. DMARC can still pass through the DKIM path, but relying solely on DKIM for alignment is fragile. Configuring a custom MAIL FROM domain, typically a subdomain such as mail.yourdomain.com, makes SPF alignment function correctly because the envelope sender now shares the same organisational domain as your From address. SES provides the MX and TXT records you need to publish for the subdomain when you configure this in the console.
Step 2: Enable and Verify DKIM on Your Domain Identity
Verify a domain identity in SES rather than an individual email address. When you verify a domain, SES offers Easy DKIM, which automatically generates and manages DKIM keys via three CNAME records with automatic key rotation. The d= value in the DKIM signature must match your From domain for DMARC alignment. If you send from multiple AWS regions, verify the domain identity separately in each region and confirm DKIM signing is active in all of them.
Step 3: Publish a DMARC Record
Add a DMARC TXT record at _dmarc.yourdomain.com. The minimum required by Microsoft is p=none with an rua reporting address. In practice, p=none is a starting point, not a destination. Monitor your DMARC aggregate reports to confirm SPF and DKIM alignment are passing consistently, then progress toward p=quarantine and ultimately p=reject. Remaining at p=none indefinitely signals to Microsoft that your domain is not fully committed to authentication, which influences SmartScreen scoring independently of whether individual messages pass.
Step 4: Add List-Unsubscribe Headers
Include both a List-Unsubscribe header with a mailto: address and a List-Unsubscribe-Post header with the value "List-Unsubscribe=One-Click" in compliance with RFC 8058. This satisfies Microsoft's strong recommendation for one-click unsubscribe and also meets Gmail and Yahoo's enforcement requirements. SES does not add these headers automatically; your application or sending code must include them on every bulk or marketing message.
Step 5: Maintain List Hygiene and Complaint Rate
Suppress hard bounces immediately and permanently. Remove recipients who complain via the SES complaint notification before your next send. Keep your Microsoft complaint rate well below 0.3%. Regularly remove inactive or unengaged subscribers from your active lists rather than continuing to send to addresses that have not opened or clicked in many months.
Monitoring Outlook Bounce and Complaint Signals
Authentication is a gate you must pass through; reputation determines what happens once you are through it. Passing Microsoft's authentication checks does not guarantee inbox placement if your complaint rate, spam trap hits or SmartScreen score are degraded.
Microsoft's primary monitoring tool for senders is SNDS, the Smart Network Data Services portal. SNDS gives IP-level data for mail sent to Microsoft consumer inboxes including Outlook.com, Hotmail and Live.com. The dashboard reports a colour-coded filter result: green represents spam verdicts on fewer than 10% of messages, yellow between 10% and 90%, and red above 90%. It also reports complaint rates and spam trap hits per IP address. The companion tool, JMRP (the Junk Mail Reporting Programme), delivers complaint feedback when eligible Microsoft users mark your mail as junk.
For SES senders using dedicated managed IPs, there is now a direct integration worth knowing about. On 21 October 2025, Amazon SES added IP observability for Dedicated IP Addresses (Managed) pools, allowing you to see the exact IP addresses in use and view SNDS reputation signals for those IPs directly through CloudWatch metrics. SES automatically creates CloudWatch metrics for SNDS information on each IP address, accessible through the CloudWatch console or APIs. This makes it considerably easier to correlate changes in your sending behaviour with changes in your Microsoft reputation without leaving the AWS console.
The signals you should monitor routinely are SES bounce rates broken down by bounce type, with hard bounces to Microsoft domains treated as an immediate alert. Complaint notifications through SES's feedback loop integration should trigger list suppression automatically, not manually. If you have access to SNDS data for your sending IPs, check filter results and complaint rates at least weekly. A yellow or red SmartScreen status warrants reducing volume to Microsoft domains, sending only to your most engaged recipients, and investigating the root cause before resuming normal volume.
Do not wait for SES's account-level sending pause to act. SES monitors your account's overall bounce and complaint rates and will pause sending across all destinations if they breach its thresholds. A sustained problem at Microsoft can therefore affect your ability to send transactional mail to Gmail, Yahoo and every other provider, making early detection and response essential.
When to Consider a Dedicated IP
If you are sending meaningful volume to Microsoft consumer addresses and your SNDS data shows IP-level reputation problems that you cannot trace to your own sending behaviour, the shared IP pool may be the source. A dedicated IP, either the standard manually managed option or the managed option that automates provisioning and per-ISP warm-up, gives your sending traffic its own IP address and isolates your reputation from other SES customers entirely.
Dedicated IPs are not automatically better. A dedicated IP that is cold, poorly warmed or used to send to an unclean list will build a worse reputation than a well-managed shared pool. The case for a dedicated IP is strongest when your volume is high enough to warm an IP sustainably, your lists are clean, your sending patterns are predictable, and you have the operational capacity to monitor SNDS and respond to reputation signals promptly.
If you operate both transactional and marketing sending streams, separate them into distinct dedicated IP pools. A marketing campaign that generates elevated complaints should not damage the IP reputation used for password resets, order confirmations and other time-sensitive transactional mail.
Authentication Gets You Past the Gate; Monitoring Keeps You There
Microsoft's bulk sender requirements are not going to become less strict. The enforcement trajectory since May 2025 has moved consistently in one direction: stricter filters, harder rejections and a lower tolerance for senders who treat authentication as an afterthought.
For Amazon SES senders, the compliance path is well defined. A verified domain identity with Easy DKIM enabled, a custom MAIL FROM subdomain for SPF alignment, a published DMARC record progressing beyond p=none, RFC 8058 unsubscribe headers and disciplined list hygiene will get your mail past Microsoft's authentication gate. That is the necessary foundation.
What keeps you in the inbox over time is continuous visibility into what Microsoft's filters are seeing. Monitor SES bounce events broken down by destination domain and treat hard bounces to Microsoft addresses as an immediate alert. Act on complaint notifications before they accumulate. Watch SNDS filter results for your sending IPs and know when your complaint rate is trending toward 0.1% rather than waiting until it reaches 0.3%. These are the practices that separate senders who pass Microsoft's gate occasionally from those who stay reliably in the inbox.
Authentication is the ticket. Reputation is the seat. You need both.