Quick answer
An Outlook 5.7.509 bounce means access denied: the sending domain in your From address does not pass DMARC verification and that domain publishes a DMARC policy of reject. 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 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.509 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.509 enhanced status code is Microsoft's way of saying access is denied because the sending domain in the 5322.From address does not pass DMARC verification and has a DMARC policy of reject. (The older 5.7.13 or 135 code is a different thing — "sender was not authenticated for public folder", a recipient-side restriction — not the DMARC-reject code.) Microsoft's handling of a DMARC p=reject policy has tightened over time, and a failure here now produces this rejection rather than a quiet downgrade to the Junk folder.
The sender controls this code directly, as it does the 5.7.23 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.509 is in the sender-controlled group.
Why Outlook returns 5.7.509
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.509 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 a p=reject policy turns that failure into the 5.7.509 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.509
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.509.
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.