What does the Vade Secure OXSUS0001_403 error code mean and how should it be handled?
Published 29 May 2025
Updated 22 Jul 2026
11 min read
Summarize with
Updated on 22 Jul 2026: We corrected the Vade _403 response, separated it from _406 syntax failures, and tightened the suppression and escalation steps.
OXSUS0001_403 is a Vade recipient rejection code. Vade currently documents it as 550 5.5.1 Recipient rejected, which means the mailbox does not exist on the receiving system. Treat it as a hard bounce and stop automatic delivery attempts to that address.
Do not confuse _403 with Vade's _406 code. The _406 response covers an invalid recipient address format, while _403 says the receiving system has no mailbox for the recipient. The full provider code and bounce text matter because the operational fixes are different.
For bulk mail, place the address on the suppression list after one confirmed _403 response. For transactional mail, stop retries to the address, retain the account, and ask the user to provide or confirm a working address. Escalate only when recent successful deliveries to the exact same address conflict with the rejection.
The short answer
The Vade Secure OXSUS0001_403 code means the receiving mail system rejected the recipient because the mailbox does not exist there. Vade maps the inbound _403 suffix to a permanent SMTP failure shown as 550 5.5.1 Recipient rejected. It is an unknown-recipient hard bounce, not a temporary deferral or an invalid address-syntax response.
Vade's OX Postmaster page is the place to verify OXSUS codes found in raw logs. Match the complete suffix and response text before choosing a handling path, because nearby recipient codes describe different problems.
Do not retry OXSUS0001_403 as though it were a temporary 4xx deferral. The 550 response is permanent, and repeated attempts to an unknown recipient add avoidable hard bounces.
- Bulk mail: Suppress the recipient after the confirmed 550 _403 failure and retain the raw bounce.
- Transactional mail: Stop automatic retries, keep the account intact, and request a corrected address.
- Syntax cases: Look for Vade _406, then inspect the exact envelope recipient sent in RCPT TO.
- Conflicting history: Escalate when the exact address has both recent acceptances and _403 rejections.
Documented OXSUS0001_403 bounce shapetext
550 5.5.1 Recipient rejected - OXSUS0001_403 This mailbox does not exist here. Classification: permanent recipient failure Bulk handling: suppress the recipient
How to read the complete rejection
Keep the complete SMTP reply instead of storing only `550` or a generic hard-bounce label. The basic status, enhanced status, human-readable text, and Vade suffix each carry different diagnostic detail. For this response, the provider suffix and Vade's current postmaster mapping give the actionable meaning: the mailbox does not exist.
|
|
|
|---|---|---|
SMTP status | 550 | Permanent failure |
Enhanced status | 5.5.1 | Permanent protocol-class response |
Response text | Recipient rejected | Failure occurred for the recipient |
Vade suffix | _403 | Mailbox does not exist here |
Parts of a Vade OXSUS0001_403 rejection.
The numeric layers should be preserved exactly even when the enhanced status looks less specific than the provider explanation. Do not rewrite the event as 5.1.1 or 5.7.1 in logs. Store what the receiving server returned, then classify it using the documented _403 meaning.
How _403 differs from _406
Vade assigns separate inbound codes to an unknown mailbox and an invalid recipient format. OXSUS0001_403 identifies a mailbox that does not exist on the receiving system. The related _406 suffix identifies a recipient address whose format is invalid. Reading only `Recipient rejected` can hide this distinction.
Screenshot-style view of OX Postmaster by Vade showing the OXSUS0001_403 code.
This matters because the fixes are different. An unknown mailbox requires bounce suppression or an address update. Malformed syntax requires correction in the sending system, imported data, merge logic, or address parser. Classifying _403 as a syntax problem keeps an invalid recipient active, while classifying _406 as an unknown mailbox can suppress a valid person whose address was transmitted incorrectly.
OXSUS0001_403: mailbox absent
The receiver says it has no mailbox for the recipient. Handle the response as a permanent unknown-recipient hard bounce.
- List action: Suppress the recipient from bulk sends.
- CRM action: Mark the address undeliverable and retain the raw bounce.
- Retry action: Retry only after the recipient supplies a corrected address.
OXSUS0001_406: format invalid
The receiver rejected the recipient address format. The mailbox can be real, but the envelope value sent over SMTP is invalid.
- Data action: Compare stored data with the exact RCPT TO value.
- System action: Check merge fields, hidden characters, quoting, and parsing.
- Retry action: Retry only after correcting the generated recipient value.
The regional OXSEU code family uses the same inbound mapping: _403 means the mailbox does not exist, while _406 means the recipient address format is invalid. Still retain the complete regional prefix and full response in the bounce record.
What to check before suppressing the address
For a clean suppression record, capture the raw bounce, envelope recipient, sending IP, message stream, and recent recipient history. The visible To header is not enough because the SMTP transaction uses the envelope recipient. History does not turn a 550 into a temporary error, but it can expose recycled mailboxes, routing changes, or a receiving-side inconsistency that needs escalation.
- Raw bounce: Capture the full SMTP response, including the regional OXSUS or OXSEU prefix and _403 suffix.
- Envelope recipient: Compare RCPT TO with the address stored in your application and suppression system.
- Recipient history: Look for accepted deliveries to the exact address before the rejection.
- Stream type: Separate bulk mail from account, password reset, invoice, and other transactional mail.
- Code check: Confirm the suffix is _403 rather than the syntax-related _406 or a temporary 4xx response.
SPF, DKIM, and DMARC do not cause the documented _403 mailbox-not-found response. Check authentication when failures extend across many recipients or begin after a sending-source change, but do not delay recipient suppression while investigating an unrelated authentication issue.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The domain health checker checks the domain's DMARC, SPF, and DKIM posture. It cannot confirm whether a recipient exists, so use it as a secondary check when the rejection pattern suggests a broader sending-domain problem.
|
|
|
|---|---|---|
Confirmed _403 | Mailbox does not exist | Suppress |
Code _406 | Recipient format is invalid | Fix data |
Recent success | Evidence conflicts | Suppress and escalate |
Temporary 4xx | Delivery is deferred | Retry on schedule |
Many domains | Pattern is broader | Check reputation |
Compact decision checks for OXSUS0001_403 handling.
How to decide whether to retry, suppress, or escalate
Treat a 550 OXSUS0001_403 as a permanent recipient failure. The sending system should stop automatic attempts to that address after the first confirmed response. Suppress it for bulk mail, and place transactional delivery into an undeliverable state that prompts the user or account owner to update the address.
Flowchart for deciding how to handle an OXSUS0001_403 rejection.
For bulk mail, suppression protects list hygiene and prevents repeated delivery to a recipient the receiver identifies as nonexistent. For transactional mail, preserve the user account and the event history, but do not keep sending password resets, invoices, or notices to the rejected address. Ask for a new address through an authenticated in-app or support workflow.
OXSUS0001_403 handling thresholds
A practical way to choose the action based on the response and supporting evidence.
One confirmed _403
1 event
Stop automatic attempts and suppress the address for bulk mail.
Transactional recipient
review
Block delivery to the address and request an address update without closing the account.
Success and failure together
mixed
Keep suppression in place and escalate with timestamps and SMTP logs.
Code _406
syntax
Fix the generated recipient format before retrying.
Retry only after the recipient address changes or the receiving provider confirms that the rejection was wrong. A recent successful delivery is evidence for escalation, not permission for repeated automated retries. Send one controlled test only after the contradiction has been investigated.
Escalation evidence to collecttext
Recipient: user@example.com Sending IP: 203.0.113.10 Envelope sender: bounce@example.com Envelope recipient: user@example.com Timestamp UTC: 2026-07-22T03:14:00Z SMTP reply: 550 5.5.1 Recipient rejected - OXSUS0001_403 Recent accepted delivery: 2026-07-22T02:57:00Z Message stream: transactional password reset
Where Suped fits in the workflow
Suped is our DMARC and email authentication platform. It does not replace Vade's bounce reason or verify that a mailbox exists. It helps investigate the parts under the sender's control, including which source sent the affected traffic, whether that source passed authentication, and whether a broader reputation issue appeared at the same time.
A practical investigation connects the raw _403 events with Suped's DMARC source data, SPF and DKIM results, alerts, and blocklist monitoring. That separation keeps a recipient-specific hard bounce from being misdiagnosed as a DNS failure while still exposing an authentication or blacklist problem affecting other mail.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
When _403 bounces rise after a sending change, use Suped to identify the source, confirm DMARC alignment, and check whether the pattern extends beyond unknown recipients. The bounce platform should remain the system of record for recipient suppression, with Suped supplying domain-level authentication and source evidence.
Connect bounce processing with authentication monitoring, but keep their conclusions separate. Every suppression decision should point to the raw recipient rejection, while domain-level findings should point to the relevant sending source.
- Bounce action: Use the raw _403 event to suppress the recipient.
- Source check: Use Suped source views to identify the system behind the traffic.
- Authentication check: Review SPF, DKIM, and DMARC results when the problem is broader.
- Reputation check: Review blocklist or blacklist data when unrelated domains also reject mail.
Why this is not a blocklist entry
OXSUS0001_403 is not a blocklist or blacklist code. Vade documents it as an unknown-mailbox response. Vade uses other inbound codes for sending IP blocklist entries, so do not start a delisting request based on _403 alone.
Check blocklist monitoring only when the evidence expands beyond individual nonexistent recipients, such as simultaneous rejections across unrelated domains after an IP change. A blacklist listing can coexist with invalid-recipient bounces, but it does not change the meaning of the _403 event.
Recipient problem
- Scope: Individual mailboxes or an imported segment fail.
- Pattern: Failures carry 550 5.5.1 and the Vade _403 suffix.
- Action: Suppress or replace the rejected recipient address.
Sender reputation problem
- Scope: Many unrelated domains reject mail after a shared sending change.
- Pattern: Replies mention an IP, policy, threat list, blocklist, or blacklist.
- Action: Investigate reputation and the exact code before seeking removal.
The blocklists guide is the next step only when the bounce evidence points to sender reputation. To inspect a controlled message path, use the email tester and compare its authentication results with the production event.
For general SMTP context, the guide on SMTP error codes explains how to retain the numeric SMTP status, enhanced status code, and provider-specific text as separate parts of the bounce.
Views from the trenches
Best practices
Treat a confirmed Vade _403 response as a hard bounce and suppress bulk recipients.
Keep the full provider suffix so _403 cannot be confused with syntax-related _406.
Save raw SMTP replies with timestamps, sending IPs, streams, and recipient domains.
Common pitfalls
Do not close a user account merely because its transactional email address bounced.
Do not diagnose _403 as malformed RCPT TO data; Vade assigns that issue to _406.
Do not retry permanent 550-class recipient failures without a corrected address.
Expert tips
Compare accepted and rejected events for the exact address before escalating _403.
Send the complete rejection and timestamps when asking the receiving side to review.
Check authentication and blacklist signals only when failures span many domains.
Marketer from Email Geeks says nearby Vade recipient codes need different handling, so keep the provider suffix and complete bounce text.
2021-05-24 - Email Geeks
Marketer from Email Geeks says bulk mail should treat an unknown-recipient response as a suppression event, while account status needs separate review.
2021-05-24 - Email Geeks
The practical handling rule
Handle OXSUS0001_403 as a permanent unknown-recipient rejection. For bulk mail, suppress the address after the first confirmed response and preserve the bounce. For transactional mail, stop delivery to the address, keep the account intact, request an address update, and escalate only when delivery history conflicts with the rejection.
Keep _403 separate from _406 and from blocklist or blacklist responses. That distinction prevents blind retries, unnecessary delisting work, and suppression of a valid recipient whose address was transmitted with bad syntax.
Suped's product supports the domain-level part of the workflow through DMARC reporting, source identification, authentication checks, alerts, and blocklist monitoring. The raw Vade bounce remains the evidence for recipient suppression.
