SMTP 451 4.3.5: a configuration error on the receiving server

451 4.3.5 is a 4xx temporary failure meaning the receiving mail system has a configuration fault - RFC 3463 defines 4.3.5 specifically as "system incorrectly configured." In practice this covers things like a missing system-level mail alias, a broken routing or transport map, a DNS lookup the mail system itself needs (not yours) failing, or a mail-system daemon that started with an invalid config file and is only partially functional.

Who is at fault

This is entirely a receiving-side configuration fault. You cannot fix someone else's mail server config, and nothing about your sending setup - authentication, content, or reputation - is relevant here. On self-managed mail servers running Exim or Postfix, a 4.3.5 condition sometimes traces back

to a configuration file that references an external file, database, or service that has since

moved or been decommissioned - a lookup table path that no longer exists, or a database connection

string pointing at a retired server. These are the kinds of changes that get made during

infrastructure migrations and occasionally missed in one specific configuration block, surfacing

only when a particular kind of mail transaction exercises that exact code path.

The exchange

220 mx.example.com ESMTP Exim 4.97
EHLO mail.yourdomain.com
250-mx.example.com
250 SIZE 52428800
MAIL FROM:<sender@yourdomain.com>
250 OK
RCPT TO:<recipient@example.com>
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
451 4.3.5 System config error

How Gmail, Microsoft 365 and Yahoo word the same condition

Large cloud providers rarely expose this specific subcode externally because their infrastructure is designed to fail over rather than present a raw configuration error - self-managed or smaller business mail servers are far more likely to surface 4.3.5 directly.

Diagnostic commands

There is little you can diagnose on their server, but you can confirm the fault is persistent and not a one-off blip:

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  451 4.3.5 System config error

$ dig +short MX example.com
mx.example.com.

$ for i in 1 2 3; do sleep 1800; swaks --to recipient@example.com \
  --from sender@yourdomain.com --server mx.example.com; done

Spacing probes 30 minutes apart over a few hours tells you whether their admin has fixed the config, since this class of fault typically requires a human to notice and correct it rather than clearing on its own.

The ordered fix

1. Confirm your queue is retrying, not abandoning, on the normal schedule.
2. Wait several hours - configuration faults on small/self-managed mail servers are often caught and fixed by their own admin within a business day.
3. If it persists past 24-48 hours, contact the recipient through another channel and include the exact reply text (451 4.3.5 System config error) so they can hand it to whoever runs their mail server.
4. Do not attempt to work around it by routing through a different path on your end - there is no sender-side workaround for a receiving-side config bug.
5. Log the domain if this recurs; a mail server that regularly misconfigures itself is worth flagging as consistently unreliable for that destination.

What not to do

• Do not treat this as your fault and start auditing your own SPF/DKIM/DMARC. The fault description is explicitly about their system configuration, not your authentication.
• Do not bounce or suppress the address. No judgement was made about the recipient address at all; the failure happened in their mail system's own plumbing.
• Do not escalate sending volume or retry aggressively. A misconfigured mail system responding faster to more requests will not fix itself; it needs a config change, not more traffic.
• Do not assume this reflects on your sender reputation. It does not, because the receiving server's own infrastructure is broken, independent of who is sending.

When to stop waiting and escalate

Most 451 4.3.5 conditions clear within a business day because a human on the receiving end notices

their own broken configuration fairly quickly - config errors that break outbound mail delivery

tend to break other things too, which gets noticed. If a specific domain still returns this exact

error after 48-72 hours across repeated attempts, it is reasonable to conclude nobody there has

noticed yet, and a direct message to the recipient through another channel, with the literal error

text included, is more useful at that point than further automated retries.

MailPilot's inbox-placement tests reach a broad seed-inbox network across providers, so a single misconfigured destination mail system shows up as an isolated placement failure for that provider rather than skewing your overall deliverability picture.