Quick answer
An Outlook 5.7.135 bounce means the sender is not authenticated: the message failed DMARC against a domain that publishes an enforcing policy. SPF or DKIM may have passed for a provider-controlled domain, but neither aligned with the visible From domain, so DMARC failed and the published quarantine or reject policy was applied. The fix is alignment: ensure that either SPF or DKIM authenticates the same organizational domain that appears in the From header, and confirm a DMARC record is published for that domain.
What the 5.7.135 code means
DMARC is a DNS policy that tells receivers what to do when neither SPF nor DKIM aligns with the visible From domain, defined in RFC 7489. The 5.7.135 enhanced status code is Microsoft's way of saying the message reached the DMARC gate and failed it against an enforcing policy. Microsoft's handling of a DMARC p=reject policy has tightened over time, and a failure here now usually produces a rejection rather than a quiet downgrade to the Junk folder.
The sender controls this code directly, as it does the 5.7.5 SPF failure. It is an authentication and DNS problem, not a reputation score and not a recipient-side policy. The Outlook pillar groups the five 5.7.x codes by who can fix them, and 5.7.135 is in the sender-controlled group.
Why Outlook returns 5.7.135
DMARC does not check authentication on its own. It checks alignment: whether a domain that already passed SPF or DKIM is the same organizational domain as the visible From address. A message can pass SPF and pass DKIM and still fail DMARC when the authenticated domain belongs to an email service platform rather than the domain in the From header. That gap is the most common cause of a 5.7.135 bounce.
SPF authenticates the envelope sender domain, also called the return-path. When you send through a platform, that return-path is often a platform-owned domain, so SPF passes for the platform but does not align with your From domain. DKIM authenticates whatever domain is named in the signature's d= tag. If the platform signs with its own domain rather than yours, DKIM passes for the platform but again does not align. DMARC requires at least one of the two paths to both pass and align with the From domain. When neither aligns, DMARC fails, and an enforcing policy turns that failure into the 5.7.135 rejection.
A second cause is a missing DMARC record combined with Microsoft applying its own enforcement for unauthenticated From domains. The fix that holds up is to publish your own DMARC record and make at least one authentication method align.
How to diagnose a 5.7.135
Identify the visible From domain in the bounced message first, because that is the domain DMARC aligns against. Resolve the DMARC record at _dmarc.<that-domain> and confirm a v=DMARC1 record exists and what its p= policy is. The Relaymetry DMARC checker reads the published record and reports the policy and alignment-relevant tags.
Then inspect a real message header. The Authentication-Results header records the DMARC verdict and shows which identity SPF and DKIM authenticated. The decisive comparison is between the d= domain in the DKIM signature, the SPF return-path domain, and the visible From domain. When the authenticated domains belong to your sending platform rather than your From domain, you have found the alignment gap that produced the 5.7.135.
What to change
Make one authentication method align with the From domain. For DKIM, configure the sending platform to sign with your domain as the d= value rather than the platform's domain, which usually means adding the platform's DKIM DNS records under your domain and enabling custom signing in the platform admin. For SPF, configure a custom return-path or bounce domain that shares the organizational domain with your From address, which lets SPF align under DMARC's relaxed alignment mode. Custom DKIM is the more durable fix because SPF alignment breaks at any forwarding hop. Once one aligned method is in place, confirm that a DMARC record is published at the organizational domain.