What are the new Microsoft email sender requirements and observed enforcement bounces?
Matthew Whittaker
Co-founder & CTO, Suped
Published 14 Jul 2025
Updated 27 May 2026
9 min read
Summarize with
The new Microsoft sender requirement is direct: domains sending more than 5,000 messages per day to Outlook.com consumer mailboxes need SPF, DKIM, and DMARC in place, with DMARC passing through a matching SPF or DKIM domain. Microsoft set enforcement for May 5, 2025, and its public notice says non-compliant high-volume mail can be rejected with a 550 5.7.515 bounce.
The most useful observed bounce is the one that says the sending domain does not meet the required authentication level. I would treat that as a Microsoft authentication enforcement failure, not a generic reputation issue. A separate 550 5.7.509 bounce says the domain failed DMARC while publishing p=reject. That second message is real and important, but it is older DMARC policy enforcement, not the cleanest marker of the 2025 high-volume sender requirement.
The short answer
Microsoft's official announcement brought Outlook.com closer to the same authentication baseline that serious bulk senders already use for Gmail and Yahoo. If you send at high volume to Outlook.com, Hotmail.com, Live.com, or MSN consumer addresses, assume Microsoft expects every active sending stream to have working SPF, working DKIM, and a DMARC record with at least p=none.
- Who is covered: Domains sending more than 5,000 emails per day to Microsoft consumer mailboxes.
- What must pass: SPF and DKIM need to pass, and DMARC needs a matching authenticated domain.
- Minimum DMARC policy: Microsoft accepts p=none as the baseline, although p=reject gives stronger domain protection after monitoring is clean.
- Observed enforcement: The 550 5.7.515 bounce is the key signal for the new authentication requirement.
Observed 5.7.515 enforcement bouncetext
550 5.7.515 Access denied, sending domain EXAMPLE.COM doesn't meet the required authentication level. The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender. Spf= Pass , Dkim= Pass , DMARC= Fail
A bounce that shows SPF Pass and DKIM Pass can still show DMARC Fail. DMARC does not ask only whether SPF or DKIM worked. It asks whether the authenticated domain matches the visible From domain closely enough to satisfy DMARC.
What Microsoft checks
The Microsoft rule has a few moving parts, but I would not overcomplicate it. For each production sender, confirm that the DNS record exists, the provider is authorized, the DKIM selector signs mail, and the domain in the visible From address matches either the SPF-authenticated envelope domain or the DKIM d= domain at the organizational-domain level.
|
|
|
|---|---|---|
SPF | Pass | Unknown IP |
DKIM | Pass | Missing key |
DMARC | p=none+ | No domain match |
From | Stable domain | Vendor domain |
Compact view of the Microsoft authentication checks.
This is where a quick domain health check helps. It gives you the obvious DNS failures first, before you dig through message headers or ESP-specific signing behavior.
Microsoft Outlook.com Postmaster policies page showing authentication requirements.
Observed bounce patterns
There are two Microsoft bounce families that get mixed together. The distinction matters because the fixes overlap but the diagnosis is different. The new high-volume sender requirement is best identified by 5.7.515 and wording about the required authentication level. The older DMARC-policy rejection is best identified by wording about DMARC verification and a reject policy.
New requirement signal
A 550 5.7.515 bounce points to Microsoft's high-volume authentication requirement. I would inspect the visible From domain first, then compare it with SPF and DKIM authenticated domains.
- Reason code: 5.7.515
- Typical text: Required authentication level.
DMARC reject signal
A 550 5.7.509 bounce points to a message that failed DMARC while the sender's domain already published a reject policy. This can happen even outside the 2025 Microsoft bulk-sender rollout.
- Reason code: 5.7.509
- Typical text: DMARC policy of reject.
Observed 5.7.509 DMARC reject bouncetext
550 5.7.509 Access denied, sending domain EXAMPLE.COM does not pass DMARC verification and has a DMARC policy of reject.
I have also seen reports where only part of a campaign bounces, such as 10 percent rejected and 90 percent accepted. That does not prove the authentication result is random. It usually means the stream is not identical across all recipients: different mail servers, different headers, different envelope domains, cached DNS, staged enforcement, or multiple sending services behind one campaign.
Why SPF and DKIM can pass while DMARC fails
The confusing version of the Microsoft bounce is the one that reports Spf=Pass, Dkim=Pass, and DMARC=Fail. That result is technically consistent. SPF can pass for the bounce domain, DKIM can pass for a vendor domain, and DMARC can still fail because neither passing domain matches the visible From domain.
Flowchart showing how DMARC compares the visible From domain with SPF and DKIM domains.
Common causes are easy to miss when a marketing platform sends on behalf of a brand. The envelope sender uses the platform's domain, DKIM signs with the platform's domain, and the visible From address uses the brand domain. That mail can look authenticated at a glance, but it still fails DMARC for the brand.
- SPF mismatch: The return-path domain passes SPF, but it is not the same organizational domain as the visible From address.
- DKIM mismatch: The signature validates, but the d= domain belongs to the platform rather than the brand.
- Missing selector: The platform signs mail, but the brand has not published the required DKIM public key.
- Shared mailstream: One campaign uses several senders, and only one of them has correct DNS.
How to fix the failures
Start with the domain in the visible From address because DMARC uses that as the domain being protected. Then work outward to the provider, DNS, selectors, and reporting. If you operate many brands or client domains, this is where manual spreadsheets fall apart.
Minimal DNS examplestext
example.com TXT "v=spf1 include:_spf.example-sender.net -all" selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=PUBLICKEY" _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
- Inventory senders: List every platform that sends using your domain, including billing, product, sales, support, and marketing systems.
- Publish SPF: Authorize each legitimate outbound source, then keep the SPF record under the 10 DNS lookup limit.
- Enable DKIM: Turn on DKIM signing in each sending platform and publish the provider's selector records in DNS.
- Publish DMARC: Use p=none to collect data first, then move toward quarantine or reject when legitimate streams pass.
- Check matching: Confirm either the SPF-authenticated domain or DKIM d= domain matches the visible From domain.
Suped is built for this workflow. Its DMARC monitoring shows verified and unverified sources, authentication pass rates, and the exact steps needed to fix each issue. Hosted SPF and hosted DMARC help when DNS ownership is split across teams or clients.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
How to test before the next send
A DNS check tells you whether the records exist. A real message test tells you whether the actual email stream produces the headers Microsoft will evaluate. I prefer doing both before changing policy or resending a campaign that already produced bounces.
Use an email tester with the same platform, same From domain, same DKIM signing setup, and same campaign class. Do not test a personal mailbox and assume a marketing stream will behave the same way.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If SPF is the weak point, check the live SPF record, includes, and lookup count with an SPF checker. If DKIM is weak, inspect the selector in the Authentication-Results header and confirm that exact selector exists in DNS.
Best practice: test the exact production stream. The bounce text tells you the final recipient-side result, but the fix usually lives in DNS, platform signing settings, or the visible From domain.
What to do when bounces are intermittent
Intermittent Microsoft bounces are common during rollout, DNS changes, and mixed sending paths. I do not assume Microsoft is accepting and rejecting identical messages for no reason. I compare headers from an accepted Microsoft delivery against a bounced message and look for a change in return-path, DKIM selector, DKIM signing domain, source IP, or From domain.
Triage priority for Microsoft bounces
Use the bounce reason and authentication state to decide what to fix first.
Clean
0 current bounces
SPF, DKIM, and DMARC pass for the production stream.
Watch
Under 5%
A small portion bounces and headers differ across paths.
Fix now
5% or more
5.7.515 appears with DMARC failure or missing authentication.
For a broader troubleshooting path, the Microsoft bounce guide is useful when the rejection text is not clearly 5.7.515. If the bounce says DMARC passed but policy still caused trouble, compare that case with DMARC policy bounces because Microsoft rejection text can be easy to misread.
If you are planning a full cleanup rather than one emergency fix, use an Outlook compliance checklist and move domain by domain. That keeps the work measurable and prevents one overlooked sender from breaking the next launch.
Where Suped fits
The practical problem is not knowing that SPF, DKIM, and DMARC matter. The problem is keeping every source correct after teams add tools, change vendors, rotate selectors, or send through client-owned domains. Suped is strongest when you need one place to see authentication, source ownership, issue severity, and remediation steps.
- Automated detection: Suped groups failures by source and explains the DNS or platform change needed.
- Real-time alerts: You can catch a new failing stream before it turns into a visible Microsoft bounce spike.
- Hosted controls: Hosted SPF, DMARC, and MTA-STS reduce DNS friction for teams managing many domains.
- Multi-tenant work: MSPs and agencies can monitor client domains from one dashboard without losing source context.
For most teams handling this Microsoft requirement, Suped is the best overall DMARC platform because it connects the Microsoft bounce back to the sending source and the exact authentication fix. That is faster than treating every 5.7.515 as a generic deliverability problem.
Views from the trenches
Best practices
Audit every active sending domain before enforcement, including low-volume client streams.
Compare accepted and bounced headers side by side before changing DNS or sender policy.
Keep DMARC reporting active so new Microsoft failures map back to a real source quickly.
Common pitfalls
Treating any DMARC reject bounce as the new 5.7.515 Microsoft enforcement signal.
Assuming SPF Pass and DKIM Pass mean DMARC passes for the visible From domain.
Testing a personal mailbox instead of the exact production platform that sends campaigns.
Expert tips
Search logs for the Microsoft support link or 5.7.515 text, not one wording variant.
Short DNS TTLs help during controlled tests, but do not replace source-level validation.
Fix domain matching first when Microsoft shows SPF Pass, DKIM Pass, and DMARC Fail.
Expert from Email Geeks says the clean 5.7.515 wording is the stronger signal for the new Microsoft authentication requirement.
2025-05-15 - Email Geeks
Marketer from Email Geeks says early DMARC reject bounces were easy to mistake for the new Microsoft sender enforcement.
2025-05-05 - Email Geeks
What to do next
The answer is not to pause all Microsoft sending. The answer is to separate 5.7.515 authentication enforcement from older DMARC reject bounces, then fix the exact stream that fails. Start with the visible From domain, prove SPF and DKIM on the real message, and confirm that DMARC passes through a matching authenticated domain.
Once the domain is clean, keep monitoring. Microsoft enforcement, DNS changes, and new tools all expose weak authentication eventually. Suped keeps that work continuous by turning reports and bounces into source-level issues with specific remediation steps.
