TL;DR
A directory server blocked forwarding. The current unchanged attempt is permanent; this does not make the recipient address invalid.
What this code means
5.4.3 combines X.4.3, directory server failure, with class 5. DNS connectivity is a standards example, but the code does not identify the directory service that failed.
Technical meaning
X.4.3 means a network system could not forward a message because a directory server was unavailable. The standard calls it useful only for persistent transient failure, while the registry also confirms a class-5 form; 5.4.3 is that concrete permanent result.
Delivery status
Class 5 makes the message permanently unsuccessful in the unchanged context. It does not mean that the infrastructure issue can never clear, identify its owner, or establish recipient-address validity.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Stop automatic and manual retries in the unchanged context. Consider a new send only after the relevant directory service or connectivity path has demonstrably changed; elapsed time alone is not evidence of that.
Suppression decision
Do not suppress the recipient from 5.4.3 alone. This is an infrastructure lookup condition; require a separate recipient-specific signal or applicable policy.
Common causes
- A required directory server was unavailable during forwarding.
- The forwarding system could not connect to an Internet DNS server, a standards example rather than a universal diagnosis.
Diagnostic steps
- Retain the full response, time, SMTP stage, destination, and attempt identifier.
- Determine which system produced the status and inspect its directory and connectivity logs.
- Before a new send, confirm restoration of the relevant service or path.
Actions by owner
Sender administrator
- Stop unchanged retries and provide the response and attempt data to the responsible party.
- Submit again only after a confirmed infrastructure change.
Recipient administrator
- Inspect the relevant directory service and network path for the stated attempt.
- Restore the confirmed dependency and verify forwarding before requesting another send.
Provider
- Inspect service and directory-connectivity logs for the exact time and path.
- Correct or communicate the confirmed infrastructure issue without suppressing the recipient solely from 5.4.3.
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.
Last verified:
