What do bounce error messages 550 5.7.1 and 554 mean and how to resolve them?
Published 24 Jul 2025
Updated 25 Oct 2026
17 min read
Summarize with
Updated on 25 Oct 2026: We clarified SMTP retry and suppression rules and added practical fixes for SPF, DKIM, and DMARC failures.
A 550 5.7.1 bounce means the receiving server refused delivery for a security or policy reason. Common causes include sender reputation, blocklist (blacklist) status, recipient permissions, relay restrictions, authentication failures, and content filtering. It is not automatically proof that the recipient address is invalid.
A 554 bounce means the SMTP transaction failed. Security policies are a common cause, but the full response and SMTP stage determine whether to investigate authentication, reputation, routing, or the message itself.
Both codes begin with 5, so they are permanent SMTP failures, often called hard bounces. Permanent describes the failed attempt, not the lifetime validity of the address. Stop automatic retries of the unchanged message; send a controlled test after correcting the cause. Suppress a recipient only when the response confirms an invalid or permanently disabled destination.
A final 250 after message data means that server accepted responsibility for delivery, not that the message reached the inbox. Junk folder placement is not a bounce. A later delivery failure can still generate a separate delivery status notification (DSN); investigate that notification using its own status and diagnostic text.
- Read the full SMTP response before choosing a fix.
- Separate invalid-recipient failures from policy blocks, temporary deferrals, and transport failures before changing list status.
- Check the sending IP, authentication results, and route named in the response before requesting a policy exception.
- Group repeated failures by recipient domain, sending source, and exact response text so the responsible team can investigate.
What 550 5.7.1 and 554 mean
Illustrative bounce texttext
smtp; 550 5.7.1 Messages from [192.0.2.25] 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; 554 Email rejected due to security policies.
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. These definitions follow RFC 3463 for enhanced status codes and RFC 5321 for SMTP replies. A 554 greeting can also mean "No SMTP service here", before any message body is sent.
Use the class split before suppression: 4xx is a soft bounce or deferral, 5.1.x points to address status, and 5.7.x points to authorization or policy. That is why 550 5.1.1 and 550 5.7.1 need different actions even though both start with 550.
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 requires moderator approval, and oversized messages can produce a separate NDR. A public folder can return RESOLVER.RST.AuthRequired when external senders are not allowed. For Exchange Online domains, also verify domain enrollment, a single expected MX path, and hybrid or smart-host connector scope before treating recipients as bad addresses.
|
|
|
|---|---|---|
550 5.7.1 | Policy refusal, with the bounce text naming the trigger. | Check permissions, routing, reputation, and authentication. |
554 | Transaction failed; at connection opening, no SMTP service is available to this client. | Check the SMTP stage and diagnostic text before testing content or authentication. |
421 or 4.7.x | Temporary deferral, rate limit, greylisting, or provider throttle. | Retry with backoff and watch the provider trend. |
451 or 452 | Temporary failure, quota issue, or transient condition. | Retry with backoff and keep it out of hard-bounce suppression. |
550 5.1.1 | Destination mailbox does not exist. | Check for typos or unwanted spaces, then suppress after confirmation. |
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. |
Quick interpretation of common SMTP bounces.
Microsoft wording matters
Microsoft's 550 5.7.1 guidance distinguishes recipient restrictions from routing and sender blocks. For a restricted group, ask its owner to permit the sender or approve the message. For a public folder that requires authenticated senders, the recipient administrator must review its delivery restrictions if external mail is intended. A recipient-side restriction needs a recipient-side configuration change.
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.
Flowchart for troubleshooting 550 5.7.1 and 554 bounces through receiver, IP, authentication, and content checks.
- Read the base reply code first. 2xx means a command succeeded; final acceptance follows message data. 4xx is temporary. 5xx is a permanent failure 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 means mailbox full. The base reply code still determines whether to retry automatically.
- Check the SMTP stage. A 554 greeting occurs before message content is available, so start with connection policy, IP reputation, or the destination server. 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. Wording such as user unknown, blocklist (blacklist), relaying denied, or authentication failed identifies the investigation. Connection timeouts without an SMTP reply belong to transport troubleshooting.
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 an invalid or permanently disabled destination, such as 550 5.1.1 user unknown. Check the address for typos, unwanted spaces, and a misspelled domain. A temporarily disabled or full mailbox needs separate handling; it is not proof of a nonexistent address.
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 can reject a connection, a recipient, or a completed message; the SMTP stage shows how far delivery progressed. 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. Use the provider's supported submission endpoint and method; do not enable unrestricted relay access.
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.
How to fix SPF, DKIM, and DMARC failures
When the rejection names authentication, check the exact sending service and domain used by the failed message. SMTP AUTH is a login check; SPF, DKIM, and DMARC are domain authentication checks. Publishing DNS records alone does not prove that this message passed.
- Check SPF at the envelope sender domain, normally shown in Return-Path on delivered mail. Publish one SPF TXT record at that name, authorize the actual sending service, and stay within the limit of 10 DNS-querying mechanisms and modifiers, including nested includes. Multiple SPF records or excess lookups produce permerror.
- Enable DKIM signing in the sending service. Check the d= signing domain and s= selector in DKIM-Signature, then verify the public key at selector._domainkey.signing-domain. A published key without a valid message signature is not a DKIM pass.
- Check DMARC alignment: at least one passing SPF or DKIM domain must match the visible From domain under the published matching mode. Relaxed matching allows the same organizational domain; strict matching requires identical domains. An unrelated provider domain can pass SPF and DKIM while the message fails DMARC.
- After DNS caches expire, send a controlled test through the same route and inspect the receiving server's Authentication-Results. Compare SPF, DKIM, and DMARC results with the failed route before resuming traffic.
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
The example shows a receiving server reporting successful authentication. DMARC needs one passing method with the required domain match; receiver requirements can separately demand both SPF and DKIM. Forwarding often breaks SPF, so check whether a matching DKIM signature survives. RFC 7208 defines SPF evaluation, and RFC 9989 defines DMARC. A DMARC pass does not override a reputation or content rejection.
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 by SMTP failure class and cause: recipient address, sender policy, routing, DNS, transport, or a later DSN. Keep the ESP label alongside the raw response rather than using it as the diagnosis.
- Group failures by receiving MX operator to distinguish a provider-wide incident from one recipient domain's policy.
- 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. |
Confirmed NXDOMAIN or null MX | Yes, after confirmation | Check address spelling and DNS. A null MX explicitly states that the domain accepts no mail under RFC 7505. |
No MX records alone | No | Check the domain's A and AAAA records. RFC 5321 permits an implicit MX fallback when no MX records exist. |
Mailbox full or recipient quota exceeded | No immediate removal | Retry 4xx with backoff; investigate 5xx before resending. Apply a documented hold policy for persistent recipient-specific failures. |
Generic 451 or 452 temporary failure | No, from the code alone | Use the diagnostic text to distinguish a mailbox quota from server storage or processing failures; retry with backoff. |
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. |
Authentication, TLS, sender DNS, or temporary resolver failure | No | Repair sender configuration failures; retry SERVFAIL or resolver timeouts with backoff before any suppression decision. |
Use reason-aware suppression instead of suppressing every 550 or 554 event.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
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.
Do not move to a dedicated IP solely because one shared pool produced a rejection. A dedicated IP gives you direct control of its reputation, but it needs regular volume, gradual warm-up, and ongoing monitoring. A well-managed shared pool is often more stable for low or irregular sending volumes.
A bounce that says Blacklisted by Internal Reputation Service is a private receiver reputation block even when public blocklist checks are clean. Group those failures by receiving operator, sending IP, and exact rejection token before opening tickets. For a named public blacklist, follow the removal instructions in the bounce only after correcting the cause of the listing; removal does not guarantee acceptance by every receiver.
Suped's blocklist monitoring helps the team track IP and domain listings alongside authentication evidence. Compare those results with the exact rejection text; a clean public blocklist result does not rule out a private receiver block.
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 550 5.7.1 and authentication rejection codes
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. Pause the affected stream, review complaints and recent volume changes, then resume with a small test after remediation.
If Gmail appends gcdp before gsmtp, treat it as a Google Workspace custom-domain policy path. The recipient domain administrator's rule belongs in the investigation even when the base code looks generic.
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 error reference lists 421 4.7.40 and 550 5.7.40 for missing DMARC records or policies. It lists 421 4.7.32 and the unusual 421 5.7.32 combination for From-domain matching failures. Preserve both codes as received: the base 421 controls automatic queue retries even when the enhanced code begins with 5.
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.
- 451 4.7.23 or 550 5.7.25: PTR or forward DNS.
- 451 4.7.24 or 550 5.7.24: suspicious SPF entries.
- 421 4.7.27 or 550 5.7.27: SPF failure.
- 421 4.7.29 or 550 5.7.29: missing TLS for bulk mail.
- 421 4.7.30 or 550 5.7.30: DKIM failure.
- 421 4.7.28 or 550 5.7.28: unusual sending rate, quota, unsolicited-mail pattern, or URL-domain pattern.
Gmail's sender guidelines require all senders to personal Gmail accounts to use SPF or DKIM, valid forward and reverse DNS, TLS, RFC 5322 message formatting, and a reported spam rate below 0.3%. Bulk senders at about 5,000 or more messages per day to personal Gmail accounts need both SPF and DKIM, DMARC with a policy such as p=none, From-domain matching for direct mail, and one-click unsubscribe plus a visible body link for marketing or subscribed mail. A p=none policy satisfies the published DMARC policy requirement; enforcement is a separate decision. Keep the reported spam rate below 0.1% and never let it reach 0.3%. Google's bulk-sender FAQ counts volume across the same primary domain and keeps bulk-sender status once that threshold has been met.
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.
For bulk mail to iCloud Mail, Apple's postmaster guidance requires SPF, DKIM, DMARC, reverse DNS, ARC headers on forwarded mail, standards-compliant messages, consistent sending identifiers, separated marketing and transactional streams, immediate unsubscribe, bounce handling, and periodic removal of inactive subscribers. Apple does not offer a bulk-sender allowlist. If failures continue after those checks, the mail administrator can contact icloudadmin@apple.com with the company name, sending domain, affected server IPs, exact SMTP errors, and when the issue began.
|
|
|
|---|---|---|
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's DMARC monitoring helps the team review sending sources and authentication failures during this investigation. Use it alongside the SMTP logs, since aggregate DMARC reports do not contain every rejection reason or prove inbox delivery.
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 this response: [Paste the full raw SMTP response for this incident] Context: - Start time and timezone: [value] - Recipient domain and receiving MX: [value] - Sending IP, IP pool, and outbound route: [value] - Provider message IDs and SMTP stage: [value] - Normal and incident bounce rates: [values] Please confirm: - who owns the sending IP and whether its pool is shared or dedicated - the HELO/EHLO name, PTR record, and forward DNS match - the visible From domain, envelope sender domain, and DKIM signing domain - authentication results observed by the receiver, and any required TLS result - whether the response identifies reputation, recipient permissions, routing, relay restrictions, content, authentication, DNS, or transport failure - the remediation owner, any provider escalation, and when to run a test
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; replace the example domain and reporting address with values you control. A p=none policy requests monitoring and does not repair SPF or DKIM. Move to quarantine or reject after reports show that legitimate sending sources pass with the required From-domain match. Strict domain matching is optional, not a required next step. Use Suped's DMARC reports to identify failing sending sources before changing enforcement.
- 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.
