TL;DR
4.4.3 indicates an unavailable directory service on the forwarding path. Preserve timing and route context, check the relevant directory service (including DNS only when evidence points there), retry with limits, and do not suppress the address from this code alone.
What this code means
X.4.3 is directory server failure. Inability to connect to an Internet DNS server is one standards example, but the exact response does not identify the directory service or responsible party by itself.
Provider examples
smtp;451 cuda_nsu 4.4.3 Temporary server error. Please try again laterTechnical meaning
A directory service needed to forward the message could not be reached. The standard includes Internet DNS connectivity as one example and treats this detail as a persistent transient failure.
Delivery status
The leading 4 marks a current condition that may clear. It is neither a permanent message rejection nor proof that the directory failure is DNS, recipient-side, or sender-side.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Use bounded, idempotent retries with backoff and jitter. Stop on success, a permanent result, or the configured limit and move recurring results to route/service diagnosis.
Suppression decision
Do not suppress an address from 4.4.3 alone. Apply recipient suppression only after an independent permanent, address-specific signal or the relevant policy.
Common causes
- A directory server needed for forwarding was unavailable.
- An Internet DNS server could not be reached; this is one standards example, not an automatic diagnosis.
Diagnostic steps
- Confirm exactly 4.4.3 with a 4xx basic reply.
- Retain the raw response, message, attempt time, routing context, and system that reported it.
- Check availability and connectivity of the actual directory service used on this path; test DNS only if it is part of that path.
- Compare bounded retries and stop at success, permanent rejection, or the configured limit.
Actions by owner
Sender administrator
- Keep route and response evidence and retry in a bounded queue.
- Escalate repeated results with the exact directory-path context rather than an address-validity claim.
Recipient administrator
- Inspect directory-service availability for the reported time where you have control.
- Restore a confirmed temporary service condition and verify a controlled delivery.
Provider
- Inspect managed directory and routing logs for the matching time.
- Preserve the exact status while correcting a confirmed availability issue.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
- SMTP Field Manual (community corpus) — Community-maintained reference of provider SMTP responses, pinned locally as evidence.
Last verified:
