The DNS records usually required to solve 450 4.1.8 Sender address rejected: Domain not found errors are valid MX or address records for the RFC5321 sender domain, plus valid DNS for any MX hostnames that domain publishes. I check the envelope sender domain first, not the visible From header and not the Received hostname.
In practical terms, if the SMTP envelope sender is bounce@ml.hostname.com, the receiving system wants to know that ml.hostname.com exists in DNS and can receive mail or resolve by address. If that domain has an MX record, the MX target also needs working A or AAAA records. If there is no MX, many receivers fall back to A or AAAA on the sender domain itself. Some gateways check both the envelope sender and the header From domain, so I verify both.
- Primary check: The RFC5321.MailFrom domain needs MX, A, or AAAA data that resolves cleanly.
- Common hidden fault: The MX record exists, but the MX target hostname has no A or AAAA answer.
- Not the fix: Adding a CNAME so the domain responds over HTTP or ping is not the right repair.
- Also check: DNSSEC, authoritative nameserver consistency, SPF, DKIM, DMARC, HELO, PTR, and rDNS.
A passing SPF or DKIM result does not prove the sender domain has the DNS records a receiving server checks before accepting mail. Authentication and basic sender-domain existence are related, but they are separate checks.
What the error is checking
I treat this as an SMTP sender-domain validation failure first. The enhanced status code 4.1.8 points at the sender address system, and the text Domain not found points at DNS. The receiver is not saying that HTTP failed, and it is not necessarily saying DMARC failed. It is saying that one sender-related domain failed a DNS existence or resolution check.
What receivers usually check
- Envelope sender: The RFC5321.MailFrom domain used in the SMTP transaction.
- Visible sender: The RFC5322 From domain shown in the message header.
- Reply path: Whether the sender domain can receive bounce traffic.
- DNS authority: Whether every authoritative nameserver returns valid answers.
What does not decide it alone
- Received host: The MTA hostname can rotate without changing the visible sender.
- HTTP response: SMTP does not require a website on the sender domain.
- Ping response: ICMP reachability is not an email authentication requirement.
- DKIM pass: A valid signature does not prove MX or address records exist.
Infographic showing the SMTP sender domain moving through DNS lookup and MX or A record validation.
That distinction matters when an ESP uses several sending hosts, such as mta1, mta2, and mta3. Those hostnames belong to the transport path. The sender domain in the envelope and the visible From domain can stay on ml.hostname.com as long as the DNS and authentication data for that domain are correct.
DNS records to verify first
I start with the exact domain after the at sign in the SMTP envelope sender. If the bounce says Sender address rejected, that sender address is the most important clue. Then I repeat the same checks for the header From domain, because some filtering stacks check both.
|
|
|
|
|---|---|---|---|
RFC5321 | MX, A, AAAA | Bounce path | Add MX or address |
MX host | A, AAAA | Delivery target | Fix host address |
RFC5322 | MX, A, DMARC | Visible sender | Publish valid data |
MTA host | A, PTR | Host identity | Match forward DNS |
Zone | NS, SOA, DS | Authority | Repair delegation |
Records to verify for a 450 4.1.8 domain not found error.
Minimum DNS shapedns
ml.hostname.com. 3600 IN MX 10 mx1.mailhost.example. ml.hostname.com. 3600 IN TXT "v=spf1 include:esp.example -all" _dmarc.ml.hostname.com. 3600 IN TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc@hostname.com" ) s1._domainkey.ml.hostname.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIB..." ) mta3.ml.hostname.com. 3600 IN A 203.0.113.23 23.113.0.203.in-addr.arpa. 3600 IN PTR mta3.ml.hostname.com.
If the sender domain already has a working MX record, I do not treat a missing A record on that same domain as the automatic cause. I still check it, but I spend more time on the exact envelope sender, MX target resolution, authoritative answers, and DNSSEC state.
How I diagnose it without public domain names
When I cannot see the real domain, I use a repeatable checklist. The goal is to find the domain the receiver actually rejected, then prove that every authoritative DNS server gives a usable answer for that domain.
- Capture the SMTP sender: Use the bounce, logs, or Return-Path to identify the RFC5321 domain.
- Query the authority: Ask each authoritative nameserver directly for MX, A, and AAAA data.
- Follow the MX: Resolve every MX target to A or AAAA, and remove broken aliases.
- Check the visible From: Repeat existence checks for the RFC5322 From domain.
- Check the MTA host: Confirm HELO, A, PTR, and reverse DNS for every sending IP.
- Validate DNSSEC: Look for DS records, DNSKEY data, signature expiry, and SERVFAIL answers.
A quick domain health check helps when I want a broad view of DMARC, SPF, DKIM, and DNS record problems before I dig into individual nameserver responses.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After the broad check, I still confirm the raw DNS path. Recursive DNS can hide one broken authoritative nameserver because it caches a good answer from another server. A receiver that hits the broken server gets a different result.
Lookup commandsbash
dig NS ml.hostname.com dig @ns1.example.net ml.hostname.com MX +short dig @ns1.example.net ml.hostname.com A +short dig @ns1.example.net ml.hostname.com AAAA +short dig mx1.mailhost.example A +short dig mx1.mailhost.example AAAA +short dig -x 203.0.113.23 +short dig mta3.ml.hostname.com A +short dig +dnssec ml.hostname.com SOA
An insecure DNSSEC status is normal when the parent has no DS record and the child zone is unsigned. A bad DNSSEC state is different: the parent has DS data but the child zone cannot validate, often producing SERVFAIL for validating resolvers.
When multiple MTA hostnames rotate
Rotating between mta, mta2, and mta3 does not mean the From address has to rotate with the host. The MTA hostname is the identity of the sending machine. The envelope sender and the visible From domain are sender identities. They need correct DNS and authentication, but they do not need to equal the MTA hostname.
Sender domains
- Envelope domain: Used for SPF and bounce handling.
- Header From: Used for DMARC domain matching.
- DKIM domain: Used to prove signing control.
- Required state: Records exist and match the sending setup.
MTA hostnames
- HELO name: Should resolve forward by A or AAAA.
- PTR name: Should point back to the host.
- Sending IP: Should be authorized in SPF where needed.
- Required state: Each rotating host has clean forward and reverse DNS.
If only some recipients fail, compare the exact sending host and envelope sender on failed messages against accepted messages. That pattern often points to intermittent failures caused by one bad DNS answer, one bad MTA hostname, or one receiving resolver path.
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 basic DNS existence checks behind this error. They sit beside them. SPF proves that the sending IP is allowed for the envelope sender domain. DKIM proves that a signing domain controlled the message. DMARC checks whether SPF or DKIM matches the visible From domain closely enough for policy.
For ongoing operations, Suped is the strongest practical choice for most teams because it brings DMARC monitoring, SPF, DKIM diagnostics, hosted SPF, hosted DMARC, MTA-STS, blocklist (blacklist) monitoring, and real-time alerts into one workflow. If DNS access is slow or shared across teams, Hosted SPF helps centralize sender changes. If the sender list is large, SPF flattening helps keep SPF under lookup limits, and the SPF checker is useful for focused record validation.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The Suped workflow I use for this kind of problem is straightforward: add the domain, review the DNS diagnostics, compare authenticated sources against unverified sources, then watch whether failures drop after DNS changes propagate. That avoids guessing from one header sample when the real issue is a broken nameserver or a rotated sending host.
Practical Suped workflow
- Add the domain: Let Suped detect DMARC, SPF, DKIM, and related DNS status.
- Review issues: Use automated detection and fix steps for DNS and authentication faults.
- Monitor sources: Confirm each ESP and MTA path is sending through expected domains.
- Use alerts: Catch new failures quickly instead of waiting for a customer bounce report.
Fix patterns that actually work
The right fix depends on which lookup fails. I avoid changing the visible From domain until I have checked the envelope sender and the DNS authority path. Changing the From domain can create new DMARC problems while leaving the original sender-domain lookup broken.
|
|
|
|---|---|---|
No MX | Add MX | Best for mail domains |
Bad MX host | Add A or AAAA | Check every target |
No address | Add A or AAAA | Useful fallback |
Bad DNSSEC | Fix DS data | Watch SERVFAIL |
Bad rDNS | Fix PTR | One per IP |
SPF limit | Reduce lookups | Avoid permerror |
Common causes and practical fixes.
DNS repair confidence
Use these bands to judge whether the sender-domain DNS is ready to retest.
Ready
Clean answers
All authoritative nameservers return the same MX and address answers.
Retry later
TTL pending
Records are correct at the source, but old cached answers still exist.
Fix first
Split answers
One authoritative nameserver returns NXDOMAIN, no data, or a stale zone.
Blocked
SERVFAIL
Validating resolvers return SERVFAIL because DNSSEC data is broken.
A 450 reply is temporary. The receiver is telling the sending server to retry later. If the same DNS fault persists, retries turn into delayed mail and then a final bounce. Fix the DNS before deciding the issue cleared by itself.
Safer fixed zone patterndns
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 ml.hostname.com. 3600 IN TXT "v=spf1 include:esp.example -all" _dmarc.ml.hostname.com. 3600 IN TXT ( "v=DMARC1; p=quarantine; " "rua=mailto:dmarc@hostname.com" )
I avoid CNAME records at active mail sender domains. A CNAME cannot live beside TXT, MX, or most other records at the same owner name. If ml.hostname.com already has SPF TXT and MX records, replacing it with a CNAME breaks more than it fixes.
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 each MTA hostname resolvable forward and backward, even when traffic rotates.
Treat DNSSEC validation failures as delivery faults, not only DNS administration issues.
Common pitfalls
Assuming an SPF pass proves the sender domain has valid MX or address records everywhere.
Adding a CNAME at a mail subdomain that already needs TXT and MX records in place.
Checking only public recursive DNS and missing one broken authoritative nameserver.
Treating a 450 retry as solved before checking the next failed recipient domain.
Expert tips
Save one failed header and one accepted header so differences in MAIL FROM are obvious.
Verify MX targets first when the sender domain already has an MX record published there.
Use short TTLs during repair, then raise them once all authoritative answers match.
Do not enable DNSSEC until DS, DNSKEY, and registrar settings are checked together.
Expert from Email Geeks says the error text points to DNS, so the useful method is to run A and MX lookups for both RFC5321 and RFC5322 sender domains across the authoritative nameservers.
2022-09-23 - Email Geeks
Marketer from Email Geeks says missing MX records often explain this class of rejection, but the exact domain in the SMTP envelope has to be checked before changing records.
2022-09-23 - Email Geeks
The practical answer
To solve 450 4.1.8 Sender address rejected: Domain not found, verify the RFC5321 sender domain first. It needs usable MX or address records, its MX targets need A or AAAA records, and every authoritative nameserver needs to return the same correct answer.
Then verify the visible From domain, the MTA hostnames, PTR records, SPF, DKIM, DMARC, and DNSSEC. Do not add a CNAME for web-style resolution, and do not force the visible From address to match a rotating MTA hostname. The fix is almost always about the exact sender domain the receiver checked and the DNS path the receiver used.
For teams that manage multiple senders, Suped turns this into an ongoing workflow instead of a one-off investigation: monitor the domain, catch DNS or authentication drift, get real-time alerts, and keep SPF, DKIM, DMARC, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, and blocklist (blacklist) checks in one place.
