Does 4.4.3 mean the domain does not exist?

No. It means the lookup failed. A domain that truly does not exist produces a definite answer and a 5.x.x bounce instead.

Why can I resolve the domain but my server cannot?

Your resolver may not validate DNSSEC while your server’s does, or your server uses a different resolver that is failing.

4.4.3 deferral: directory server failure

4.4.3Directory server failureTemporary: the sender retries

Example

dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=example.com type=MX: Host not found, try again)

What it means

RFC 3463 defines X.4.3 as "Directory server failure". The network directory it refers to is, in practice, DNS: your sending server could not look up the recipient domain’s MX or address records because the lookup failed rather than returned an answer. The example is Postfix’s log text for a SERVFAIL or timeout on the MX query.

It is produced by your own MTA before it contacts anyone. The key difference from 5.4.4 is that 4.4.3 means the DNS question got no usable answer (try again later), while 5.4.4 means DNS answered definitively that there is nothing to route to. The domain may well be fine; your resolver or their nameservers had trouble at that moment.

A 4.4.3 is retried. If the DNS problem persists, the final bounce after queue expiry may still read 4.4.3 or turn into 4.4.7. A 5.4.3 is rare and mostly comes from systems that treat a broken directory as permanent.

Likely causes

The recipient domain’s authoritative nameservers are down, lame, or not responding.
DNSSEC validation failed (an expired signature or a DS record that no longer matches the DNSKEY), so a validating resolver returns SERVFAIL.
Your server’s own resolver is broken, overloaded, or blocked from reaching the internet.
The domain’s delegation at the registry points at nameservers that do not serve the zone.

How to fix it

Query the recipient domain’s MX from your mail server with the same resolver it uses, for example `dig MX example.com`. A SERVFAIL confirms the problem.
Test a known good domain the same way. If that also fails, your resolver is the problem; fix or replace it.
Check whether the domain is DNSSEC signed and whether validation fails. A DS record without a matching DNSKEY causes SERVFAIL at every validating resolver.
If you own the recipient domain, audit its nameservers and DNSSEC chain and correct the delegation or re-sign the zone.

Checks that apply

Your domain or sending IP (fills in the checks below)

DNS Server Audit Audits the domain’s nameservers for lame or unresponsive delegations, a common reason MX lookups fail.
DS Lookup Shows the DS record at the parent zone so you can compare it with the published DNSKEY.
DNSKEY Lookup Lists the zone’s DNSSEC keys, revealing a key rollover that broke validation.
DNS Propagation Checks the MX answer from many resolvers, showing whether the failure is global or local to your server.

FAQ

Does 4.4.3 mean the domain does not exist?: No. It means the lookup failed. A domain that truly does not exist produces a definite answer and a 5.x.x bounce instead.
Why can I resolve the domain but my server cannot?: Your resolver may not validate DNSSEC while your server’s does, or your server uses a different resolver that is failing.

All 191 bounce codes