What does a 550 5.7.1 error mean in email delivery?
Updated on 3 Oct 2026: We clarified who can fix a 550 5.7.1 rejection and how to use the full bounce to choose the right next step.
A 550 5.7.1 error means the SMTP server that returned the code refused the message permanently under a security or authorization rule. The first number tells you the failure is permanent. The enhanced code 5.7.1 means delivery was not authorized. The cause can be failed authentication, a blocklist or blacklist signal, a relay restriction, or a recipient-side access rule. The full bounce text identifies the next check.
Treat 550 5.7.1 as a policy refusal, not as a mailbox capacity problem. An invalid address usually has a different enhanced code. The server decided that the message, sender, domain, IP, route, or authenticated identity did not meet its acceptance rules.
- Read: Keep the exact bounce text, including the server that returned it and any wording after the code.
- Test: Send a fresh message through an email tester to inspect headers and authentication.
- Verify: Check SPF, DKIM, DMARC, sending IP, sending domain, and blocklist or blacklist status.
- Retry: Resend only after the cause is fixed, or the same policy refusal repeats.
What the code means
SMTP errors have layers. The first number is the basic status code, and the enhanced status code gives a more specific reason. A plain 550 tells you the rejection is permanent. The 5.7.1 part means "delivery not authorized, message refused." That makes it different from a user unknown error, where the address itself is invalid.
|
|
|
|---|---|---|
550 | Permanent failure | Do not keep retrying blindly |
5 | Permanent class | Fix the cause before resending |
7 | Security or policy class | Authentication and authorization |
1 | Delivery refused | Receiver rule or sender permission |
How to read a 550 5.7.1 bounce code.
Answer in one sentence
A 550 5.7.1 bounce means the SMTP server refused delivery under an authorization or policy rule, and the diagnostic text tells you which rule to investigate.
The exact words after the code matter. One server can say the sender is not authorized, while another says access denied or rejected by policy. Those phrases are the fastest clues. Preserve the full diagnostic string before changing DNS, switching IPs, or asking a receiver to review the block.
Most common causes
A 550 5.7.1 bounce is broad because servers use it for several policy failures. The cause can live on the sender side or the recipient side. Sender-side causes include authentication, outbound routing, and reputation. Recipient-side causes include a company rule, a tenant block, or restrictions on a specific address or group.
Sender-side causes
- SPF: The sending IP is not authorized in the envelope sender domain's SPF record.
- DKIM: The message is unsigned, the selector is wrong, or the signature breaks in transit.
- DMARC: Neither SPF nor DKIM passes with a domain aligned to the visible From domain when the receiver enforces DMARC.
- Reputation: The domain or IP has a poor sending history, complaint pattern, or listing signal.
- Infrastructure: PTR, forward DNS, EHLO, IPv6, or routing identity is inconsistent.
- Relay: The outbound server does not authorize this sender or submission route.
Receiver-side causes
- Policy: The recipient system blocks a domain, sender, attachment type, or pattern.
- Routing: The recipient domain points to the wrong MX, or a connector rejects the route.
- Tenant: A company mail rule rejects the message before it reaches the mailbox.
- Address: The recipient exists but has restrictions on who is allowed to send to it.
A 550 5.7.1 troubleshooting flowchart covering bounce text, authentication, domain health, reputation, receiver policy, and resend testing.
Do not assume the cause from the number alone. A 550 5.7.1 can mean an SPF miss, a broken DKIM selector, a domain on a blacklist, a blocked sending IP, an unapproved relay path, or a recipient tenant rule. The code is the same, but the fix depends on the diagnostic text.
How to diagnose it
Start with evidence, not guesswork. The domain, IP, timestamp, envelope sender, visible From domain, sending logs, and exact diagnostic text give you the path. If you only have a screenshot of the bounce, ask for the raw non-delivery report. Request original message headers when the message reached a test mailbox; a rejection before message data was accepted will not have recipient-side headers.
- Capture: Save the full bounce, including the reporting server, remote server response, and any queue ID.
- Scope: Check whether one recipient, one destination domain, or unrelated destinations reject the mail.
- Compare: Find one accepted message to the same receiver and compare headers.
- Authenticate: Check SPF, DKIM, and DMARC for the domain, then review results with a domain health checker.
- Identify: Verify PTR and forward DNS, the EHLO name, the active IP version, and the actual outbound route.
- Inspect: Look for forwarding, link wrapping, mailing list changes, or message rewriting.
- Escalate: Send the full bounce to the recipient admin for a local rule or to the sending provider for a shared IP block.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A live test message shows the headers and authentication results after routing and signing. DNS can look correct while the real message still fails because a sender uses the wrong envelope domain, signs with the wrong selector, or modifies the body after DKIM signing. A test mailbox cannot reproduce a different receiver's local policy, so compare its results with the original bounce.
Do not retry before fixing
A permanent policy refusal will not clear through repeated automatic retries. Fix the visible cause first, then run a controlled test to one recipient before resuming normal volume.
Fix SPF, DKIM, and DMARC failures
If SPF, DKIM, or DMARC is involved, fix the underlying authentication instead of loosening policy blindly. DMARC passes when SPF or DKIM passes and its authenticated domain matches the visible From domain. Under relaxed matching, the domains can share the same organizational domain. Under strict matching, they must be identical. A DMARC monitoring workflow shows which services are passing, failing, and sending without approval.
Basic DMARC record for monitoring at _dmarc.example.comDNS
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
That record requests aggregate reports and does not ask receivers to reject messages that fail DMARC. It will not, by itself, fix a 550 5.7.1 bounce. Use the reports to find legitimate sources with failed authentication or domain matching. Once every real sender has passing SPF or DKIM with correct domain matching, stage enforcement in a controlled way.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped ties the DNS record, source-level authentication, and practical fix steps together. When a sender fails DMARC domain matching, Suped shows the affected source and the authentication result to investigate. Use the full bounce and sending logs to connect that source-level pattern to a specific 550 5.7.1 rejection.
Good authentication outcome
- SPF: The sending IP is authorized for the envelope sender domain.
- DKIM: The message has a valid signature using an active selector.
- DMARC: At least one passing mechanism matches the visible From domain.
- Policy: The domain policy matches the real state of all legitimate senders.
Check sending infrastructure identity
Passing SPF, DKIM, and DMARC does not prove that the sending host has a complete identity. Receivers also evaluate the IP's reverse DNS, the hostname announced in EHLO, forward DNS, the IP version in use, and the route that delivered the message. A mismatch can trigger 550 5.7.1 wording about authorization, IPv6 requirements, or policy.
- Verify reverse DNS: Each public sending IP should resolve through PTR to a valid hostname.
- Confirm forward DNS: That hostname should resolve back to the sending IP with an A or AAAA record.
- Check EHLO: The server should announce a resolvable hostname that is consistent with its configured mail identity.
- Trace the route: Confirm the bounce came from the expected outbound IP, especially after migrations or connector changes.
- Audit IPv6: If mail uses IPv6, configure its PTR record and authentication to the same standard as IPv4.
Weak SPF endings do not establish trust
An SPF record ending in +all authorizes every IP, while ?all returns a neutral result for unmatched IPs. Neither ending creates a useful boundary between approved and unapproved senders. Inventory every real source, authorize it deliberately, and use an ending that states how other IPs should be handled.
Infrastructure checks matter most when authentication passes but a specific receiver still rejects every address at its domain. If the route recently changed, compare the current source IP and EHLO name with a previously accepted message before changing content or DMARC policy.
Reputation and blocklist checks
If authentication and sending-host identity pass but the bounce remains, shift to reputation. A domain or IP can pass SPF, DKIM, and DMARC and still be refused because the receiver does not trust the traffic. That trust decision can be based on complaint rates, traps, poor list hygiene, sudden volume, suspicious content, or a blocklist (blacklist) signal.
Check the sending IP and visible domain together. Suped's blocklist monitoring helps teams track domain and IP listings across major blocklists, then connect those signals to the same domain authentication view.
How to prioritize rejection signals
Use the bounce scope and listing evidence together to choose the next action.
Low risk
Ask admin
One recipient rejects, authentication passes, no listing signal.
Warning
Fix
One receiver rejects many recipients or a new listing appears.
Critical
Pause
Multiple receivers reject, volume changed, and listings appear.
For a reputation-based block, receiver escalation works best when you can show a clean current state. Authentication should pass, the suspect traffic source should be stopped, consent problems should be fixed, and the bounce should still occur. Give the postmaster team the affected domain, sending IP, timestamps, sample queue IDs, and completed remediation. A recipient-only permission failure instead belongs with that recipient's admin.
Receiver wording that changes the fix
The same enhanced status code can hide different operational meanings. Read the sentence around the code. If the text says relay denied, check which server returned it, then fix its routing or submission permission. If it says unauthenticated sender, inspect the named authentication or connector requirement. If it says access denied by policy, look for content rules, tenant blocks, or reputation controls.
|
|
|
|---|---|---|
Relay denied | Routing or submission | Check the rejecting server and approved route |
Access denied | Policy | Check receiver and sender rules |
Unauthenticated | Authentication | Check SPF, DKIM, DMARC, or connector permission |
Blocked sender | Receiver rule or reputation | Check rejection scope and listing evidence |
Common 550 5.7.1 wording and the first fix to try.
Separate single-recipient failures from domain-wide failures. If only one recipient bounces, the problem often sits in a local rule or recipient restriction. If every address at the same destination bounces, the receiver is likely applying a sender, domain, IP, or authentication rule. If many unrelated destinations bounce, pause sending and investigate reputation before volume continues.
Who can fix the rejection
Identify who controls the rule named in the non-delivery report before changing settings. A shared outbound IP, an internal relay, and a recipient-only block have different owners.
|
|
|
|---|---|---|
SPF, DKIM, DMARC, or EHLO failure | Sender or domain admin | Correct the sending configuration and test again |
Shared sending IP or outbound route blocked | Sending provider or IP operator | Send the full bounce and affected IP for investigation |
One recipient or group rejects external mail | Recipient admin or group owner | Review delivery restrictions and mail rules |
Match a 550 5.7.1 rejection to the team that controls the fix.
If the message is accepted elsewhere but one organization rejects it, send its admin the exact diagnostic text and timestamp. If an IP controlled by your sending provider is blocked, give the provider the full non-delivery report; changes to your domain DNS alone will not remove an IP-level block.
Where Suped fits
For one isolated bounce, read the diagnostic text, test the message, check DNS, and correct the sender setup. For a team sending through several services, Suped brings DMARC, SPF, DKIM, blocklist visibility, alerts, and guided fixes into one place.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped can surface new sending sources, falling authentication rates, SPF lookup pressure, and domain or IP listings. Teams can use its alerts and multi-domain views to find the affected sender, then confirm the specific transaction in the bounce and sending logs.
- Triage: See which source, domain, and authentication result changed.
- Repair: Follow issue-specific steps instead of guessing which DNS record to edit.
- Prevent: Use reporting and alerts to catch broken authentication before receivers reject mail.
- Scale: Manage many domains through a multi-tenant view for internal teams or MSPs.
Views from the trenches
Best practices
Keep the full bounce text, sending IP, domain, and timestamp together before changing DNS.
Confirm SPF, DKIM, and DMARC first, then check blocklist and blacklist signals next.
Escalate to the receiver only after you have clean logs and a clear remediation note.
Common pitfalls
Troubleshooting without the sending domain wastes time and hides DNS or reputation causes.
Treating every 550 5.7.1 as a spam issue misses relay, auth, and access problems.
Changing DMARC policy before verifying sources creates new failures during the next send.
Expert tips
Compare one failed message with one accepted message to isolate the receiver policy change.
Use aggregate DMARC data to find unverified services before tightening enforcement.
Record the exact enhanced code because 5.7.1 and 5.7.26 point to different fixes.
Marketer view
Marketer from Email Geeks says missing or failing SPF, DKIM, or DMARC is a common first place to check when a receiver returns 550 5.7.1.
2023-09-05 - Email Geeks
Marketer view
Marketer from Email Geeks says checking DNSBLs, blocklist entries, and blacklist entries helps separate authentication failure from reputation refusal.
2023-09-05 - Email Geeks
How to fix 550 5.7.1
A 550 5.7.1 error is a permanent policy rejection. Read the full bounce, identify the server that refused the message, verify authentication and sending-host identity, then check domain and IP reputation. Determine whether the rejection is sender-wide, receiver-wide, or recipient-specific and route the fix to the team that controls it. Once the cause is fixed, send a controlled test before returning to normal volume.
