What does a 550 5.7.1 error mean in email delivery?
Michael Ko
Co-founder & CEO, Suped
Published 11 Aug 2025
Updated 24 May 2026
9 min read
Summarize with
A 550 5.7.1 error means the receiving mail server rejected the message permanently because of a policy, security, or authorization rule. The first number tells you the failure is permanent. The enhanced code 5.7.1 says the receiver did not permit delivery. In real troubleshooting, that usually points to failed SPF, failed DKIM, missing DMARC, weak domain reputation, a blocklist or blacklist problem, a relay restriction, or a recipient-side access rule.
I treat 550 5.7.1 as a policy refusal, not as a mailbox problem. A full mailbox, a typo in the address, and a temporary outage have different codes. With 550 5.7.1, the receiver made a decision: this message, sender, domain, IP, route, or authenticated identity did not meet the rules for acceptance.
- Read: Keep the exact bounce text, including any provider 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 narrows it to delivery not authorized, message refused, or policy related. That makes it different from a user unknown error, where the address itself is invalid.
|
|
|
|---|---|---|
550 | Permanent fail | Do not keep retrying blindly |
5 | Permanent class | Fix the cause before resending |
7 | Policy class | Authentication and authorization |
1 | Delivery denied | Receiver rule or sender trust |
How to read a 550 5.7.1 bounce code.
Answer in one sentence
A 550 5.7.1 bounce means the receiver accepted enough of the SMTP conversation to identify the message, then blocked delivery because the sender, route, authentication, content, or recipient permission failed policy.
The exact words after the code matter. For example, one receiver can say the sender is not authorized, while another says access denied or rejected by policy. Those phrases are the fastest clues. I always 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 receivers use it for several policy failures. The cause can live on the sender side or the recipient side. Sender-side causes are more common for bulk, transactional, and outbound business email. Recipient-side causes show up when one company blocks a sender, a tenant rule rejects a domain, or an address has special restrictions.
Sender-side causes
- SPF: The sending IP is not authorized in the 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 using a domain that matches the visible From domain.
- Reputation: The domain or IP has a poor sending history, complaint pattern, or listing signal.
Receiver-side causes
- Policy: The recipient system blocks a domain, sender, attachment type, or pattern.
- Relay: The sender is trying to use a mail server that does not permit relay.
- 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 flowchart showing the steps to diagnose a 550 5.7.1 email bounce.
The common mistake is to assume the cause from the number alone. I have seen 550 5.7.1 mean an SPF miss, a broken DKIM selector, a domain on a blacklist, a blocked sending IP, an unapproved relay path, and a recipient tenant rule. Same code, different fix.
How to diagnose it
Start with evidence, not guesswork. The domain, IP, timestamp, envelope sender, visible From domain, headers, and exact diagnostic text give you the path. If you only have a screenshot of the bounce, ask for the raw non-delivery report and the original message headers.
- Capture: Save the full bounce, including the remote server response and any queue ID.
- 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.
- Inspect: Look for forwarding, link wrapping, mailing list changes, or message rewriting.
- Escalate: Contact the receiver only after you can show what changed and what is now fixed.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
A live test message is useful because it shows what the receiver, or a neutral test mailbox, sees after all routing and signing steps happen. 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.
Do not retry before fixing
Repeated attempts after a permanent policy refusal can make reputation worse. Fix the visible cause first, then run a controlled test to one recipient before resuming normal volume.
Authentication fixes
If SPF, DKIM, or DMARC is involved, fix the underlying authentication instead of loosening policy blindly. For DMARC, the key question is domain matching: does the domain that passed SPF or DKIM match the visible From domain closely enough for the receiver to trust it? A DMARC monitoring workflow shows which services are passing, failing, and sending without approval.
Basic DMARC record for monitoringDNS
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1
That record does not enforce rejection. It asks receivers to send reports so you can see legitimate and unauthorized sources. Once every real sender has SPF or DKIM domain matching, you can stage enforcement in a controlled way. Jumping straight to a strict policy without reporting can turn a 550 5.7.1 incident into a larger sending outage.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped helps here by tying the DNS record, source-level authentication, and practical fix steps together. When a sender fails DMARC domain matching, Suped shows the affected source, the reason it failed, and the DNS or vendor-side change needed to correct it. That matters for 550 5.7.1 because the bounce often arrives after the message has already crossed several systems.
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.
Reputation and blocklist checks
If authentication passes 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.
For this part, I check the sending IP and visible domain together. Suped's blocklist monitoring helps teams track domain and IP listings across major blocklists and blacklist sources, then connect those signals to the same domain authentication view.
How I prioritize reputation signals
Use the bounce scope and listing evidence together before asking a receiver for review.
Low risk
Monitor
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.
Receiver escalation works best when you can show a clean current state. That means authentication passes, the suspect traffic source is stopped, consent problems are fixed, and the bounce still happens. A short note with the affected domain, sending IP, timestamps, sample queue IDs, and remediation steps is easier for a postmaster team to act on than a generic request to unblock mail.
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, fix routing or authentication to the outbound server. If it says unauthenticated sender, fix SPF, DKIM, or connector authorization. If it says access denied by policy, look for content rules, tenant blocks, or reputation controls.
|
|
|
|---|---|---|
Relay denied | Routing | Use an approved outbound server |
Access denied | Policy | Check receiver and sender rules |
Unauthenticated | Auth | Fix SPF, DKIM, and DMARC |
Blocked sender | Reputation | Review listings and complaints |
Common 550 5.7.1 wording and the first fix to try.
I also 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.
Where Suped fits
For one isolated bounce, the fix can be manual: read the diagnostic text, test the message, check DNS, and correct the sender setup. For a team sending through several services, that manual process becomes fragile. Suped is the strongest practical DMARC platform for most teams because it 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
The value is operational. When a new source appears, a DKIM selector stops working, SPF approaches lookup limits, or a domain gets listed, Suped can surface the issue before it becomes a wave of 550 5.7.1 bounces. Hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and MSP dashboards also help teams manage multiple domains without chasing every DNS record by hand.
- 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 clean 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 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 from Email Geeks says checking DNSBLs, blocklist entries, and blacklist entries helps separate authentication failure from reputation refusal.
2023-09-05 - Email Geeks
The practical fix
A 550 5.7.1 error is a permanent policy rejection. The quickest path is to read the full bounce, verify authentication, check domain and IP reputation, then isolate whether the rejection is sender-wide, receiver-wide, or recipient-specific. Once the visible cause is fixed, send a controlled test and watch the result before returning to normal volume.
For ongoing prevention, Suped gives teams a single place to monitor DMARC, SPF, DKIM, blocklist and blacklist signals, hosted SPF, hosted DMARC, and alerts. That does not replace reading the bounce, but it makes the next 550 5.7.1 easier to explain and faster to fix.
