550 5.7.0 Local Policy Violation means the receiving server refused your message because of one of its own rules. "Local" means the rule belongs to that server or to the company running it, not to an internet standard, and the code does not say which rule it was.

That makes it one of the vaguest bounces you can get. The good news: the causes are almost always the same handful, and you can check each one in a few minutes. For other codes, see our guide to SMTP bounce codes.

What the code means

  • 550: the server will not accept the message (a permanent refusal).
  • 5.7.0: "other or undefined security status". The 7 means security or policy; the 0 means the server chose not to be more specific.

So this is a policy block, not a problem with the address. The mailbox usually exists. Removing it from your list will not stop the bounce for the next person at the same company; fixing your setup will.

The usual causes

In rough order of how often they turn out to be the problem:

  1. Authentication fails. The receiver checked SPF, DKIM or DMARC for your sending domain and the result was a fail, or nothing was published at all. Typical culprits: a tool that sends as your domain (CRM, newsletter, invoicing) but is not in your SPF record, an SPF record with more than 10 DNS lookups, two SPF records on the same domain, or no DKIM signature.
  2. Your IP or domain has a poor reputation, or is on a blocklist the receiver uses.
  3. No reverse DNS (PTR) for your sending IP, or one that does not match. Many gateways refuse mail from IPs without a proper hostname. See 550 5.7.25 and PTR records.
  4. Content or links the filter dislikes: a link shortener, a domain with a bad reputation in the message, an attachment type the company blocks.
  5. A rule only for you. The recipient (or their IT team) blocked your address or domain, or the company only accepts mail from known partners.

How to find which rule it was

  1. Read the whole bounce message, not only the code. Look for the name of the rejecting server (Remote-MTA, Reporting-MTA or the host in the error line), and for words such as SPF, DKIM, DMARC, reputation, blocklist or a link to a delisting page.
  2. Check your authentication. Enter your sending domain in the SPF and DMARC checker and the DKIM checker. Every service that sends as your domain must pass SPF or DKIM, and the domain it passes for must match your From address.
  3. See whether it is one company or everyone. If only one recipient domain rejects you, the rule is theirs: ask the recipient to have their IT team allow your domain, or to send you the reason from their gateway logs. If many domains reject you, the problem is your setup or reputation.
  4. Check your sending IP. Make sure it has a PTR record that points to a hostname, and that the hostname points back to the same IP. If you use an email service provider, they handle this; if you run your own server, your hosting provider sets it.
  5. Test with a plain message. Send a short text email with no links or attachments to the same address. If it goes through, the filter is reacting to your content.

What not to do

  • Do not keep resending. A permanent refusal will not change by retrying, and repeated attempts can make your reputation worse.
  • Do not change your From address to get around it. Sending as another domain usually makes authentication fail even harder.

How email verification relates to it

A 5.7.x refusal is about you, not the address, so verifying the address cannot fix it. What verification does help with is reputation: sending to addresses that do not exist is one of the fastest ways to look like a spammer to filters. Checking a list before you send (for example with the free email checker for a single address, or a CSV upload for a whole list) keeps your bounce rate low, which makes policy blocks less likely in the first place.

Frequently asked questions

Is 550 5.7.0 a hard or soft bounce?

It is a permanent refusal, but not a bad address. Keep the address, fix the cause, and send again once it is fixed.

Why does it happen with only one recipient?

Because the rule is "local": it belongs to that company's mail gateway. Other companies may accept the same message without any problem. The recipient's IT team is the only one who can tell you which rule it was.

Is it the same as 550 5.7.1?

They are close. 5.7.1 is "delivery not authorized", usually with a clearer reason in the text. 5.7.0 gives no detail at all. Both are policy blocks; see 550 5.7.1.

Sources