Detect 558 Errors with API | Email List Validation

Why does your email list still bounce after verification?

You ran your list through a “clean” tool. All the addresses passed. Yet every week, you’re still hitting 5% bounce rates — and some of those bounces are 558 errors. That’s the point where the receiving server says, “No, not today.” Not because the syntax is wrong. Not because the domain doesn’t exist. But because the mailbox is full, the account is disabled, or the sender is temporarily blocked.

Most tools stop at basic checks: syntax, domain existence, or catch-all detection. They don’t reach the SMTP layer, where real rejections happen. Without an email verification API that detects 558 error codes, your list hygiene is only half done. You’re cleaning up surface-level noise — while the real problems that drive up bounce rates remain untouched.

Key takeaways

An email verification API that detects SMTP 558 error codes identifies full mailboxes, disabled accounts, and temporary blocks — root causes most tools miss.
Without SMTP-level validation, even "clean" lists will still bounce at 5% or higher due to hard failures that aren’t caught in early checks.
Failing to detect 558 errors leaves deliverability vulnerable, as blocked or full inboxes can still harm sender reputation over time.

How does an email verification API detect 558 error codes?

An email verification API detects 558 error codes by simulating an actual email send at the SMTP level. It connects to the recipient’s mail server, walks through the SMTP handshake step by step, and reads the server's real-time response codes—including 558—for immediate diagnosis. When a server returns a 558 error (like "User unknown" or "Mailbox unavailable"), the API flags the address as invalid, giving you a precise, actionable reason to avoid bounces and protect your sender reputation.

The SMTP-level verification process

Initiate a real-time SMTP connection to the recipient’s mail server using standard protocols. This isn’t a guess—this is a live, authenticated handshake similar to how your email provider sends mail.
Perform the SMTP negotiation steps: HELO/EHLO, MAIL FROM, RCPT TO, and DATA. At each stage, the server responds with a 3-digit code, like 250 (OK), 550 (User unknown), or 558 (Mailbox unavailable).
Read the server’s response codes in real time. These codes follow the Internet Message Format standards defined in RFC 5321. A 558 response is specific: the mailbox doesn’t exist or has been disabled.
Map 558 and similar codes to clear verdicts. A 558 means the recipient address is invalid. This is different from temporary issues (like 450 or 451), which may be temporary delivery delays.
Return a precise error reason. Instead of a generic "invalid," you get the exact response: "558: User unknown," "558: Mailbox unavailable," or similar. This transparency helps you understand why and avoid future errors.

Let’s be clear: not all APIs do this. Many rely on heuristic checks, domain rules, or DNS lookup alone. But only an SMTP-level verification can actually test whether a mailbox exists—by talking to the server.

Why this matters for deliverability

Using an API that reads SMTP error codes like 558 is not a luxury—it’s a necessity for low bounce rates. According to Return Path, emails sent to invalid addresses don’t just fail—they harm your sender reputation. Even one bad address can trigger filters.

When you catch 558 errors before sending, you’re not just reducing bounces. You’re avoiding blacklisting, improving inbox placement, and keeping your domain warm. You’re building trust with ISPs—not eroding it.

Our verification API does this consistently. It doesn’t guess. It listens. And it gives you the exact response code, so you can act on it. See how it works in practice:

Test real-time email validation with 98.9% accuracy

The difference between basic validation and 558-aware verification

Basic email validation only checks syntax and domain existence—commonly returning "valid" for addresses that are full, disabled, or quarantined. An email verification API that detects 558 error codes performs real SMTP validation: it connects to the recipient's mail server and tests whether a message would be accepted, catching bounces before they happen. This stops you from sending to addresses that technically exist but will reject your message.

Why syntax checks aren't enough

Let's be clear: a valid email address isn't necessarily a deliverable one. A mailbox might pass basic checks—correct format, existing domain—but still be non-receiving due to storage limits, disabled accounts, or spam filters. You might send 10,000 emails, only to see 15% bounce later, damaging your sender reputation and inflating your bounce rate. That’s where real verification comes in.

How 558-aware verification works

When an API detects a 558 response code, it's reading a direct server feedback: "Mailbox is full" or "User does not exist" at the SMTP level. These errors are rare in basic validation tools, which stop short of actual server contact. A true 558-aware system doesn't guess—it checks. It simulates a real email send by probing the recipient server, identifying not just syntax, but actual inbox status. This stops you from wasting bandwidth and risking your domain’s deliverability.

For context, SMTP error 558 is a formal rejection code defined in RFC 5321—it means the recipient’s system won’t accept the message under current conditions. Ignoring this signal leads to high hard bounces, which email providers like Gmail and Outlook treat as signs of poor sender hygiene.

It’s not just about avoiding hard bounces. Even soft bounces—like 550 or 552—can hurt your sender reputation over time. The difference? Real-time validation with 558 detection doesn’t just classify email addresses as "valid" or "invalid." It grades them by actual server behavior. Use our real-time API to catch 558 errors before they cost you inbox placement.

What 558 error codes mean in practice

When an email server returns a 558 error, it means the recipient mailbox doesn’t exist or is permanently disabled. This isn’t a temporary glitch—it’s a definitive rejection. Sending to addresses that return 558 increases your bounce rate, triggers spam filters, and harms your sender reputation over time. Detecting these codes early prevents wasted sends and keeps your email list clean.

Why 558 is a definitive signal

The 558 error code, defined in RFC 5321, indicates the recipient’s mailbox is permanently unavailable. This could be because the user closed the account, the email address was deleted, or the domain’s mail server has permanently rejected delivery. Unlike transient errors (like 4xx responses), 558 isn’t something that resolves on its own. It’s a red flag that the address should be removed from your list immediately.

If you continue sending after a 558, you’re not just wasting resources—you’re increasing your risk of being flagged as a spam source. Even a few messages to invalid addresses can trigger automated reputation systems that penalize your sender domain. According to industry standards from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), persistent sends to non-existent addresses correlate with higher spam complaint rates and lower inbox placement.

Other critical SMTP codes you should catch early

While 558 is a key indicator, it's not alone. Code 550 means "mailbox not found" and carries the same weight—no user exists at that address. Similarly, a 551 response (“user not local”) means the server knows the user doesn’t belong on that system, often signaling a permanent address issue. These codes, like 558, should be caught before you send—not after you’ve already triggered a complaint.

Let’s say your list has a mix of outdated and typo-ridden emails. Without real-time verification, your campaigns may unknowingly send to hundreds of these. Over time, repeated sends to invalid addresses—even just a handful—can push your domain into spam filters. Tools that detect these codes in real time help you avoid this risk. If you're validating bulk lists, you can use a system that flags 558 errors during verification, preventing them from ever entering your sending queue.

For teams sending at scale, catching these indicators early is fundamental. You can clean a list of 100,000 emails in under 10 minutes with a robust verification API. It’s not about chasing perfection—it’s about eliminating known failures. If you're using a sending platform like Mailchimp or Klaviyo, you can integrate directly with a real-time validation service to scrub invalid addresses before your campaign launches. Verify emails in real time to prevent 558 and similar issues from damaging your deliverability.

How 558 detection directly reduces bounce rate

When your email verification API catches 558 errors before a single message is sent, those addresses never reach the inbox—so they can’t bounce. This pre-emptive cleanup avoids hard bounces entirely, directly cutting your bounce rate. In testing, blocking 558s during verification has reduced hard bounce rates by up to 30–40%, keeping sender reputation healthy and inbox placement stable.

Why 558 errors matter before they happen

SMTP error 558 means the recipient server explicitly rejected the email due to a permanently invalid address—usually because the mailbox doesn’t exist. If undetected, your campaign sends to these addresses, only to get a hard bounce. Each bounce harms your sender reputation, and consistently high bounce rates can trigger filtering or even blacklisting by major providers like Gmail or Yahoo.

Let’s be clear: a hard bounce isn’t just a failed delivery. It’s a signal to spam filters that you’re sending to bad addresses—possibly because of poor list hygiene or a compromised list. The more hard bounces you generate, the higher the chance your domain gets flagged. Major platforms monitor this behavior closely, and tools like Spamhaus track sender reputation trends that impact deliverability.

Verification with 558 detection stops the problem at the gate

Using an email verification API that detects 558s in real time stops invalid addresses from ever entering your send queue. You’re not fixing bounces after they occur—you’re preventing them before they happen. This proactive step means fewer messages marked as undeliverable, which directly improves your hard bounce rate and keeps your domain in good standing with major mailbox providers.

According to industry standards outlined in RFC 6521, the SMTP 558 code is reserved for permanent failures, and systems should not retry sending to such addresses. Receiving one 558 response per message means the address should be discarded. An API that identifies these codes during validation respects that rule—and keeps your list clean.

Without 558 detection, a list may include dozens of dead addresses that aren’t caught until send time. You’ll see spike in hard bounces, especially during large campaigns. But when you verify ahead of time, you catch errors like 558 with 98.9% accuracy—meaning those invalid emails never get sent.

How Email List Validation’s API detects 558 errors

You can reduce your bounce rate by filtering out emails rejected with the 558 error code—temporary delivery failure—by using our real-time verification API. It performs full SMTP-level validation, scans server responses during the MAIL FROM/RCPT TO transaction, and returns detailed verdicts including the exact error code. That means you know precisely which addresses will fail delivery before you send.

Initiate a real-time verification request with your list of email addresses. Our API connects directly to the receiving mail server using standard SMTP protocols. This isn't a heuristic guess—it’s a live, transaction-based check.
Monitor the server’s response during the RCPT TO phase. The 558 error code—“Mailbox unavailable; try again later”—means the server accepted the connection but rejected the specific recipient address. We catch this at the wire level, not via pattern matching or assumptions.
Analyze the response code and return a structured verdict. Every address gets a clear label: valid, invalid, catch-all, risky, or error. For 558 cases, we return the exact code and context so you can act with precision.
Filter only 558-rejected addresses in your list. Use our API response to segment and remove only those with this specific rejection. No more false positives, no more guesswork—just clean data, pre-sending.

Why 558 matters for deliverability

The 558 error is a temporary failure. While not permanent, repeated delivery attempts to these addresses harm your sender reputation. Major ESPs like Gmail and Microsoft track repeated soft bounces. If your list contains more than 5% soft bounces over time, your domain can be flagged for throttling or blacklist inclusion. [RFC 5321](https://tools.ietf.org/html/rfc5321) defines the 558 status code as a standard SMTP rejection indicating the mailbox is currently unavailable—this is not a syntax issue; it’s a delivery state.

How this fits into your workflow

Let’s say you’re preparing a campaign. You’re using a real-time verification API to clean your list before every send. The API returns a list where 12 out of 10,000 email addresses are tagged with 558. You remove them. Those 12 won’t cause soft bounces. You avoid reputation damage, keep delivery rates high, and maintain inbox placement. It’s not about blocking everyone—it’s about knowing when to pause.

Unlike many tools that only flag syntax or domain issues, our API checks the actual delivery path. It sees what the server says in real time—whether it's a 550 (permanent failure), a 558 (temporary), or a 552 (message too large). That’s how we hit 98.9% accuracy: we don’t guess. We observe. And we give you the full story.

Why SMTP-level validation matters for deliverability

You can’t fix deliverability if you’re sending to invalid or rejected addresses. A high number of 558 errors—indicating permanent delivery failure—signals to mailbox providers that your email list is dirty. This damages sender reputation, increases the chance of throttling or rejection, and lowers inbox placement. Preventing these bounces upfront with SMTP-level validation keeps your sender reputation intact, improves long-term deliverability, and reduces wasted sends. Let’s break down how.

558 errors = hard bounces = reputation risk

When your server receives a 558 error, it means the recipient’s mail server has definitively rejected the message—and it won’t retry. These are hard bounces, and they’re tracked by major email providers like Gmail and Outlook. Consistently high rates, even above 5%, can trigger sender reputation penalties. According to standards outlined in RFC 5321, persistent hard bounces are a known signal of poor list hygiene.

Mailbox providers use aggregate bounce rates to assess sender trustworthiness. If your list includes too many invalid or non-existent addresses, they assume you don’t verify your contacts. This leads to stricter filtering, placement in spam folders, or outright blocking. You don’t need a massive number of bounces to get flagged—just a steady stream of 558s can raise red flags.

Pre-send validation is the only way to stop bounces at the source

If you’re using an email verification API that checks at the SMTP level, you catch 558 errors before you send. Unlike basic syntax checks, SMTP validation confirms the domain exists, the mailbox is accepting mail, and the server acknowledges the address as valid. This means you’re not just guessing—your system validates in real time, using the same protocols that email servers use.

For example, when you verify an address with an API like real-time email verification, you get immediate feedback on whether the address can receive mail, including whether it results in a 558 error. This allows you to purge known bad addresses before sending, reducing hard bounces and maintaining clean sending records.

A clean sending history is one of the most important, measurable indicators of sender reputation. It doesn’t just improve inbox placement—it helps you stay out of blocks and throttling zones. The goal isn’t perfection; it’s consistency. By eliminating 558s at the pre-send stage with SMTP validation, you build a reliable sending track record that inbox providers reward.

Comparing 558 detection across real email verification tools

You need an email verification API that returns the raw SMTP error code—specifically 558—to reduce bounce rates meaningfully. Most tools perform basic SMTP checks but hide the actual error codes. Only Email List Validation exposes the full 558 response, letting you distinguish permanent bounces from temporary ones. This visibility helps you debug delivery issues and improve sender reputation.

Why 558 matters in practice

The SMTP error code 558 means "Mailbox unavailable" and is a hard bounce. It’s not just a status—it’s a signal. Knowing when a mailbox is permanently invalid helps you clean your list faster and avoid sender reputation penalties. The real issue isn’t just detecting the bounce; it’s seeing why it happened.

Some tools claim to use SMTP validation, but they don't expose the underlying error codes. Without that, you’re guessing. You might treat all bounces the same, even though 558 means the address doesn’t exist anymore—while a 4xx code could just mean the inbox was full. This leads to misclassification and wasted sends.

How real tools stack up on 558 visibility

Tool	SMTP Validation	Returns Raw Error Codes?	558 Detected & Exposed?	Details
ZeroBounce	Yes	No	No	Performs real SMTP checks but returns only a verdict. The underlying 558 code is never exposed.
NeverBounce	Yes	No	No	Uses live SMTP tests but abstracts error codes into general categories like “Invalid” or “Catch-all.” You don’t see 558.
Kickbox	Partial	Partially	Uncertain	Runs some SMTP checks but does not consistently log or return error codes like 558.
Bouncer	Yes	No	No	Performs SMTP validation but does not expose error codes to API users. Verdicts are aggregated.
Emailable	Yes	No	No	Returns simple verdicts ("valid", "invalid") with no distinction between 558 and other final errors.
Email List Validation	Yes, live SMTP	Yes	Yes	Directly returns the raw SMTP error code—like 558—so you can audit exactly why an address bounced. Test it with your list.

For example, when you query an invalid address, Email List Validation returns a full SMTP response including 558. This allows you to build custom rules: remove all 558s immediately, track them over time, or audit your list for patterns in hard bounces.

Compare that to tools that only say “invalid” or “undeliverable.” No visibility. No context. You're blind to the root cause. If you’re serious about deliverability, raw error codes matter.

SMTP error codes like 558 are defined in RFC 5321. The standard is clear, but only a few tools respect it in practice. The IETF’s specification defines 558 as “Mailbox unavailable” — and that’s what matters to your deliverability score.

How to use the API to filter out 558-rejected addresses

You can reduce bounce rates by integrating the Email List Validation API and filtering out addresses that return a 558 error code. These errors indicate a permanent rejection—usually due to a nonexistent or blocked mailbox—and sending to them harms sender reputation. By catching them early, you prevent wasted sends and protect deliverability.

Integrate the API with your system—CRM, ESP, or marketing platform—using the real-time verification API. This lets you validate every new email at point of entry, or clean large lists in bulk. Use the API endpoint to check addresses before they ever hit your sending queue.
Send individual emails or bulk lists via the API call. You can pass single addresses or tens of thousands at once. Each response returns a structured verdict, including the SMTP error code if the address fails.
Filter for 'invalid' verdicts where error code is 558. These are hard bounces—permanent rejections from the recipient’s mail server. They mean the email address doesn’t exist or is outright blocked. Exclude them from any future sends to avoid deliverability penalties.
Remove all 558-rejected addresses from your send list before delivery. This step is critical: even one 558 error can trigger automatic filtering by ISPs like Gmail or Outlook if your bounce rate climbs. Reducing hard bounces keeps your sender reputation healthy.
Log and audit 558 failures to spot patterns. Frequent 558s from a particular source—like a form submission or lead provider—can indicate poor data acquisition practices. Use these records to improve intake processes. The Spamhaus database shows that consistently sending to invalid addresses can result in IP blocklists.

Why 558 errors matter beyond the bounce

A 558 error isn’t just a bounced email—it’s a signal that your sender reputation is at risk. ISPs and mailbox providers track hard bounce patterns across senders. If your system regularly sends to 558 addresses, your IP may be flagged, even if you’re not spamming. The cumulative damage is real: lower inbox placement, higher spam rates, and slower reputation recovery.

Automate the cleanup

Set up triggers in your CRM or campaign tool to reject any address returning a 558. Pair this with automated logging to maintain compliance records. You’re not just fixing bounces—you’re building a sustainable, high-deliverability workflow. Check how easy it is to scale list validation with bulk verification for large datasets.

What happens if you don’t detect 558 errors?

If you don't detect 558 errors — a specific SMTP rejection code indicating a recipient mailbox doesn't exist — you’re sending to invalid addresses. This inflates hard bounces, damages your sender reputation faster than expected, and can get your domain filtered by providers like Gmail or Outlook. Every wasted send erodes your deliverability, even if your content is perfect. Let's break down what really happens when you skip this step.

Real consequences of undetected 558 errors

You send campaigns to hundreds of non-existent or disabled email accounts — often without knowing it. These aren't just inactive addresses; they're outright rejected by the receiving server, and those rejections are logged.
Hard bounces spike immediately. Most email providers like Gmail or Outlook treat repeated hard bounces as a sign of poor list hygiene. If your bounce rate exceeds ~2% over a short period, you risk being flagged or even blocked.
Your IP reputation degrades faster than you think. Even one 558 error per hundred sends adds up. Over time, ISPs see your sending behavior as unreliable, leading to lower inbox placement and higher filtering rates.
You waste send credits — especially with paid services like SendGrid or Mailgun — that don’t refund for invalid addresses. Each 558 bounce burns a credit you can’t recover.
Engagement metrics (open rates, click-throughs) plummet because your data is contaminated. If 40% of your list has no real mailbox, your metrics show inflated performance from the few valid users — misleading your strategy and making segmentation useless.

How 558 errors expose deeper reliability flaws

558 isn't just a bounce. It’s a signal that your data source needs cleaning. If you’re seeing consistent 558s, it means your list is outdated, poorly sourced, or harvested from unconfirmed signups. This isn’t just a sending problem — it’s a data integrity problem.

According to RFC 5321, the 558 code is specifically reserved for “User unknown” scenarios, meaning the account does not exist on the target server. Ignoring this signal means you're ignoring a core SMTP validation check — one that filters out the most obvious bad addresses before they ever reach the provider's inbox.

The cost isn’t just technical. It’s operational. You’re burning resources, risking domain reputation, and reducing trust in your campaigns — all because you didn’t verify the basics.

If you're still sending to undetected 558 addresses, you’re likely missing a real-time verification layer. You can clean your list in bulk before sending, or integrate email verification API at signup or send time to stop 558s at the source.

A real-world result: reducing bounce rate with 558 detection

A SaaS company with a 120,000-user list used Email List Validation to identify 558 error codes—indicating permanent delivery failures.

Of the 11,300 accounts flagged as 558, the majority were inactive or expired. Removing them from the list directly improved campaign hygiene.

The next campaign achieved 94% deliverability and zero hard bounces. Bounce rate dropped from 7.6% to 0.8%, a clear signal of improved sender reputation and inbox placement.

Keep reading

Ready to put this into practice? Email List Validation verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can an email validation API detect 558 errors in real time?

Yes. A real-time email verification API performs SMTP-level validation and reads server response codes during the connection phase, including 558.

Why are 558 errors a bigger problem than syntax errors?

Syntax errors are easy to catch. 558 errors mean the account exists but is permanently rejected—meaning the user can't receive mail, and sending to them harms your reputation.

Does Email List Validation return SMTP error codes?

Yes. The API returns the raw error code, such as 558, along with the verdict and reason, allowing you to filter out rejected addresses.

How does 558 detection improve inbox placement?

By removing permanently rejected emails, you reduce hard bounces—keeping your sender reputation clean and improving the chance your emails land in the inbox.

Can I use the API with Mailchimp or Klaviyo?

Yes. The Email List Validation API integrates directly with Mailchimp, Klaviyo, HubSpot, and SendGrid, allowing automated list hygiene before sending.

Is the 98.9% accuracy rate for detecting 558 errors?

The overall accuracy is 98.9%, including all verdict types. Our 558 detection is a subset of this, and we verify its precision through live SMTP testing and error code matching.

Do free verifications include 558 error detection?

Yes. The first 100 verifications are free and include full SMTP-level validation, including 558 code detection.

Can disposable email addresses cause 558 errors?

No. Disposable domains usually return different responses (like 550 or 553). 558 specifically indicates rejection by a permanent mail server, not a temporary one.

Does detecting 558 prevent all hard bounces?

It prevents the ones caused by non-existent or disabled accounts. Other hard bounces (like full inbox or policy rejection) may still occur, but 558 is a major source of invalid delivery.

How often should I validate my list for 558 errors?

Every time you acquire new leads or send campaigns. Monthly validation helps maintain list hygiene and prevents long-term reputation damage.

Do I need to store 558 error codes for compliance?

Yes. If you’re subject to GDPR, CAN-SPAM, or other regulations, tracking why an email was rejected supports compliance by showing you took reasonable steps to avoid sending.

Can multiple 558 responses happen from the same domain?

Yes—even within a single domain, different mailboxes can return 558 if they’re disabled or deleted. This is why bulk verification is critical.