5.7.509 means the visible From domain publishes a DMARC policy of reject, the message failed DMARC, and Microsoft honoured the policy. The domain owner asked receivers to reject unaligned mail; the message was unaligned; the outcome is the policy working as published.
Most common causes
- SPF failed or passed on an identity that was not aligned with the visible From domain
- DKIM failed or signed with a domain that was not aligned
- Forwarding or message modification broke the only aligned authentication path
- The domain moved to p=reject before every legitimate sender was correctly authenticated
What to verify next
- Run DMARC Alignment Lab with the real From, envelope and DKIM identities
- Inspect Authentication-Results from the failed message
- Inventory third-party senders that use the affected From domain
- Correct authentication and alignment rather than weakening policy without evidence
DMARC failed because nothing aligned
DMARC passes if either SPF or DKIM passes with an identity aligned to the From domain. A 5.7.509 means neither did: SPF may have passed for a platform bounce domain, DKIM may have passed for a platform signing domain, but the From domain had no aligned path — or both mechanisms simply failed.
Read Authentication-Results from a delivered copy of the same message. It shows spf, dkim and dmarc results with the identities evaluated, which makes the missing alignment path obvious.
The usual ways this happens
A platform sending as the domain without a custom bounce domain or custom DKIM signing. Forwarding that broke both paths. A DNS change that removed the DKIM selector the platform still signs with. Or an attacker spoofing the domain, in which case the rejection is exactly the intended outcome.
The policy was probably moved to reject before every legitimate sender had an aligned path. Aggregate reports for the domain will show which sources are failing.
- Find the platform or path that lacks alignment.
- Aggregate reports reveal every failing source.
- Legitimate rejection of spoofing looks identical from the outside.
Fix alignment rather than weakening policy
Configure the platform for a custom bounce domain and custom DKIM signing under the From domain, verify with a real message, and confirm dmarc=pass. Dropping the policy back to none removes the protection for everyone to accommodate one misconfigured sender.
If the sending source is not yours, the rejection is correct and should stay. Use DMARC Alignment Lab to test a specific path before and after the change.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisDMARC Alignment Lab
Compare visible From, envelope sender and DKIM identities without reducing the result to a pass/fail label.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- The failing message’s exact identities are only visible in its headers; a DNS check alone cannot reproduce them.
- Receivers may apply local overrides to DMARC; Microsoft reports this code when it did enforce.
Common questions
SPF and DKIM both pass. Why DMARC fail?
They passed for platform-owned identities that do not align with the From domain. Alignment is the missing piece.
Should I change p=reject to p=none?
Only as a temporary emergency measure. The right fix is an aligned path for the affected sender.
Why does only Microsoft reject?
Some receivers quarantine instead of rejecting, or apply local policy overrides. Microsoft honoured the published policy.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.