SMTP 451 4.3.5 Server Configuration Problem

SMTP 451 4.3.5 is a temporary delivery failure. The basic reply code 451 is defined in RFC 5321 §4.2.3 as "Requested action aborted: local error in processing" — a 4xx code, meaning the message itself is valid and the server expects to recover. The attached enhanced status code 4.3.5 is defined in RFC 3463 §3.4 as X.3.5 "System incorrectly configured": "The system is not configured in a manner that will permit it to accept this message."

The critical detail most explanations miss: the 3 in 4.3.5 is the Mail System Status subject, which RFC 3463 says covers conditions "under the general control of the destination system administrator." In other words, the "server configuration problem" is almost always on the receiving mail server, not yours — and because it's a 4.x.x class (persistent transient failure), it should be retried, not abandoned.

What causes SMTP 451 4.3.5?

The receiving MTA accepted the connection but its own configuration prevents it from accepting the message at this moment. Common underlying causes:

• A misconfigured or half-deployed inbound mail server (e.g., a routing/transport rule, milter, or content filter that errors out).
• A relay/gateway that is configured to relay for a domain it no longer hosts, or whose downstream host is unreachable.
• Temporary backend dependency failure (LDAP/Active Directory lookup, antispam service, mailbox database) that the server reports as a config fault.
• Less often, a sender-side relay you control (e.g., your own Postfix/Exchange or an SMTP relay) returning 451 4.3.5 because its transport configuration is broken.

Because 4.3.5 is intentionally generic, the bounce text rarely names a specific line — RFC 3463 only guarantees the category of fault, not the exact misconfiguration.

How do I fix SMTP 451 4.3.5?

1. Treat it as transient first. A 4xx code means retry. A standards-compliant sender should queue the message and retry with exponential backoff (RFC 5321 recommends multi-day retry windows). Many 451 4.3.5 events are transient and clear within minutes to hours once the receiving server's dependency recovers.

2. Determine which side is misconfigured. Read the full bounce/DSN. The hostname in the response (or the Reporting-MTA/Remote-MTA fields of the DSN) tells you whether the rejecting server is the recipient's or one of yours. Test the path directly:

swaks --to user@recipient-domain.com --server mx.recipient-domain.com --from you@yourdomain.com

If the same 451 4.3.5 comes from the recipient's MX, the problem is on their end.

3. If it's the recipient's server: you cannot fix their configuration. Retry on schedule; if it persists beyond your retry window, contact the recipient's postmaster/IT with the exact DSN and timestamp so their admin can inspect their inbound transport, filters, and backend dependencies.

4. If it's a relay you operate: check that your MTA's transport map actually has a valid route for the destination, that any content filter/milter is running, and that backend lookups (DNS, directory, mailbox store) succeed. On Postfix, inspect postconf -n and the mail log for the deferred message; on Exchange, review the send/receive connector and transport rules.

5. If you send through an API/ESP (Courier, SendGrid, SES, Mailgun, etc.): the platform's retry queue handles transient 451s automatically. Check delivery logs to confirm whether retries eventually succeed; a persistent 451 4.3.5 against one recipient domain usually indicates that recipient's server, not the ESP. Note this is unrelated to your own SMTP auth setup — 451 4.3.5 is not an authentication or "less secure apps"/App Password issue.