5.7.1 — Message rejected by policy

What 5.7.1 means

5.7.1 signals a permanent failure related to authorization or policy. The receiver is telling you: “We will not accept this message as sent.” The important detail is often not the number itself, but the diagnostic text that comes with it.

Some providers use 5.7.1 broadly for many different policy reasons. That’s why reading the wording around the code matters more here than with, say, 5.1.1 (user unknown).

Common causes

Policy rejections are usually triggered by one (or several) of these patterns:

Authentication and identity issues

The receiver may not be able to confirm that your infrastructure is allowed to send for the domain you claim in From:. Failures or misalignment in SPF/DKIM/DMARC are frequent culprits, especially when the bounce text explicitly mentions them.

Reputation and block decisions

Even with correct authentication, providers can reject mail based on the reputation of the sending IP, sending domain, or the combination of both. This may be influenced by past complaint rates, poor list quality, sudden volume spikes, or listings on public/private blocklists.

Content and malware rules

Some 5.7.1 bounces are content-driven: suspicious links, attachment types, macros, or patterns that resemble phishing. Providers often describe this in the diagnostic line.

Rate limiting presented as a “hard” rejection

Ideally, throttling is temporary (often 4.7.x), but some systems still reject with 5.7.1 when they want the sender to back off or when repeated deferrals failed.

What it looks like in a bounce

Providers vary, but the useful lines tend to look like this:

Action: failed
Status: 5.7.1
Diagnostic-Code: smtp; 550 5.7.1 Message rejected under local policy

Action: failed
Status: 5.7.1
Diagnostic-Code: smtp; 554 5.7.1 Access denied, sending domain not permitted

Action: failed
Status: 5.7.1
Diagnostic-Code: smtp; 550 5.7.1 SPF/DKIM authentication failed

Next steps (practical)

If you are the sender

Start with the diagnostic line and then check identity, consistency, and volume. The fastest “first pass” often looks like:

• Confirm SPF/DKIM/DMARC are present and consistent with the domain in From:, and that DKIM actually signs outgoing mail.
• Check whether the bounce text mentions “blocked”, “spam”, “reputation”, “policy”, “denied”, or “not permitted”. That usually indicates a reputation/policy decision rather than a pure configuration mistake.
• If you recently changed infrastructure (new IP, new domain, new provider), reduce volume spikes and build a stable sending pattern.
• If the message contains links or attachments, try a controlled test: same recipient domain, same sender identity, but remove attachments and simplify links to see if the rejection follows the content.

If you administer the receiving system

A 5.7.1 is frequently generated intentionally by policy rules. Useful checks include:

• Look for logs that show which policy module decided the rejection (authentication, reputation, content scanning, rate control).
• Confirm whether an allowlist exists for trusted senders, and whether the rejection should be overridden or kept.
• Ensure your rejection text is specific enough to be actionable (it reduces back-and-forth).

If you are the recipient

If a sender tells you they get “5.7.1” when writing to you, the most helpful detail is the full bounce text (especially the diagnostic line). In many cases it’s a spam/policy filter decision, not something the sender can guess without those lines.

Related codes

Many providers use neighboring codes for similar situations. If you see these, the interpretation is often in the same family: 5.7.0 (general policy), 5.7.2 (sender blocked/content policy), and temporary deferrals like 4.7.1. You can look them up on the main list: /bouncecodes/.