5.4.1Mail rejected by the destination domain (permanent)

This catalog's IANA registry mirror mechanically confirms only the class-4 reading of registry pattern X.4.1 (code 4.4.1). No IANA registry confirmation exists here for any class-5 variant of the pattern, yet code 5.4.1 maps that pattern onto class 5. Under RFC 3463, X.4.1 means "no answer from host" and is useful only as a persistent transient failure. Concrete code 5.4.1 appears in this catalog on exact corpus evidence instead: production responses that carry the digits 5.4.1 yet describe a permanent destination-side rejection, whether through the receiving domain's own mail filters (Zoho) or a recipient-address access policy enforced inside a non-delivery report (Microsoft 365 / Exchange Online Protection), not an unanswered connection.

Observed provider behavior treats the digits as evidence of a permanent destination-side refusal, not as proof that the standard's exact "no answer from host" condition occurred. Pattern X.4.1 denotes no answer from the remote host: an outbound connection attempt went unanswered because the remote system was busy or unable to accept the call. RFC 3463 states the pattern generically, and this catalog's IANA registry mirror mechanically confirms only the class-4 variant (4.4.1, basic SMTP code 451, a persistent transient failure). No IANA registry mechanism confirms a class-5 variant of X.4.1 here. Concrete code 5.4.1 is published on exact corpus evidence: production responses carrying the digits 5.4.1 that describe a permanent destination-side rejection (a receiving domain's mail filters, or a recipient-address access policy), not the literal unanswered connection attempt the standard describes.

The leading digit 5 denotes a permanent failure for this message in the current context: do not repeat the exact same send unchanged. This does not by itself mean the recipient address is permanently invalid — both accepted examples describe a filter or access-policy decision, which can change if the receiving domain adjusts it. Do not conflate this with 4.4.1, where the same X.4.1 pattern is IANA-confirmed as a class-4, retryable condition describing an unanswered connection.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Operational recommendation: stop automatic and manual retries of the same message to this address in the unchanged context. A new send makes sense only after a relevant condition has demonstrably changed — the receiving domain adjusting its filter, or its administrator confirming the recipient-access policy no longer blocks the address — not merely after time has passed.

Operational recommendation: do not add the address to a suppression list from a single 5.4.1 alone. Inspect the full response text and the system that returned it: a destination-domain filter or a recipient-access policy decision may be reversible by the recipient's administrator and is not the same as a permanently invalid address. Suppress only once the applicable list policy, or an independent permanent signal, justifies it.

• The receiving domain has its own mail filters configured to block this specific message, independent of the sender's own reputation — documented Zoho behavior for domains hosted with this provider.
• The receiving system's recipient-address access policy denies delivery to this specific address, reported inside a non-delivery report rather than a live SMTP reply — documented Microsoft 365 / Exchange Online Protection behavior.
• Providers reuse the X.4.1 digits for a permanent destination-side refusal that the standard's own example ("no answer from host") does not describe; the code alone does not identify which filter or policy fired.

1. Inspect the raw SMTP response or non-delivery report and confirm that the enhanced code is exactly 5.4.1 and the basic reply is in the 5xx class (541 in the accepted Zoho example, 550 in the accepted Microsoft 365 / Exchange Online Protection example).
2. Read the provider's own description text carefully: it usually names the real cause (destination-domain mail filters, or a recipient-address access policy), which does not have to match the standard's literal "no answer from host" wording for X.4.1.
3. Correlate the response with the specific message, attempt time, and recipient address or domain; retain the full response text, including any bracketed server or message identifiers the provider includes.
4. Stop unchanged automated retries; before any new send, confirm with the recipient or their administrator that the underlying filter, policy, or address issue has actually changed.