What do bounce error messages 550 5.7.1 and 554 mean and how to resolve them?
Matthew Whittaker
Co-founder & CTO, Suped
Published 24 Jul 2025
Updated 24 May 2026
10 min read
Summarize with
A 550 5.7.1 bounce means the receiving server refused the message for a policy reason. In the example that says part of the sender's network is on a block list, the main problem is IP or network reputation, not the recipient mailbox and not ordinary SMTP login. A 554 bounce means the message was rejected by a security policy. That can be a local blocklist, blacklist, content filter, URL reputation issue, attachment rule, authentication failure, or tenant-specific gateway policy.
The fastest resolution path is to separate sender-owned problems from provider-owned problems. If the mail is going through a shared sending IP, the ESP or cloud mail provider usually controls the IP reputation and the remediation channel. If the domain, DKIM, SPF, DMARC, content, or recipient acquisition process is broken, the sender has work to do before asking the receiver to change anything.
- First read: the words after the SMTP code matter more than the code alone.
- First owner: shared IP blocks need the ESP's help because the sender cannot delist that network directly.
- First check: prove SPF, DKIM, DMARC, IP reputation, and message content before asking the recipient to allowlist mail.
- First fix: pause or slow the affected traffic while the sending path and reputation evidence are reviewed.
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; 554 Email rejected due to security policies.
For the first error, I would read the phrase part of their network is on our block list as the decisive clue. The receiver is saying the sending IP, or a wider network containing that IP, has a reputation problem. The enhanced status code 5.7.1 covers policy refusal, but the text tells you which policy fired.
For the second error, 554 is less specific. It says the receiving security layer refused the transaction. I treat it as a policy rejection until the receiving system gives a narrower reason. A 550 5.7.1 explainer is useful when the bounce only shows the enhanced code, but the exact text in your NDR is still the source of truth.
|
|
|
|
|---|---|---|---|
550 5.7.1 | Policy refusal, with the bounce text naming the real trigger. | Sender, ESP, or IP provider. | Check reputation and ask the ESP for logs. |
554 | Security policy rejection at the receiving side. | Receiver policy, ESP, or sender setup. | Compare content, auth, and recipient pattern. |
Quick interpretation of the two SMTP bounces.
Microsoft wording matters
Microsoft's 550 5.7.1 guidance covers multiple scenarios under the same enhanced status code. When the bounce says the network is on a block list, focus on sender reputation and provider escalation before changing random DNS records.
Why this is not usually SMTP authentication
SMTP authentication usually happens between your app and your outbound mail service. If the username, password, API key, or SMTP credential is wrong, the message often never leaves your sending platform. A receiver-side 550 5.7.1 or 554 rejection means the recipient's mail system saw the message and made a delivery decision.
That does not clear SPF, DKIM, and DMARC. It only changes the order of investigation. I first check whether the sending IP reputation is implicated, then I confirm authentication because failed DKIM or a domain mismatch can make policy filters stricter. A domain health check gives a quick view of the domain's SPF, DKIM, and DMARC posture before deeper log review.
SMTP login problem
- Where it fails: between your app and your own outbound mail service.
- Typical symptom: authentication denied, invalid credentials, or API key rejected.
- Log location: application logs, ESP event logs, or SMTP client logs.
- Fix path: rotate credentials, verify the sender identity, and resend a test.
Policy or reputation block
- Where it fails: at the recipient server or security gateway.
- Typical symptom: blocklist, blacklist, security policy, spam, or denied sender text.
- Log location: bounce logs, ESP delivery events, DMARC reports, and receiver response text.
- Fix path: repair reputation, authentication, 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 process
I do not start by changing DNS. I start by collecting the full NDR, the sending IP, the visible From domain, the envelope sender domain, the recipient domain, the sending platform, and the message type. One bounce to one protected domain is a different incident than the same bounce across many mailbox providers.
After that, I compare a failed message with a known good message from the same system. The useful differences are usually sender identity, DKIM selector, link domain, attachment, template, sending IP pool, and recipient source. If the failure began after a vendor change, a new template, or a new traffic source, that recent change gets priority.
A six-step flowchart for triaging SMTP bounce errors.
Triage checklist
- Classify: record the SMTP code, enhanced status code, and full receiver text.
- Identify: separate Microsoft, Google, corporate gateway, and private-domain failures.
- Map: connect each bounce to a sending IP, pool, DKIM selector, and template.
- Compare: test one plain text version and one normal version to isolate content rules.
- Escalate: send the ESP evidence, not a general request to improve deliverability.
A real message test helps because DNS-only checks do not show how the final message looks after the ESP signs it, rewrites links, adds headers, or chooses an IP pool. The email tester is useful here because you send an actual message and inspect the authentication and content signals together.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If the test message passes authentication but the same template bounces only at one organization, the next move is a receiver-specific escalation. If the test shows DKIM missing, SPF failing, or DMARC not passing, fix that before asking the recipient to adjust policy.
How to resolve 550 5.7.1 blocklist and blacklist bounces
When the bounce names a block list or blacklist, the first question is whether the sending IP is dedicated or shared. On a shared IP, another sender using the same network can damage the pool's reputation. The receiver does not care that your individual message is legitimate; it sees the IP and the current risk attached to that network.
A dedicated IP gives the sender more control, but it also removes the easy excuse. If that IP is listed, sending volume, complaint rate, old addresses, unexpected content, poor suppression, or a compromised integration has to be investigated. 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
For Microsoft-style S3150 blocks, the provider that controls the IP has the cleanest path to resolution. The sender should still prepare evidence: affected domains, timestamps, IPs, bounce samples, message IDs, and proof that the traffic source is legitimate.
- 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.
- Transactional mail: confirm it is separated from marketing traffic and uses stable identity.
- Block evidence: save the raw bounce text before it gets shortened in a CRM or help desk.
Do not start with allowlisting
Asking one recipient to allowlist your sender can restore one conversation, but it does not fix a reputation block. Use allowlisting only when the recipient confirms a local business rule caused the rejection. For broader SMTP 550 causes, treat the bounce pattern as evidence and fix the sender-side trigger.
How to resolve 554 security policy bounces
A 554 policy rejection needs more context because the same code can cover content, identity, and recipient gateway rules. I usually create four test versions: the original message, a plain text version, a version with links removed, and a version sent through the same domain but a different verified IP or pool if the ESP allows it.
That comparison tells you whether the receiver dislikes the sender, the IP, the content, or a specific link domain. If only the original fails, the content or URL set is suspect. If every version fails from one IP, reputation is more likely. If every version fails from one domain even on a clean path, authentication and domain reputation move to the top.
|
|
|
|---|---|---|
security policy | Gateway rule or reputation. | Plain text resend and ESP logs. |
spam content | Template or link domain. | Remove links and attachments. |
sender denied | Local block or blacklist. | Ask receiver for rule owner. |
auth failed | SPF, DKIM, or DMARC. | Inspect headers and DNS. |
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. Suped is the strongest practical DMARC platform for most teams because it turns DMARC data into source-level issues, real-time alerts, and concrete fix steps instead of leaving raw reports for someone to decode manually. Its DMARC monitoring also helps catch unknown senders, DKIM failures, SPF problems, and policy drift before they turn into recurring bounces.
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 the full pool, queue behavior, complaint signals, retry patterns, and provider-specific feedback. A vague ticket slows things down, so I include the smallest useful evidence bundle.
The ticket should ask for ownership and next steps, not just a definition of the bounce code. If the ESP confirms a pool-level issue, ask what mitigation is already underway and whether your traffic can move to another pool only after the sender setup has been checked.
ESP escalation templatetext
We are seeing hard bounces with these responses: 550 5.7.1 network is on our block list (S3150) 554 Email rejected due to security policies Please confirm: - the sending IP and IP pool for each message ID - whether the pool is shared or dedicated - whether this IP range has a known reputation issue - whether SPF, DKIM, and DMARC passed at handoff - what remediation or provider escalation is in progress
Evidence to include
- Bounces: full raw NDR text, not a shortened CRM status.
- Message IDs: provider message ID, campaign ID, and timestamp with timezone.
- Domains: visible From domain, envelope sender domain, and link tracking domain.
- Scope: how many recipients, which recipient domains, and when the failures began.
How to stop the same bounces returning
After the immediate block is handled, I 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, or a template that looks automated and lacks clear context for the recipient.
For marketing or lifecycle mail, the recurrence drivers are usually list quality, stale recipients, sudden volume spikes, and sender identity drift. Technical authentication will not rescue mail that recipients did not expect, but broken authentication makes wanted mail harder for receivers to trust.
Starter DMARC recordtext
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
The record above is only a starter. Move policy carefully after reports show that legitimate senders pass. 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 hard bounces immediately and reduce mail to unengaged recipients.
- Traffic separation: keep critical transactional mail away from bulk or experimental sends.
- Alerting: monitor rejection spikes by provider, IP, source, and authentication result.
Views from the trenches
Best practices
Preserve raw bounce text before ticketing so the exact provider wording is not lost.
Separate shared IP incidents from sender-domain issues before changing DNS records.
Test the same message with links removed to isolate content rules from IP reputation.
Common pitfalls
Treating every 550 5.7.1 as an auth failure wastes time when the IP is already blocked.
Asking a recipient to allowlist mail before checking shared IP reputation is weak.
Opening ESP tickets without IPs, timestamps, and message IDs slows investigation.
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 rules.
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 or blacklist needs reputation investigation and usually ESP involvement, especially on shared IPs. A 554 security-policy bounce needs a comparison of content, sender identity, authentication, IP, and recipient-side rules.
I would not assume SMTP authentication is the root cause unless the logs show a credential failure before handoff. Start with the full bounce text, identify the owner of the sending IP, 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.
