Outlook / Exchange Online DMARC rejection

Fix Outlook 550 5.7.509 DMARC failure

Microsoft returns 5.7.509 when the RFC 5322 From domain fails DMARC and publishes a policy of p=reject. The safe correction is usually to fix the legitimate sender's authentication alignment—not to disable protection.

Problem description

The NDR includes a response similar to:

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

Check the current DMARC policy

What MailFixIt can test: the current applicable DMARC policy and public SPF/DKIM configuration, plus receiver-reported results from supplied headers. The current checker does not independently calculate or cryptographically verify message-level alignment.

Is this temporary or permanent?

550 is permanent for this message. Retrying it unchanged will normally be rejected again. Correct the affected sender path and generate a new message.

What Microsoft 5.7.509 means

The visible From domain requested rejection of mail that fails DMARC. DMARC passes when at least one successful authentication path aligns with that visible domain: SPF through the MAIL FROM identity or DKIM through the signing d= domain. A valid policy record does not make an unaligned message pass.

Probable causes

A legitimate third-party sender uses its own Return-Path domain, so SPF can pass without aligning.
The service signs with a provider domain rather than an aligned customer DKIM domain.
SPF or DKIM failed outright because authorization, signing or public key DNS is wrong.
A subdomain inherits a stricter policy than the operator expected.
Forwarding changed the SPF path and no aligned DKIM signature survived.
An unauthorized sender is correctly being blocked by the domain's policy.

How to diagnose DMARC rejection

Confirm the RFC 5322 From domain shown to the recipient.
Inspect Authentication-Results, Return-Path and DKIM-Signature in a representative rejected or delivered message.
Discover the effective DMARC policy for the visible From domain, including inherited subdomain behavior.
For SPF, compare the passing MAIL FROM domain with the visible From domain.
For DKIM, compare each passing signing domain with the visible From domain.
Determine whether the message was direct or forwarded before assigning a root cause.

How to fix Outlook 5.7.509

For an authorized sender, configure a custom aligned Return-Path or branded DKIM signing domain supported by that service. Repair any missing SPF authorization or invalid DKIM key without removing other legitimate senders. Keep p=reject when it is safely protecting the domain; change policy only as a controlled, evidence-backed rollout decision.

If the message is unauthorized, the rejection is expected behavior. Do not authorize an unknown IP merely because it appears in a bounce.

Frequently asked questions

What does Outlook 550 5.7.509 mean?

Microsoft rejected a message because the RFC 5322 From domain did not pass DMARC and its DMARC policy requested rejection.

Should I change p=reject to p=none?

Not as the first response. Identify which legitimate sender failed aligned SPF or DKIM and correct that path; weakening policy can reduce impersonation protection.

Can DNS alone prove DMARC alignment?

No. DNS shows the applicable policy and authentication material, while alignment depends on the identities and pass results of the actual message.

Related email diagnostics

Primary sources: Microsoft Exchange Online NDR reference and RFC 9989 DMARC.