550 5.7.509: Sending domain fails DMARC with a reject policy

550 5.7.509 is a Microsoft code. It means your From domain failed DMARC and your own DMARC policy says to reject such mail. The message was refused because of the policy you published.

Bounce type
Hard bounce (permanent)
Usually caused on
Your sending side
Terlido report label
Blocked by the provider

What the standard says

RFC 5321 defines 550 as "mailbox unavailable", which includes refusals for policy reasons. Subject 7 in RFC 3463 covers security or policy. The detail number 509 is not defined in an RFC. It is Microsoft's own detail code, so the meaning comes from the Microsoft text.

What the mailbox providers say

  • Microsoft 365 / Outlook (5.7.509): “Access denied, sending domain [$SenderDomain] does not pass DMARC verification and has a DMARC policy of reject.” Source

Common causes

  • Neither SPF nor DKIM passes in a way that aligns with the From domain.
  • A third-party service sends as your domain without being set up in your DNS.
  • DKIM signs with the service's own domain instead of yours, so alignment fails.
  • The DMARC policy was set to reject before all legitimate senders were authorized.
  • A subdomain that sends mail but has no DKIM keys, while the parent domain has a strict DMARC policy.
  • A new tool added to the workflow that sends with your From address before its authentication was set up.

How to fix it

  • Read the DMARC reports for your domain to find which senders fail alignment.
  • Set up DKIM with your own domain for every service that sends as you.
  • Add the sending services to your SPF record where they use your envelope domain.
  • While you fix this, you can move the DMARC policy to a softer setting, then tighten it again once all senders pass.
  • Check the policy for subdomains in your DMARC record and align it with how you actually send.
  • Test a message from every tool after changes, and read the authentication results in the received headers.
  • Keep a list of every service that sends as your domain, and add each one to the list before it goes live.

Is it a deliverability problem?

Yes. A DMARC failure with a reject policy means your own configuration blocks your own mail. Fixing alignment is a sender-side job, and it gives you the benefit of a strict policy without losing real mail. A reject policy is good practice once all senders are aligned. Until then, the policy blocks your own legitimate mail at receivers that obey it, so this code is a sign to finish the alignment work.

How Terlido handles it

When a bounce message for this code arrives in a connected mailbox, Terlido reads the status code. An enhanced code that starts with 5 is a hard bounce. In the campaign Reports tab this one is grouped as "Blocked by the provider".

On a hard bounce Terlido adds the address to the workspace blocklist with the reason "hard bounce", so no campaign emails it again. The lead stops in that campaign as bounced, its lead score goes down by 15, and the bounce counts toward the campaign's bounce rate.

Once a campaign has at least 20 sends, it pauses itself when hard bounces divided by sends goes over the campaign's maximum bounce rate. The default is 5%. If the cause was on your side and you fixed it, you can remove the entry on the Blocklist page of your account settings and try again.

Terlido treats every 5.x.x code as a hard bounce, so it blocklists the recipient even when the real cause is your own sending setup. After you fix the sending side, remove the entry from the blocklist if you want to contact that person again.

Check the domain behind the bounce

The free domain checker runs live SPF, DKIM, DMARC, MX and blocklist lookups and explains each result in plain English.

Free tools that help

Related error codes

Sources

Connect a mailbox.
Your domain's score lands today.

It costs nothing and doesn't depend on anyone else being on the platform. Warmup runs free on every plan, forever.

Start free
14 days at Multichannel limits, then the Free plan. No card, at any point.