Does Microsoft require a reject policy?

No. Microsoft's high-volume sender minimum permits p=none. Choose a stronger policy through a separate, tested rollout; changing the policy does not make a failing message authenticate.

Can a passing DNS check prove every sender is compliant?

No. A passing DNS check describes published configuration. Validate a real message from each sending service to establish its authentication results and alignment.

Can different sending services share one validation result?

No. Services using the same visible From domain can have different envelope senders, signing domains and keys. Keep a separate test result for each production path.

Where should I investigate an existing Outlook rejection?

Start with the complete rejection response. The 550 5.7.515 repair guide covers that authentication failure and the evidence to collect before proposing changes.

Microsoft DMARC requirements: SPF, DKIM and sender scope

Microsoft's DMARC requirements for high-volume Outlook senders require SPF and DKIM to pass, a published DMARC policy of at least p=none, and DMARC alignment through SPF or DKIM. These requirements cover Microsoft's consumer email services; published DNS records alone do not show that your sending systems meet them. Microsoft's current requirements and rejection guidance describes the checks applied to messages.

At a glance

Quick takeaways

Test every production sending service, including billing, marketing and support systems.
Separate public DNS configuration from actual message authentication results.
Keep evidence of the sending domain, test path, receiver result and check date.
Route an existing rejection to the 550 5.7.515 repair guide, which includes an evidence-based Palisade MCP workflow.

Who is affected?

Microsoft's consumer services include Outlook.com, Hotmail, Live.com and MSN. The current Microsoft Support definition counts 5,000 or more messages using the same visible From domain. Its definition does not specify a time window. The rollout announcement uses more than 5,000 emails per day.

For planning, treat 5,000 daily consumer-bound messages from one From domain as the point to have the full checklist in place. This is a conservative operational interpretation of the two wordings, not a claim that Microsoft publishes an exact counting algorithm. Do not assume each sending application gets a separate allowance when it uses the same From domain.

These consumer-service rules do not establish the filtering policy of every Microsoft 365 business tenant. A rejection from a business recipient needs its own complete response and recipient-policy context.

What are the requirements?

Microsoft Support requires all of the following:

SPF passes for the message's envelope-sender domain.
DKIM passes for the signed message.
DMARC is published, with p=none sufficient as the minimum policy.
DMARC passes through at least one aligned SPF or DKIM result.

DMARC alignment relates an authenticated domain to the visible From domain. Under relaxed alignment, the organizational domains can match; strict alignment requires an exact match. Microsoft's DMARC configuration guidance explains that distinction. See the DMARC learning hub for the underlying protocol and policy choices.

A stricter DMARC policy is a separate rollout decision. It does not repair failing SPF, DKIM or alignment. Before requesting quarantine or rejection, identify legitimate senders and validate their authentication, following Microsoft's staged deployment guidance above.

When does the requirement take effect?

Microsoft's April 29 update to its announcement replaced the initial junk-first plan with rejection beginning May 5, 2025. Do not plan around a future grace period.

The documented rejection is:

Technical exampletext

550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level.

That current error is documented in Microsoft's NDR guidance. Preserve your complete bounce response, including any additional details, when investigating.

How do I implement the requirement?

1. Inventory the actual sending paths

Make one checklist entry per service that sends with your visible From domain. Record the service owner and the message type so that a successful test from your main mailbox does not stand in for the billing platform or newsletter provider.

2. Check the published configuration

Use the Microsoft compliance checker to screen public authentication records. Keep the result with the relevant service's setup instructions. A DNS lookup can identify published configuration; it cannot prove which envelope sender or signing key a production message uses.

3. Validate messages before changing policy

Send an authorized test from each real sending path to a mailbox you control. Inspect the receiving system's authentication results and compare them with the intended sender configuration. Escalate a failing service to its owner with the evidence, rather than applying the same DNS change across every service.

How do I validate compliance?

To validate Microsoft compliance, inspect the receiving system's trusted Authentication-Results, not a header supplied by an arbitrary sender. RFC 8601 defines the result fields and their trust boundary. Save enough evidence to distinguish a record that exists from an authenticated, aligned message.

Use this as an illustrative checklist, not as a sample passing result:

Technical exampletext

Sending service:
Visible From domain:
Envelope-sender domain:
DKIM signing domain and selector:
Trusted receiver SPF result:
Trusted receiver DKIM result:
Trusted receiver DMARC result:
Check date and next action:

Repeat the test after correcting the identified sending path. Keep the current result alongside the previous failure so the service owner can verify what changed. Authentication is necessary evidence for this checklist; it is not a promise of inbox placement.

Change log and next review

October 2, 2026: corrected the rejection code, removed the obsolete junk-first grace period, clarified threshold wording, and separated DNS checks from message evidence. Removed BIMI from the implementation sequence because it is not part of this authentication checklist.

Owner: Samuel Chenard, Palisade editorial. Next review: November 2, 2026, or sooner if Microsoft changes either cited requirement page.

Evidence