What do bounce error messages 550 5.7.1 and 554 mean and how to resolve them?
Published 24 Jul 2025
Updated 22 Jun 2026
16 min read
Summarize with
Updated on 23 Jun 2026: We updated this guide with clearer bounce-code list handling and current Gmail and Microsoft triage details.
A 550 5.7.1 bounce means the receiving server refused the message for a policy reason. The policy can be sender reputation, blocklist (blacklist) status, recipient permissions, relay rights, Microsoft 365 routing, Gmail authentication requirements, content filtering, or a local gateway rule. It is not automatically proof that the recipient address is invalid.
A 554 bounce means the transaction failed or the receiver rejected the message under a security policy. Treat it as policy, reputation, authentication, routing, relay, content, attachment, loop, malformed-message, or gateway evidence until the raw text narrows the cause.
Both codes begin with 5, so they are permanent for that delivery attempt, but they are not automatic contact-suppression signals. Do not keep retrying the same message unchanged, and do not remove contacts unless the text proves the mailbox, alias, group, or account is invalid.
- Read the words after the SMTP code before choosing a fix.
- Use public bounce-code lists for orientation, then keep an internal map that ties repeated replies to retry, suppress, authentication, reputation, relay, routing, or escalation.
- Separate invalid-recipient bounces, valid-address policy bounces, relay-denied events, provider-specific spikes, soft bounces, and transport failures before changing list status.
- Prove SPF, DKIM, DMARC, PTR or reverse DNS, From header validity, Message-ID validity, TLS where required, IP reputation, sender route, recipient-domain DNS, and MX ownership before asking for allowlisting.
- For Salesforce Marketing Cloud 554s, group _Bounce rows by domain, job, source, category, subcategory, SMTP code, and SMTP wording before retrying or suppressing.
What the two bounce messages mean
Typical bounce texttext
smtp; 550 5.7.1 Messages from [23.251.255.157] weren't sent. Part of their network is on our block list (S3150). smtp; 550 5.7.1 [C15] RBL restriction: Blacklisted by Internal Reputation Service - 203.0.113.25 smtp; 550 5.7.1 relaying denied for user@example.net smtp; 550 Invalid Domain [smtp-41.iol.local; VIR_420] smtp; 554 Email rejected due to security policies. smtp; 5.0.0 (undefined status) permanent failure for one or more recipients (recipient@example.com:blocked)
The base SMTP code tells you broad behavior. A 550 can mean mailbox unavailable, no access, relay refused, or command rejected for policy reasons. The enhanced code 5.7.1 points to delivery not authorized or message refused, but the provider text identifies the first fix path.
When the text names a block list, blacklist, internal reputation service, low IP reputation, low domain reputation, or sender denied rule, classify the event as reputation or policy. When it says relaying denied, compare the rejecting IP with the current MX path and check relay permissions before suppressing contacts.
Microsoft 365 uses the 5.7.x family for several causes: restricted recipients, large distribution groups, mail-enabled public folders that require authenticated senders, source IP blocklist cases, stale MX records, incomplete SPF, hybrid connectors, mail flow rules, and transport rules. A group with more than 5,000 members can require moderator approval or reject oversized messages. A public folder can return RESOLVER.RST.AuthRequired when external senders are not allowed.
|
|
|
|---|---|---|
550 5.7.1 | Policy refusal, with the bounce text naming the trigger. | Check permissions, routing, reputation, and authentication. |
Internal Reputation Service | Private receiver reputation service refused the sender. | Group by MX, source IP, ASN, and rejection token. |
550 relaying denied | The server refused to relay for that recipient or route. | Compare Remote-MTA, current MX, route rules, and relay permissions. |
554 | Transaction failed or security policy rejection. | Compare content, authentication, attachments, and recipient pattern. |
451 or 452 | Temporary failure, quota issue, or transient condition. | Retry with backoff and keep it out of hard-bounce suppression. |
Quick interpretation of common SMTP bounces.
Microsoft wording matters
Microsoft's 550 5.7.1 guidance treats these as NDR, bounce message, delivery status notification, or DSN cases. For Microsoft 365 domains, confirm domain health, MX records, SPF coverage, connector scope, smart-host selection, recipient restrictions, and source IP blocklist status before suppressing recipients.
How to read the raw SMTP response
Find the raw SMTP response in the NDR or DSN, ESP delivery event, webhook payload, outbound MTA log, or SMTP transcript. A normal bounce record has the platform label, the human-readable explanation, and the original SMTP error line. Do not rely on a dashboard label such as blocked, invalid, or deferred because that label usually removes the provider wording that explains the fix.
Treat public bounce-code references as lookup aids, not the system of record. The enhanced status code tells you the class and subject, provider wording tells you the local rule, and your own saved examples tell you which action actually worked for that mailbox provider, gateway, or sender route.
Preserve DSN fields such as Action, Status, Reporting-MTA, Remote-MTA, Final-Recipient, and Diagnostic-Code. Also save timestamp, timezone, sending IP, message ID, recipient, retry result, affected MX host, resolved MX IP, recipient-domain DNS status, and any no-MX, null-MX, NXDOMAIN, timeout, or SERVFAIL result.
SMTP 550 5.7.1 and 554 bounce triage flowchart showing receiver, IP, authentication, content, and owner checks.
- Read the base reply code first. 4xx is temporary. 5xx is permanent for that delivery attempt.
- Read the enhanced status code next. 5.7.1 points to security or policy. 5.1.1 points to address status. 5.2.2 points to mailbox status.
- Check the SMTP stage. A RCPT TO rejection often points to recipient validity, permissions, routing, or relay rights. A rejection after DATA often points to content, authentication, link reputation, or a policy scan.
- Read provider text last. Phrases such as block list, blacklist, internal reputation service, relaying denied, auth failed, security policy, user unknown, no MX, connection timeout, or i/o timeout decide the first fix path.
Do not suppress from 550 alone
A 550 can mean invalid recipient, no access, mailbox unavailable, relaying denied, or policy refusal. Suppress only when the enhanced code and text confirm a bad address, such as 550 5.1.1 user unknown, bad address syntax, disabled mailbox, unknown recipient, bad destination mailbox address, or missing mailbox, alias, group, or shared mailbox.
SMTP authentication, relay, and routing checks
SMTP authentication usually happens between your app and your outbound mail service. A receiver-side 550 5.7.1 or 554 rejection means the recipient's mail system saw the message and made a delivery decision. If the log shows 530 authentication required, 535 invalid credentials, 504 5.7.40 unrecognized authentication type, or unsupported XOAUTH before handoff, handle it as an SMTP login or authentication-method problem first.
A 550 relaying denied bounce means the SMTP server that answered your delivery attempt refused to relay the message for that recipient or sending path. Compare the rejecting Remote-MTA and IP with the recipient domain's current MX answers, then inspect transport maps, pinned MX entries, smarthost rules, connector scope, relay credentials, tenant domain registration, and envelope sender domain.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
SMTP login problem
- Fails between your app and outbound mail service.
- Logs mention invalid credentials, unsupported SMTP AUTH, or API key rejection.
- Fix credentials, verify sender identity, confirm the supported method, and resend a test.
Policy or reputation block
- Fails at the recipient server, relay, or security gateway.
- Bounce mentions blocklist, blacklist, internal reputation, relaying denied, security policy, spam, or denied sender text.
- Fix reputation, authentication, routing, message content, or recipient targeting.
Authentication evidence to look fortext
Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounces.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
A practical triage and suppression process
Start by collecting the full NDR or DSN, sending IP, visible From domain, envelope sender domain, recipient domain, affected MX host, sending platform, message type, and SMTP stage. One bounce to one protected domain is different from the same bounce across many mailbox providers.
If the sender log only says error dialing remote address, dial tcp, i/o timeout, or connection timed out, start with transport evidence: destination MX, resolved IP, source IP, port 25 egress, route, firewall path, and whether the timeout happened before the SMTP banner.
Triage checklist
- Classify the event as temporary deferral, hard bounce, connection timeout, relay-denied event, recipient-address failure, sender-domain DNS failure, recipient-domain DNS failure, provider-acceptance issue, or delayed out-of-band DSN.
- Separate Microsoft, Google, Apple, gateway, corporate-domain, legacy ISP, and ISP-family failures by MX.
- Map each bounce to sending IP, pool, DKIM selector, SMTP stage, envelope sender, outbound route, MX host, and template.
- Test one plain text version and one normal version to isolate content rules.
- Escalate with raw evidence, not a general deliverability request.
|
|
|
|---|---|---|
User unknown or invalid address | Yes | Suppress after the confirmed hard bounce. |
No MX, null MX, NXDOMAIN, or recipient domain not found | Yes, after confirmation | Suppress confirmed no-route domains; retry resolver timeout or SERVFAIL first. |
Mailbox full, over quota, or repeated 451/452 | Yes, when repeated | Count consecutive soft bounces and reset on delivery. |
Rate limit, greylisting, or 421 Service not available | No | Throttle, retry, and keep the address active. |
Provider-specific incident spike | No | Quarantine the pattern, tag the time window, and retest. |
Relaying denied or wrong route | No | Fix MX, transport map, smarthost, connector, or relay permission first. |
Blocklist, blacklist, or reputation | No | Pause affected traffic and fix the sender issue. |
SPF, DKIM, DMARC, TLS, or DNS failure | No | Repair the sending path before retrying. |
Use reason-aware suppression instead of suppressing every 550 or 554 event.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
How to resolve blocklist and blacklist bounces
When the bounce names a block list or blacklist, first identify whether the sending IP is dedicated or shared. On a shared IP, another sender can damage the pool's reputation. On a dedicated IP, check recent volume, complaint rate, old addresses, suppression, unexpected content, compromised integrations, and traffic separation.
A bounce that says Blacklisted by Internal Reputation Service is a private receiver reputation block even when public blocklist and blacklist checks are clean. Group those failures by MX host, resolved IP, ASN, abuse contact, backend mail operator, and exact rejection token before opening tickets.
Suped's blocklist monitoring connects IP and domain reputation checks with DMARC and authentication evidence, so the team can see whether the problem is isolated to reputation or part of a wider sending-path issue.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
- Shared IP: open an ESP ticket and ask whether the pool is under active mitigation.
- Dedicated IP: pause risky traffic, check recent list imports, and review complaint sources.
- Internal reputation: group the bounce by MX host, backend owner, ASN, and exact rejection token.
- Microsoft S3150: preserve the original NDR and have the IP owner or ESP handle the delist route for shared pools.
Gmail-specific 550 5.7.1 and 554 clues
A Gmail 550 5.7.1 response that says the message is likely suspicious because of very low reputation is a reputation incident first. It is not fixed by retrying normal volume, changing random DNS records, or assuming every affected Gmail address is invalid.
Gmail low reputation patterntext
550 5.7.1 ... very low reputation of the sending IP address ... - gsmtp 550 5.7.1 ... very low reputation of the sending domain ... - gsmtp 421 4.7.0 ... very low reputation of the sending IP address ... temporarily rate limited ... - gsmtp
Gmail's SMTP errors page lists 421 4.7.40 for a sending domain that lacks a DMARC record or a DMARC policy, and 550 5.7.40 for the blocked version of the same requirement. It also lists 421 4.7.32 and 421 5.7.32 for From-header domain matching failures, with the base reply code deciding queue handling.
A specific Gmail 550 5.7.26 means unauthenticated mail, envelope-sender SPF hard fail, or unauthenticated mail blocked by the sending domain's DMARC policy. Check every continuation line because later lines often name SPF, DKIM, or DMARC.
- 4.7.23 or 550 5.7.25: PTR or forward DNS.
- 4.7.24 or 550 5.7.24: suspicious SPF entries.
- 4.7.27 or 550 5.7.27: SPF failure.
- 4.7.29 or 550 5.7.29: missing TLS for bulk mail.
- 4.7.30 or 550 5.7.30: DKIM failure.
- 4.7.28 or 550 5.7.28: unusual sending rate, quota, or unsolicited-mail pattern.
Gmail's sender guidelines require at least SPF or DKIM for personal Gmail accounts. Bulk senders need SPF, DKIM, DMARC, valid PTR and forward DNS, TLS, From-domain matching for direct mail, one-click unsubscribe for marketing or subscribed mail, valid headers, and a spam rate below 0.3%.
Apple and 554 security policy bounces
Apple can return 550 5.7.1 or 554 5.7.1 local policy text for iCloud Mail domains such as icloud.com, me.com, and mac.com. CS01, HM07, and HM08 should be treated as Apple receiver policy decisions, not proof that the recipient complained or that the address is invalid.
Apple local policy examplestext
550 5.7.1 [CS01] Message rejected due to local policy. 554 5.7.1 [HM07] Message rejected due to local policy. 554 5.7.1 [HM08] Message rejected due to local policy.
A 554 policy rejection needs more context because the same code can cover content, identity, relay rules, and recipient gateway rules. Test the original message, a plain text version, a version without links, and a version without attachments. If the enhanced code is 5.4.6, look for a loop. If it is 5.6.0 or says malformed, inspect MIME boundaries, header syntax, and generated HTML before treating it as reputation.
|
|
|
|---|---|---|
security policy | Gateway rule or reputation. | Plain text resend and ESP logs. |
spam content | Template or link domain. | Remove links and attachments. |
auth failed | SPF, DKIM, or DMARC. | Inspect headers and DNS. |
relay denied | Connector, relay permission, or route. | Compare current MX, route, and relay credentials. |
malformed message | Header, MIME, or HTML structure. | Inspect From, Message-ID, MIME, and HTML. |
Common 554 clues and the next diagnostic step.
Suped fits this workflow when the team needs one place for authentication, blocklist, blacklist, and deliverability signals. Its DMARC monitoring turns DMARC data into source-level issues, real-time alerts, and concrete fix steps instead of leaving raw reports for someone to decode manually.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
What to send your ESP or IT team
If the sending IP is shared, the ESP has more data than the sender. They can see pool behavior, queue behavior, complaint signals, retry patterns, and provider-specific feedback. Ask for ownership and next steps, not only a definition of the bounce code.
ESP escalation templatetext
We are seeing delivery failures with these responses: 550 5.7.1 network is on our block list (S3150) 550 5.7.1 RBL restriction: Blacklisted by Internal Reputation Service 550 5.7.1 relaying denied for user@example.net 421 Service not available, closing transmission channel 451 or 452 local temporary failure, mailbox full, or over quota 554 Email rejected due to security policies 5.0.0 undefined status permanent failure with blocked wording 550 5.7.1 [CS01] Message rejected due to local policy 554 5.7.1 [HM07] Message rejected due to local policy 554 5.7.1 [HM08] Message rejected due to local policy error dialing remote address or dial tcp i/o timeout Please confirm: - the sending IP, HELO/EHLO name, and IP pool for each message ID - the PTR/reverse DNS name used by the affected sending IPs - whether the pool is shared or dedicated - the visible From domain, envelope sender domain, and return-path domain - whether this IP range has a known reputation issue - whether the response points to recipient permission, routing, relay rights, content, authentication, IP reputation, sender-domain DNS, recipient-domain DNS, provider acceptance, local policy, temporary deferral, delayed DSN classification, or transport failure - whether the rejection happened at RCPT TO, after DATA, after initial acceptance, before SMTP banner, or during TCP connection - whether TLS was offered and used when the receiver required it - whether SPF, DKIM, and DMARC passed at handoff - what remediation or provider escalation is in progress
Evidence to include
- Full raw NDR or DSN text, not a shortened CRM status.
- Provider message ID, campaign ID, and timestamp with timezone.
- Normal bounce rate beside the incident rate for the same receiver, sender, pool, and UTC window.
- Visible From domain, envelope sender domain, return-path domain, DKIM domain, and link tracking domain.
- Sending IP, IP pool, HELO or EHLO name, PTR record, reverse DNS result, outbound route, and TLS result when the receiver names it.
- Exact SMTP rejection text, RCPT TO or DATA stage, delayed DSN timing, TCP timeout text, or the connection stage if the issue is a timeout rather than a bounce.
How to stop the same bounces returning
After the immediate block is handled, look for the condition that let the problem reach production. For transactional mail, that often means unverified form addresses, weak suppression, a shared IP with mixed senders, a relay route that changed, or a template that looks automated and lacks clear context for the recipient.
Starter DMARC recordtext
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The record above is only a starter. Move policy carefully after reports show that legitimate senders pass, then tighten SPF and DKIM domain matching only when third-party sending paths are known and stable. Hosted DMARC and hosted SPF in Suped are useful when multiple teams or vendors send mail and DNS access is slow, because sender changes can be staged without repeated manual TXT edits.
- Source control: keep a current inventory of every platform allowed to send for the domain.
- List hygiene: suppress confirmed invalid-recipient hard bounces, keep provider holds separate, and quarantine sudden provider-specific spikes before broad purges.
- Traffic separation: keep critical transactional mail away from bulk or experimental sends.
- Infrastructure checks: keep PTR, reverse DNS, HELO or EHLO naming, TLS behavior, return-path DNS, smarthost rules, and relay permissions consistent with the sending path.
- Alerting: monitor rejection spikes by provider, IP, source, route, and authentication result.
Views from the trenches
Best practices
Preserve raw bounce text before ticketing so exact provider wording reaches the owner.
Separate shared IP incidents from sender-domain issues before changing DNS or content.
Compare rejecting IPs with current MX records when relay-denied errors spike suddenly.
Test the same message with links removed to isolate content rules from IP reputation.
Common pitfalls
Treating every 550 5.7.1 as auth failure wastes time when the IP is already blocked.
Asking for allowlisting before checking shared IP reputation leaves the root cause active.
Suppressing relay-denied contacts before route checks can remove valid recipients from lists.
Opening ESP tickets without IPs, timestamps, and message IDs slows investigation quickly.
Expert tips
Map each bounce to the sending pool so provider-owned issues become clear quickly.
Use DMARC reports to find new sender sources before policy filters start rejecting.
Track 554 failures by template because content changes often trigger local receiver rules.
Record Remote-MTA and Diagnostic-Code fields before CRM labels shorten the bounce.
Expert from Email Geeks says the 550 text points first to reputation blocking, not a basic SMTP login failure.
2023-07-24 - Email Geeks
Expert from Email Geeks says a 554 security-policy bounce can be a local blocklist or a content-based rejection.
2023-07-24 - Email Geeks
The practical resolution path
The direct fix depends on ownership. A 550 5.7.1 that names a block list, blacklist, or internal reputation service needs reputation investigation and usually ESP involvement, especially on shared IPs. A 550 relaying denied needs rejecting-IP, current-MX, smarthost, connector, and relay-permission checks before recipient suppression. A 554 security-policy block needs full SMTP evidence, authentication review, content testing, and recipient-pattern analysis.
Provider-specific failures need their named fix. Gmail low-IP or low-domain-reputation responses need Gmail-only volume review and a slow restart of clean mail. Gmail codes that name suspicious SPF entries, PTR, TLS, SPF, DKIM, From-domain matching, DMARC, unusual sending rate, relay routing, quota, malformed headers, message size, header size, or recipient count need that requirement fixed first.
Do not assume SMTP authentication is the root cause unless logs show a credential failure before handoff. Start with the full bounce text, identify the sending IP owner, prove SPF, DKIM, and DMARC, then ask the ESP or recipient for the specific policy evidence needed to release the block.
Suped is built for the ongoing part of this work: monitoring DMARC, surfacing unknown senders, detecting authentication failures, alerting on reputation changes, and giving fix steps that a team can act on without parsing every raw report by hand.
