A 550 5.7.1 error means the receiving system refused delivery for a security or policy reason. The number alone does not identify the fix. Read the text after it: a restricted recipient, unauthorized relay, message-format problem, authentication failure, or reputation block needs a different response.
Start with the complete bounce message, not a blanket DNS change. This guide helps you identify the rejecting system, choose the right owner, and test the correction without repeatedly resending the same rejected campaign.
What does 550 5.7.1 mean?
The enhanced status code 5.7.1 describes delivery that is not authorized and a message that was refused. The leading 5 indicates a permanent failure for that delivery attempt. It does not mean the address is permanently unusable; an administrator may be able to correct the policy or configuration. See the enhanced mail status-code standard.
A rejection is different from spam-folder placement: the receiving system did not accept this delivery attempt. A successfully accepted message can still be filtered later. Keep bounce results and placement results separate in your reporting.
Match the bounce text to the next check
| The bounce points to | Check first | Who can act |
|---|---|---|
| Recipient, group, or organization policy | Whether this sender is allowed to contact that recipient; ask for the specific restriction or mail-flow rule. | Recipient or receiving mail administrator |
| Relay access or relay credentials | The SMTP service and relay method configured in the sending application. | Sending mail administrator or email provider |
| Authentication or domain alignment | The failed message's authentication results and the domains actually used by the sending service. | Sending service owner and DNS administrator |
| IP/domain reputation or unwanted mail | The affected sending stream, recent changes, recipient complaints, and the provider's diagnostic information. | Sending team and email provider |
| PTR, IPv6, or message headers | The specific DNS or message-format requirement named in the response. | Sending infrastructure or application owner |
This is a triage map, not a diagnosis from the number alone. Google documents several different 550 5.7.1 responses, including policy, relay, reputation, IPv6, and malformed-header cases.
How to fix a Gmail 550 5.7.1 rejection
- Save the exact response. Keep the diagnostic text, rejecting server, timestamp, sending IP if available, and message ID. Redact recipient addresses and message content before sharing outside the people handling the incident.
- Follow the named failure. A policy response needs a policy investigation. A relay response needs the configured relay reviewed. A PTR or header response needs that particular configuration corrected.
- For reputation-related responses, compare affected traffic. Group failures by sending provider, domain, campaign, and recipient provider. This helps distinguish one problematic stream from an account-wide configuration issue.
- Check available Gmail evidence. Use Google Postmaster Tools alongside your provider's logs. A public DNS or blocklist result does not expose Gmail's complete filtering decision.
- Retest the corrected path. Send a controlled message to an authorized test recipient using the same application and sending identity. Record whether the rejection disappears; investigate placement separately.
How to fix a Microsoft 365 550 5.7.1 rejection
Microsoft's guidance includes restricted recipients and groups, relay permissions, routing, and configuration problems. If delivery fails only for one group or organization, send its administrator the relevant diagnostic details and ask which rule prevented delivery. A sender-side DNS change cannot grant permission to a restricted group. Follow the case that matches your NDR in Microsoft's 5.7.1 troubleshooting guide.
If several applications are affected, make a small comparison table: sending application, sender domain, recipient domain, exact response, and time. Start with the common component. Keep unrelated transactional traffic separate while investigating a failing marketing stream.
Check authentication without weakening protection
If the evidence points to authentication, check the actual sent message, not just whether DNS records exist. Confirm that the sending service signs with DKIM and that the authenticated identity aligns as required. DMARC can pass through aligned SPF or aligned DKIM; one failed mechanism does not automatically mean DMARC failed. See Google's DMARC alignment explanation.
Do not change DMARC to a weaker policy merely because the bounce contains 5.7.1. Correct the identified source or alignment problem with the domain owner. Likewise, changing wording or adding warm-up activity does not repair a recipient permission or SMTP relay error.
Choose a diagnostic that answers the next question
- Folderly Lens helps inspect public DNS, authentication, and IP signals. Use it when the response points to sending setup.
- Folderly Flash checks a real test message from your sending tool and domain. It does not grant access to a recipient's mail policy.
- Inbox Insights helps test placement after messages can be accepted. A seed test is a sample, not a guarantee for every recipient.
Frequently asked questions
Should I keep retrying a 550 5.7.1 bounce?
Do not repeatedly resend an unchanged rejected message. Identify and correct the reported cause, then make a controlled retry. A 5xx response differs from a temporary 4xx deferral.
Does 550 5.7.1 prove my domain is blacklisted?
No. The same code can accompany permission, relay, formatting, and other policy failures. Use the full diagnostic response to decide whether a reputation or blocklist investigation is relevant.
How long does fixing it take?
There is no universal recovery time. A configuration correction and a provider reputation review are different processes. Record the change and its observed result rather than promising a fixed deadline.