SMTP error 450 4.1.8: sender domain not found, temporarily refused

SMTP error 450 4.1.8 is a temporary rejection of your sending domain because the receiving

server could not resolve it in DNS at the moment of the check. The enhanced code 4.1.8 is RFC

3463's "bad sender's system address" within the retriable 4xx class - the deferred counterpart

to a permanent domain-resolution failure. Crucially, the receiving server is not yet certain your

domain has no DNS presence; it is giving the check another chance on a future attempt.

Fault: sender, specifically the sending domain's DNS state, though often this is a timing

issue (propagation) rather than a genuinely missing record.

Why it happens

• DNS has not fully propagated yet for a newly configured or recently changed sending

domain. The record may be correct and published, but has not reached every resolver the

receiving server might query.

• A resolver-level caching issue at the receiving server's DNS infrastructure, where a

negative result from before your record existed is still cached (a negative-TTL situation)

even though the record is now live.

• Genuinely no `MX` or `A` record exists yet for the sending domain, and the server is being

lenient by deferring rather than permanently rejecting, giving you a window to fix it before it

escalates to a 550.

• An intermittent DNS infrastructure problem on your own domain's authoritative nameservers,

causing some queries to succeed and others to fail depending on which resolver or geographic

path is used.

The deferral window exists precisely to absorb this kind of timing mismatch between "the record

is technically published" and "every resolver that might check it has actually seen it." A record

can be perfectly correct and still fail a check that happens to query a resolver that has not

caught up yet - which is why patience, not a configuration change, is usually the right first

response.

The transcript

$ swaks --to test@mailpilots.in --server mx.example.net --from sender@newdomain.test
-> MAIL FROM:<sender@newdomain.test>
<- 450 4.1.8 <sender@newdomain.test>: Sender address rejected: Domain not found

How the big three word it

Diagnose it

$ dig +short MX newdomain.test
$ dig +short A newdomain.test

Run this from an external resolver (a public DNS service, not your own infrastructure) to see

exactly what the outside world currently sees, rather than what your own DNS server believes.

$ dig +trace newdomain.test | tail -10

+trace walks the full delegation chain from the root, which reveals whether the domain's

nameservers are correctly delegated and reachable - a common, less obvious cause when the records

themselves look correct but the chain leading to them is broken.

The fix, in order

1. Confirm at least one of `MX` or `A` exists for the sending domain, checked from an

external resolver.

1. Allow standard DNS propagation time after any recent change - typically governed by the

record's TTL, though some resolvers cache longer than the published TTL suggests.

1. Check the domain's full delegation chain with `dig +trace` if records look correct but the

error persists, since a broken nameserver delegation produces the same symptom as a missing

record.

1. Retry sending after confirming DNS is resolving correctly everywhere you can check from.
2. If the condition persists for more than a day with confirmed-correct DNS, treat it as

worth contacting the specific receiving domain's postmaster, since it may indicate a stale

negative cache on their side specifically.

What not to do

• Do not panic and change your envelope-from domain. A brand-new domain has no DNS history at

all behind it and will trigger the identical check with less trust, not more.

• Do not assume the error is permanent. It is a 4xx; the deferred retry window exists

specifically so a genuine, temporary propagation delay has a chance to resolve.

• Do not keep resending identical messages manually while waiting for DNS to propagate - let

the normal queue retry schedule handle it instead.

• Do not confuse this with the permanent `550 5.1.0` (sender address rejected, covered

separately) - that one indicates the receiver has given up retrying; this one is still actively

giving you a window.

MailPilot's Domain Health checks validate MX, A, and the full authentication record set for a

sending domain before it is put into active use, which catches a missing or not-yet-propagated

DNS record before it produces this exact deferral against a real recipient.