SMTP error 500 5.7.1: authentication or policy rejection

500 5.7.1 combines 500 (RFC 5321's "syntax error, command unrecognized") with 5.7.1

(RFC 3463's security/policy "delivery not authorized" code). This pairing is inherently unusual:

the base code says the server could not parse your command, while the enhanced code says a policy

rejected you — which is a sign that a relay, firewall, or security appliance between you and the

real destination rewrote a specific rejection into a generic one, rather than the destination

server generating this combination natively.

A real transcript

MAIL FROM:<you@yourdomain.com>
250 2.1.0 Sender OK
RCPT TO:<recipient@example.com>
500 5.7.1 Command rejected due to policy restrictions

How the big three actually report this class of rejection

Few providers emit the literal 500 5.7.1 combination; most use 550 5.7.1 for the same

real-world condition, which is itself diagnostic.

Root causes

1. Failed email authentication (SPF, DKIM, DMARC) — the underlying condition a 5.7.1 almost

always represents, regardless of which base code wraps it.

1. Blacklisted sending IP or domain — a security appliance in the path rejecting generically

rather than passing through the destination's specific reply.

1. SMTP relay misconfiguration or relay denial — an intermediate relay that does not properly

forward the destination's actual reply text.

1. Policy restrictions and sending limits imposed by a corporate gateway or filtering service

sitting in front of the real mailbox server.

Diagnose it yourself

1. Trace the actual delivery path: dig MX recipientdomain.com +short, then check whether that

MX host is the final destination or a security gateway (many corporate domains route through a

filtering service like Proofpoint or Mimecast before the real mailbox server).

1. Connect directly to the MX host and watch the exact reply: `openssl s_client -starttls smtp

-connect <mx-host>:25` — if the gateway's reply text is generic ("policy restrictions") while a

direct Gmail or Microsoft rejection is normally specific, that confirms an intermediary is

involved.

1. Check SPF, DKIM, and DMARC regardless of which base code you saw: `dig TXT yourdomain.com

+short and dig TXT _dmarc.yourdomain.com +short — since 5.7.1` points here first no matter

what wraps it.

An additional diagnostic command

Bypassing your own sending library entirely is the fastest way to confirm whether the rewriting

happens before or after your infrastructure: `swaks --to recipient@example.com --from

you@yourdomain.com --server <mx-host> -tls` sends a hand-built test message straight to the MX host

and prints the exact raw reply. If swaks reproduces the same generic 500 5.7.1, the rewriting is

happening on the receiving side's path, not in your own client; if it instead returns a specific

Gmail- or Microsoft-style 550 5.7.1 with real detail, your own sending library or an outbound

relay you control is the one flattening the reply before it reaches your logs.

How to fix it

1. Fix authentication first. Confirm SPF, DKIM, and DMARC are configured and aligned for the

domain actually sending — this resolves the underlying 5.7.1 condition regardless of which

base code appeared.

1. Check blacklist status for your sending IP and domain against major DNSBLs.
2. If a corporate gateway is confirmed in the path, contact that organisation's postmaster or

IT security team directly — a generic 500 5.7.1 from a security appliance usually cannot be

resolved by adjusting your own sending infrastructure alone.

1. Review your relay configuration if you send through an intermediate relay yourself, to

confirm it passes through destination replies rather than substituting its own generic ones.

What not to do

• Do not treat the 500 as a literal syntax error in your SMTP commands — spend no time auditing

your command formatting here; the enhanced code 5.7.1 is the real signal, and it is a policy

condition, not a protocol one.

• Do not assume this is unfixable because it came from an intermediary rather than the final

mailbox server — the authentication fix (SPF/DKIM/DMARC) still applies and still helps, since

security gateways evaluate the same signals.

• Do not keep retrying against the same gateway with no changes — a 5xx embedded in this pairing

is still permanent in intent even though the wrapping code looks like a protocol-level issue.

MailPilot checks SPF, DKIM, and DMARC continuously for every connected mailbox, which addresses the

5.7.1 condition at its root regardless of which base code a downstream relay happens to wrap it

in.