550 5.7.509: rejected because your DMARC policy says reject

What the bounce means

A 550 5.7.509 rejection reads like this:

550 5.7.509 Access denied, sending domain example.com does not
pass DMARC verification and has a DMARC policy of reject.

Two facts, both in the bounce text itself. First, the message failed DMARC: neither SPF nor DKIM produced a pass aligned with the visible From: domain. Second, that domain publishes p=reject, which asks every receiver to refuse mail that fails. Microsoft checked, the message failed, and Microsoft honored the policy. Unlike 5.7.515, this is not Microsoft's bar; it is your domain's own instruction, carried out.

The three ways mail ends up here

• A legitimate sender that is not aligned. A CRM, invoicing tool, or newsletter platform sends as your domain but authenticates with its own: its SPF envelope domain is not yours and it signs DKIM with its own d= domain. Under p=none that misconfiguration was invisible. Under p=reject it bounces.
• Forwarding. A recipient auto-forwards to an outlook.com mailbox. The forwarder's server breaks SPF alignment by design, and if it modifies the message it breaks the DKIM signature too. The forwarded copy fails DMARC even though the original was perfectly authenticated.
• An actual spoof. Someone forged your domain in the From: and Microsoft refused it. This is the policy working exactly as intended; the bounce went to the spoofer, not to you, and there is nothing to fix.

Telling these apart is the whole job. Read the rejected message's Authentication-Results header, or find the source IP in your DMARC aggregate reports: your own known sender, a forwarding host, or an IP you have never seen.

The fix is alignment, not a weaker policy

The tempting move is to drop back to p=none so the bounces stop. Do not. That reopens the exact spoofing p=reject blocks, at every receiver on the internet, to make one misconfigured sender's symptoms disappear. Fix the sender instead:

• Give the failing source aligned DKIM. Have the service sign with d=yourdomain.com (usually a pair of CNAMEs it hands you). Aligned DKIM is the durable path because it also survives most forwarding.
• Or authorize it in SPF with the service's include, if the service uses your domain in the envelope. SPF alone still breaks on forwarding, so treat it as the secondary mechanism.
• For persistent forwarding losses, aligned DKIM is the only real lever you hold. A forwarder that rewrites messages badly enough to break signatures is out of your control; the volume involved is usually tiny.

5.7.509 next to its neighbors

Microsoft has three rejections that read similarly and mean different things. 5.7.509 is your own p=reject being honored after a DMARC failure. 5.7.515 is Microsoft's own authentication requirement for high-volume senders, which can fire even at p=none. And 5.7.1 is the older, broader rejected-by-policy code that many servers use for anything from DMARC to tenant rules, so its bounce text matters more than its number. If you got 5.7.509, you already know the cause: a DMARC failure meeting a reject policy.

Frequently asked

What does 550 5.7.509 mean?

Microsoft 365 rejected the message because it failed DMARC (no aligned SPF or DKIM pass) and the From: domain publishes a DMARC policy of reject. Microsoft did exactly what the domain's own policy asked receivers to do; any DMARC-enforcing receiver would refuse the same message.

Should I change my policy to p=none to stop 5.7.509?

No. Weakening the policy reopens the exact spoofing p=reject exists to block, at every receiver, not just Microsoft. The bounce is telling you one sending path fails DMARC; fix that path's alignment and keep the policy. Retreating to p=none trades a visible, fixable bounce for invisible exposure.

Can forwarding cause 5.7.509?

Yes. A forwarder re-sends the message from its own server, which breaks SPF alignment, and some forwarders modify the message enough to break the DKIM signature too. If neither survives, the forwarded copy fails DMARC and a p=reject policy asks Microsoft to refuse it. Aligned DKIM that survives forwarding is the durable fix; the original delivery to the forwarding mailbox was unaffected.

How is 5.7.509 different from 5.7.515?

5.7.509 enforces your domain's own published DMARC policy after a failed check, so it only fires when you publish p=reject (or the message's effective policy is reject). 5.7.515 is Microsoft's own authentication bar for high-volume senders and can fire even when your policy is p=none, because it keys on Microsoft's requirement, not your policy.