“Outlook” can mean a desktop application, a consumer mailbox or an organization's Microsoft 365 environment. Those are not interchangeable policy scopes. Start with the actual receiving service and diagnostic before using a high-volume checklist to explain a failed message.
Identify the consumer service and its current requirement
Microsoft's current support article for 550 5.7.515 describes Outlook.com and related consumer services, including Hotmail, Live.com and MSN. It identifies a high-volume sender as sending 5,000 or more messages to those services using the same domain in the visible 5322.From address. Its support wording states that both SPF and DKIM must pass, and that a published DMARC policy of at least p=none and DMARC pass are required. Microsoft 550 5.7.515 guidance.
The updated announcement set rejection enforcement to begin on May 5, 2025. Its initial Junk-only plan is struck out; do not treat that superseded paragraph as the current response policy. Microsoft updated announcement.
The earlier announcement described daily volume and used “more than 5,000.” Do not build an exemption around the boundary wording: the current support guidance uses 5,000 or more. Nor should you invent a reset period or permanent classification rule from this support page. Record the version and actual receiving diagnostic when interpreting a case.
Separate protocol success from the provider gate
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
DMARC can pass through an aligned successful DKIM signature even when SPF fails. That protocol outcome does not satisfy a separate requirement that both underlying mechanisms pass. Conversely, SPF and DKIM may both pass for domains unrelated to the visible From and leave DMARC failing. Keep all three results and the identities behind them.
For a direct service-generated message, record the sending IP, envelope sender domain, From domain, DKIM d= domain and selector. Verify the current DNS and the final signed message, not just a setup screen. Use the actual protocol names: SMTP MAIL FROM is the RFC 5321 envelope identity, while the visible From belongs to RFC 5322.
Read the rejection as evidence, not a repair script
References: RFC 8601 §5.
A 550 5.7.515 rejection indicates the sender's domain did not meet the required authentication level. Preserve the entire diagnostic, time, affected recipient and message identifiers. Do not respond by adding every available provider include to SPF or disabling DMARC enforcement without understanding the failing identity.
Compare affected and unaffected streams. A billing service may have the correct custom signing setup while a campaign service still signs only with its own domain. If forwarding or another intermediary is involved, preserve the route and transformations. Direct-mail assumptions may not explain an indirect path, and a copied Authentication-Results line is not a substitute for trusted receiver evidence.
Work through a synthetic diagnostic
References: RFC 9989 §5.3.5.
Imagine a controlled message whose SPF result is fail, whose DKIM result is pass with alignment, and whose DMARC result is pass. The DMARC result is internally coherent. Under Microsoft's stated high-volume requirement, the SPF failure still needs repair. This is a logical example, not a captured Microsoft rejection.
The next action is to determine whether the evaluated envelope sender authorized the actual connecting IP. After an approved correction, retest through the same intended route and preserve the new outcome. Do not reuse the old pass as evidence for a changed message or route.
Keep enterprise cases on their own evidence path
A Microsoft 365 tenant can apply its own inbound policies and connectors. A recipient using the Outlook application does not make their organization subject to the consumer article's exact gate. For enterprise cases, collect the tenant's diagnostic and policy context instead of assuming that 5.7.515 explains every 5.7.x response.
Close with the affected service, sender domain, observed mechanism results and corrected route. No live Microsoft mailbox test is claimed here, and authentication compliance remains distinct from inbox placement.