5.7.1 is Gmail’s general policy rejection. On its own it says only that a policy applied to this delivery was not satisfied; the text that follows identifies which. Treating every 5.7.1 as the same problem is the main reason it takes so long to resolve.
Most common causes
- Destination or sender policy does not accept the message
- Authentication or reputation evidence is insufficient for the policy path
- The message is being rejected by a domain-specific rule
- The detailed text following the status code identifies a more specific cause
What to verify next
- Use the complete provider diagnostic, not only 5.7.1
- Inspect authentication results and the sending domain state
- Separate domain policy from recipient-specific rejection
- Retest only after the specific cause in the diagnostic has been addressed
Several different rejections share this code
Gmail uses 5.7.1 for recipient-side policy (a Workspace admin blocked external mail or a specific sender), for content and attachment policy, for messages that look like known abuse patterns, and for authentication or reputation problems when a more specific code does not apply.
The distinguishing information is the sentence after the code and, often, a support URL. A rejection mentioning "the recipient’s domain" is a receiving-side rule; one mentioning "this message" or "likely unsolicited" is a content or reputation judgement about the sender.
Separate recipient policy from sender state
When only one recipient organization rejects while everyone else accepts, the cause is almost always a rule inside that organization: an admin-configured block, an attachment type policy, or a compliance filter. No change to your DNS resolves it; the recipient administrator has to allow the sender.
When many Gmail recipients reject with the same 5.7.1 text, look at the sender: authentication, reputation, sudden volume changes, or content the classifier associates with abuse.
- One recipient rejecting: recipient-side policy.
- Many recipients rejecting: sender authentication, reputation or content.
- A support URL in the text narrows the category further.
Verification path
Classify the complete text with Mail Failure Doctor first. If it points at the sender, verify SPF, DKIM and DMARC for the real sending path and inspect a delivered header from the same platform. If it points at the recipient, collect the exact text and recipient address and hand it to their administrator.
Do not retry a permanent 5.7.1 unchanged. Repeated identical attempts against a policy rejection degrade sender reputation without any chance of delivery.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- Gmail intentionally keeps some 5.7.1 wording generic for security reasons; not every rejection can be attributed precisely from the text alone.
- Recipient-organization rules are invisible from outside; only their administrator can confirm them.
Common questions
Is 5.7.1 a blacklist?
Not usually. It is a policy verdict. Reputation can contribute, but the code covers recipient rules and content policy as well.
Why does the same message deliver to Outlook but not Gmail?
Receivers apply independent policy. Gmail may enforce an authentication or content rule that another provider tolerates.
Should I contact Google?
For sender-side reputation, use Postmaster Tools. For a recipient-side block, contact the recipient organization; Google support cannot override an admin’s policy.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Gmail SMTP errors and codes.