What DNS records are required to solve '450 4.1.8 Sender address rejected: Domain not found' errors?
Published 30 Apr 2025
Updated 20 Oct 2026
13 min read
Summarize with
Updated on 20 Oct 2026: We clarified the DNS checks and receiver-side fixes for 450 4.1.8 sender-domain errors.
The DNS records usually required to solve 450 4.1.8 Sender address rejected: Domain not found errors are a valid MX record or address records for the RFC5321.MailFrom domain, plus A or AAAA records for every hostname named by its MX records. Start with the domain to the right of the at sign in the SMTP envelope sender, not the visible From header or a hostname in a Received header.
If the SMTP envelope sender is bounce@ml.hostname.com, the receiving system checks ml.hostname.com. A valid MX record gives the clearest return route. When no MX exists, SMTP uses the domain's A or AAAA records as an implicit MX. If MX records exist but are unusable, adding an A record at the sender domain does not provide fallback routing. Some filtering policies also inspect the header From domain, but that is an implementation-specific check rather than the normal meaning of 4.1.8. These routing rules are defined in RFC 5321.
- Check the RFC5321.MailFrom domain for a usable MX record or, when no MX exists, A or AAAA answers.
- Resolve every MX target to A or AAAA and reject stale, malformed, or unresolvable targets.
- Query every authoritative nameserver because one stale server can cause intermittent failures.
- Do not add a web-oriented CNAME unless the sending provider requires that exact record on a dedicated return-path subdomain.
- Treat MAIL FROM:<> as a special null reverse-path with no sender domain to validate.
A passing SPF or DKIM result does not prove that the envelope sender domain can accept return mail. Authentication and sender-domain existence use DNS, but they are separate checks.
What the error is checking
Treat this as an SMTP sender-domain validation failure first. Enhanced status code 4.1.8 means the sender's system address does not exist or cannot accept return mail. The accompanying text Domain not found points to a DNS lookup failure. It does not report an HTTP, SPF, DKIM, or DMARC result. See IANA's status code registry for the definition of X.1.8.
DNS checks to make
- The RFC5321.MailFrom domain used in the SMTP transaction.
- Whether DNS returns MX, A, or AAAA data for that domain.
- Whether each published MX hostname has a usable address.
- Whether authoritative nameservers return consistent answers.
What does not decide it alone
- The RFC5322 From domain, unless the receiver applies a separate header-domain policy.
- The MTA hostname in a Received header or the SMTP HELO name.
- A website or ICMP ping response on the sender domain.
- A passing SPF, DKIM, or DMARC result.
SMTP envelope sender domain checked for MX or A records before a temporary 450 4.1.8 rejection.
That distinction matters when an ESP uses several sending hosts, such as mta1, mta2, and mta3. Those hostnames belong to the transport path. The envelope sender domain can remain ml.hostname.com when its DNS and authentication records match the provider's configuration.
DNS records to verify first
Start with the exact domain after the at sign in the SMTP envelope sender. The rejected address shown beside Sender address rejected is the most useful clue. Check the header From domain separately only when the receiving system documents or logs that additional validation. Correct a typo or an application default that uses an internal-only domain before adding DNS records.
|
|
|
|
|---|---|---|---|
Envelope sender domain | MX or A/AAAA | Return route | Publish usable mail DNS |
MX target | A or AAAA | Mail host address | Fix each target |
ESP return path | Provider-specified DNS | Delegated sender domain | Restore the exact record |
MTA hostname | A/AAAA; PTR for the sending IP | Separate host identity check | Match forward and reverse DNS |
DNS zone | NS and SOA; DS if DNSSEC is configured | Authority and validation | Repair delegation or DNSSEC |
Records to verify for a 450 4.1.8 domain not found error.
Usable sender-domain DNS shapedns
; Example only: replace these with your actual mail host and IP. ml.hostname.com. 3600 IN MX 10 mx1.mailhost.example. mx1.mailhost.example. 3600 IN A 192.0.2.25
A sender domain with a working MX does not also need an A record at the same name for standard SMTP routing. Its MX targets still need direct A or AAAA records, rather than CNAME aliases. An address pointing only to a website does not establish that SMTP accepts return mail. A null MX record, written as MX 0 ., tells receivers that the domain accepts no mail and disables implicit MX fallback. RFC 7505 recommends avoiding null MX on domains used in MAIL FROM or the visible From address.
How to check authoritative DNS
Use a repeatable checklist when the real domain cannot be shared. Find the domain the receiver rejected, then prove that every authoritative DNS server gives a usable answer for that exact name. Replace the example names below with the real domain when running the commands.
- Capture MAIL FROM in the sending log or bounce transcript; a delivered copy's Return-Path is only supporting evidence.
- Identify the authoritative zone, then query every nameserver for that zone directly for MX, A, and AAAA data.
- Distinguish NXDOMAIN from NODATA and SERVFAIL because each result points to a different repair.
- Resolve every MX target and check for malformed targets, stale aliases, or missing addresses.
- Confirm the HELO name, forward DNS, PTR, and reverse DNS for each sending IP as a separate reputation check.
- Validate DS and DNSKEY data when DNSSEC-aware resolvers return SERVFAIL.
Suped's domain health check gives a broad view of DMARC, SPF, DKIM, and related DNS problems before individual nameserver responses are compared.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Confirm the raw DNS path after the broad check. Recursive DNS caches can hide one broken authoritative nameserver by retaining a good answer from another server. A receiver that reaches the stale server gets a different result. Negative answers are cached too. Under RFC 2308, their cache lifetime is the smaller of the SOA record's TTL and SOA.MINIMUM. Lowering a newly added record's TTL does not clear a previously cached NXDOMAIN or NODATA answer.
Lookup commandsbash
# Find the authoritative zone and its nameservers. dig +trace ml.hostname.com MX # If hostname.com is the authoritative zone identified above: dig hostname.com NS +short # Replace ns1.example.net and repeat for every authoritative server. dig @ns1.example.net ml.hostname.com MX +norecurse +noall +comments +answer +authority dig @ns1.example.net ml.hostname.com A +norecurse +noall +comments +answer +authority dig @ns1.example.net ml.hostname.com AAAA +norecurse +noall +comments +answer +authority # Resolve the actual MX target through your recursive resolver. dig mx1.mailhost.example A +noall +comments +answer dig mx1.mailhost.example AAAA +noall +comments +answer # Check sending-host identity separately. dig -x 203.0.113.23 +short dig mta3.ml.hostname.com A +short # Request DNSSEC records, then validate with delv if installed. dig +dnssec ml.hostname.com MX delv ml.hostname.com MX
Read the status line: NXDOMAIN means the queried name does not exist. NOERROR with no requested record is NODATA; a missing AAAA record alone is normal if another usable mail route exists. SERVFAIL means resolution failed and does not identify the cause. The BIND lookup documentation explains these command options. The +comments option preserves the status line; dig +dnssec requests DNSSEC data, while delv performs validation.
An insecure DNSSEC status is normal when the zone has no authenticated chain of trust, such as an unsigned zone with no parent DS record. A bogus state means validation failed, for example because a parent DS record no longer matches the child DNSKEY or signatures have expired. Validating resolvers normally return SERVFAIL for bogus data.
When public DNS works but the receiver still rejects mail
If authoritative answers and independent recursive lookups succeed, ask the receiving administrator to repeat the lookup from the receiving server using its configured resolver. A failure there points to the receiving server's DNS path. Check resolver reachability over UDP and TCP port 53, cached failures, and split DNS that returns internal answers for a public sender domain.
Postfix commonly produces this wording through reject_unknown_sender_domain, which checks the MAIL FROM domain for missing or malformed mail DNS and uses 450 by default. This domain check does not prove that a bounce mailbox accepts mail. With smtpd_delay_reject = yes, sender checks are delayed until RCPT TO, so a rejection at that command still concerns the sender. See the Postfix configuration reference.
For a receiving Postfix service in a chroot, check the resolver configuration inside that environment as well as on the host. Send the administrator the exact MAIL FROM domain, rejection text, and timestamp so the failed lookup can be traced. Retest after the resolver fault is repaired; disabling sender-domain validation does not repair DNS.
When an ESP manages the return-path domain
Some ESP configurations use a dedicated bounce or return-path subdomain and require a CNAME or a set of delegated DNS records. The provider can verify those records during setup and continue using the domain after someone deletes or changes them. The next receiver then looks up the envelope sender domain and returns 450 4.1.8 because the return-path domain no longer has usable DNS.
- Copy the complete domain from the rejected MAIL FROM address, including every subdomain label.
- Compare the provider's current DNS instructions with answers from every authoritative nameserver.
- Restore the exact CNAME, MX, TXT, or delegated record set supplied for that hostname.
- Retest after the previous negative DNS answer has expired from recursive caches.
Do not invent a CNAME or place one at a name that already has MX or TXT records. A provider-issued CNAME works only when the return-path hostname is dedicated to that alias and the provider explicitly requires it.
When multiple MTA hostnames rotate
Rotating between mta1, mta2, and mta3 does not require the From address to rotate with the host. The MTA hostname identifies the sending machine. The envelope sender and visible From domain identify message senders. These names need correct DNS and authentication, but they do not need to be identical.
Sender domains
- The envelope domain handles SPF identity and bounce traffic.
- The header From domain supplies the DMARC identity.
- The DKIM d= domain identifies the signing domain.
- Each domain needs records that match the sending configuration.
MTA hostnames
- Each HELO name should resolve forward by A or AAAA.
- Each sending IP should have a stable PTR hostname.
- Forward DNS for the PTR hostname should return the sending IP.
- SPF should authorize each sending path where the envelope domain uses it.
If only some recipients fail, compare the sending host and envelope sender on failed messages with accepted messages. That pattern can expose intermittent failures caused by one bad authoritative answer, one broken MTA hostname, or a receiver-specific DNS path. PTR records are managed by the operator of the sending IP address space, usually the sending or hosting provider.
Rotating MTA host patterndns
mta1.ml.hostname.com. 3600 IN A 203.0.113.21 mta2.ml.hostname.com. 3600 IN A 203.0.113.22 mta3.ml.hostname.com. 3600 IN A 203.0.113.23 21.113.0.203.in-addr.arpa. 3600 IN PTR mta1.ml.hostname.com. 22.113.0.203.in-addr.arpa. 3600 IN PTR mta2.ml.hostname.com. 23.113.0.203.in-addr.arpa. 3600 IN PTR mta3.ml.hostname.com.
Where SPF, DKIM, DMARC, and Suped fit
SPF, DKIM, and DMARC do not replace the DNS existence checks behind this error. SPF checks whether the sending IP is authorized for the envelope sender domain. DKIM checks a cryptographic signature. DMARC checks whether a passing SPF or DKIM identity matches the visible From domain. Fix the 4.1.8 DNS failure first, then validate authentication.
Suped's DMARC reporting and email authentication platform helps review sending sources and authentication failures. After repairing the return-path DNS, use its SPF checker to verify authorization for each sending path.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
A practical Suped workflow is to add the domain, review its DNS diagnostics, and compare authenticated sources with unverified sources after the repair. A rejection before DATA occurs before the receiver receives the message headers needed for DMARC evaluation. Use SMTP logs to track these deferrals and confirm that queued messages are accepted.
Practical Suped workflow
- Add the domain so Suped can detect DMARC, SPF, DKIM, and related DNS status.
- Review the detected DNS and authentication faults before changing records.
- Confirm that each ESP and MTA path uses the expected sender domains.
- Use Suped alerts for authentication changes and SMTP logs to confirm delivery recovery.
Match the DNS result to the repair
The right fix depends on the failed lookup. Do not change the visible From domain before checking the envelope sender and authoritative DNS path. A From-domain change can create DMARC problems while leaving the original sender-domain failure untouched.
|
|
|
|---|---|---|
NXDOMAIN: name does not exist | Correct MAIL FROM typos or restore the exact DNS name | The intended sender domain resolves publicly |
NODATA for MX, A, and AAAA | Add a valid MX route or, without MX, A or AAAA | A usable return route exists |
Broken MX target | Add target A or AAAA | Every target resolves |
Removed ESP alias | Restore prescribed DNS | Public answer matches setup |
Split authority | Update the stale nameserver | Answers are consistent |
DNSSEC SERVFAIL | Repair DS or signatures | Validation succeeds |
Other SERVFAIL or lookup timeout | Check delegation, resolver access, and DNS transport | Lookups succeed from the receiving server |
Null MX | Use a bounce-capable sender domain or replace null MX | Return mail has a working route |
Common DNS outcomes and practical fixes.
DNS repair confidence
Use these bands to judge whether the sender-domain DNS is ready to retest.
Ready
Clean answers
Authoritative answers consistently provide a usable MX route or, without MX, A or AAAA.
Retry later
TTL pending
Records are correct at the source, but old cached answers still exist.
Fix first
Split answers
Authorities disagree about the sender name or no usable mail route exists.
Blocked
SERVFAIL
SERVFAIL prevents resolution; investigate DNSSEC, delegation, and resolver access.
A 450 reply is temporary, so the sending server should retry. If the DNS fault remains, queued mail is delayed and later expires into a final bounce. Fix the DNS instead of treating a successful retry as proof that the fault has disappeared. After caches expire, confirm queued messages receive final 250 acceptance after DATA rather than repeated deferrals.
Example MX route after repairdns
; Example only: use real inbound mail hosts and their addresses. ml.hostname.com. 3600 IN MX 10 inbound1.hostname.com. ml.hostname.com. 3600 IN MX 20 inbound2.hostname.com. inbound1.hostname.com. 3600 IN A 198.51.100.10 inbound2.hostname.com. 3600 IN A 198.51.100.11
Avoid a CNAME at an ordinary sender name that already has MX or TXT records because a CNAME cannot coexist with those records at the same owner name. A provider-issued CNAME can be correct on a dedicated return-path subdomain. Use the DNS model prescribed for that exact hostname.
Views from the trenches
Best practices
Check the exact RFC5321.MailFrom domain before changing visible From or DKIM settings.
Query every authoritative nameserver so stale DNS data does not hide the real fault.
Keep MTA names resolvable and each sending IP mapped to a PTR that resolves back to that IP.
Verify parent DS, child DNSKEY, and signature validity after a DNSSEC or nameserver change.
Common pitfalls
Assuming an SPF pass proves the sender domain has valid MX or address records everywhere.
Adding a CNAME at a sender name that already needs TXT and MX records at that owner.
Checking only recursive DNS and missing one broken authoritative nameserver response.
Treating a 450 retry as solved before testing the same envelope sender at more recipients.
Expert tips
Compare failed and accepted SMTP log entries to identify the actual MAIL FROM domain used.
Verify every MX target address when the sender domain already has a valid MX record.
Account for negative DNS caching after fixing an NXDOMAIN or NODATA response at its source.
Check the provider's exact return-path hostname before restoring a deleted CNAME record.
Expert view
An Email Geeks participant says the error text points to DNS, so the useful method is to run A and MX lookups for the RFC5321 domain across every authoritative nameserver.
2022-09-23 - Email Geeks
Marketer view
An Email Geeks participant says missing MX records often explain this rejection, but the exact domain in the SMTP envelope must be checked before records change.
2022-09-23 - Email Geeks
Frequently asked questions
No. A valid MX record supplies the normal mail route as long as each MX target resolves to A or AAAA. When no MX exists, SMTP falls back to A or AAAA on the sender domain as an implicit MX.
Not primarily. This reply normally reports a DNS existence or resolution failure for the SMTP envelope sender domain. DMARC evaluation is separate and depends on SPF or DKIM matching the visible From domain.
Only when the sending provider requires that exact CNAME on a dedicated return-path hostname. Do not add an arbitrary CNAME, and do not add one at a name that already contains MX or TXT records.
No. Each MTA hostname should resolve forward, and each sending IP should have a PTR hostname that resolves back to that IP. The visible From domain can remain stable. Configure SPF, DKIM, and DMARC for the chosen sender identities.
Yes. Broken DNSSEC can make validating resolvers return SERVFAIL, so the sender domain appears unresolvable. Check DS records, DNSKEY data, signatures, and registrar delegation together.
A null MX record, written as MX 0 ., says a domain accepts no mail and prevents implicit MX fallback. A receiver rejecting a sender for null MX should use 550 5.7.27 under RFC 7505. MAIL FROM:<> is the valid empty reverse-path used for delivery notifications and has no sender domain to check.
