Before a receiving mail server accepts a message, many of them look at the sender address and ask a simple question: does this domain exist, and can it receive mail? If DNS gives no useful answer, the server may refuse the message with a reply such as 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found, 553 5.1.8 Sender address rejected: domain of sender address does not exist or 550 5.7.1 Sender address rejected: Access denied. These replies surprise people because the domain in question is often perfectly healthy in a web browser. The reason is that the check is made against the sender address in the SMTP envelope, from the receiving server's resolver, at the moment of delivery, and what matters is whether DNS for the mail setup answers correctly then. This guide explains the check, lists the causes in the order that they usually occur, shows how to test them with a few commands and gives the fix for each. It also explains the temporary 4.1.8 variant, which is often a short DNS outage and clears by itself.
What the receiving server checks
SMTP has two senders. The envelope sender is the address given in the MAIL FROM command; it is where bounces go, and it appears in the Return-Path header after delivery. The header From is the address the reader sees. The check described here uses the envelope sender. The receiving server takes its domain and asks DNS for an MX record. If there is none, the standard allows a fallback to the domain's address records. If DNS says the domain does not exist (NXDOMAIN), or the domain has neither mail nor address records, or the lookup fails, a server configured to verify senders refuses the message. In Postfix this is the reject_unknown_sender_domain restriction, and many other servers have an equivalent. The enhanced status code 5.1.8 is defined as "bad sender's system address" in RFC 3463, and 4.1.8 is its temporary form.
Why it happens: the causes
1. The envelope sender uses a domain that does not exist
The most common reason, and the easiest to fix. A typo in the configuration of your application or server (exmaple.com), a placeholder left in place (noreply@localhost or [email protected]), a domain that expired, or a development address that was never replaced. Local hostnames such as localhost.localdomain are not real domains and fail the check at every receiver that makes it. Check the exact address in the bounce, then check where your software gets it. Applications often have separate settings for the From address and for the envelope sender, and only the second is changed when you fix the first.
2. The domain exists, but has no mail or address records
A domain used only for a web redirect, or a freshly registered one, may have no MX and no A record at the apex. Add an MX record that points at a real mail host, or, if the domain will never receive mail, publish a "null MX" (an MX with priority 0 and target .) so that receivers get a clean, explicit answer rather than an error. For basic background, see what an MX record is.
3. Broken or unreachable nameservers
If the nameservers listed at the registrar do not answer, or answer differently from each other, the domain works in one resolver's cache and fails at another. This is a typical cause of intermittent failures and of the temporary 4.1.8. It often follows a DNS migration, a registrar change or an expired DNS hosting plan. Check that all nameservers at the registrar are correct and answer with the same data.
4. DNSSEC problems
A domain with DNSSEC enabled but with a mismatched DS record at the registrar looks valid in a lenient resolver and fails in a validating one, which returns a failure (SERVFAIL) and not an answer. Receiving servers that validate will report that the domain cannot be found. After a DNS provider move, turn DNSSEC off at the registrar before the move, or update the DS record afterwards. Our guide to DNS record quirks across registrars covers the related pitfalls.
5. Recent changes that have not propagated
If you created the domain or changed its DNS in the last hours, some resolvers may still hold the old "does not exist" answer. Negative answers are cached for a period set by the zone's SOA record. The fix is to wait, and to avoid sending from the new domain until the records resolve everywhere.
6. A local resolver problem on the sending side
Occasionally the error is produced by your own server. A mail server that cannot resolve DNS because of a broken /etc/resolv.conf, a blocked firewall rule for port 53, or a resolver that is down logs "Domain not found" for addresses that exist. Test name resolution from the sending machine, not from your laptop.
Test it with a few commands
# Does the domain have mail records?
dig MX example.com +short
# Fallback address records
dig A example.com +short
dig AAAA example.com +short
# Ask the authoritative nameservers directly
dig NS example.com +short
dig MX example.com @ns1.your-dns-host.example +short
# Check from a public resolver, and from the sending server
dig MX example.com @1.1.1.1 +short
# DNSSEC status (look for SERVFAIL or the ad flag)
dig MX example.com +dnssecInterpret the output carefully. An empty answer with status: NXDOMAIN means the name does not exist. An empty answer with status: NOERROR means the name exists but has no records of that type. A SERVFAIL means the resolver could not get a valid answer, which points to broken nameservers or DNSSEC. If the public resolver and the authoritative server disagree, the problem is propagation or inconsistent nameservers. Run the same commands on the machine that sends the mail.
Fixes
| Finding | Fix |
|---|---|
| NXDOMAIN for the envelope sender domain | Correct the sender address in the application or server, or register or renew the domain |
| NOERROR with no MX or A records | Add an MX record, or a null MX if the domain never receives mail |
| Different answers from different nameservers | Make every nameserver at the registrar serve the same zone; remove stale ones |
| SERVFAIL with DNSSEC | Fix or remove the DS record at the registrar; check the signing at the DNS host |
| Domain works from your laptop, not from the server | Repair the server's resolver configuration and firewall rules for DNS |
| Only 4.1.8, then it works later | Temporary DNS failure; let the queue retry and check for repeated resolver timeouts |
If you run the receiving server
Sender domain verification catches a lot of junk, but it also rejects legitimate mail from badly configured senders and it generates complaints when a small DNS outage causes a burst of refusals. If you use Postfix, reject_unknown_sender_domain returns a temporary 450 4.1.8 for DNS timeouts and a permanent code for non-existent domains, and the behaviour can be adjusted with unknown_address_reject_code and related parameters. Use a local caching resolver so that lookups are fast and reliable. Treat the check as one signal among others, not as the only defence. Do not turn it off to fix one sender; ask the sender to repair their DNS.
Relationship with authentication and bounces
The envelope sender is also where SPF is evaluated and where bounces return. If you use a sending service, the envelope domain is usually a bounce domain on your side or the provider's. If the CNAME or MX record for that bounce domain is missing, you can see this very error, and you will also lose the benefit of SPF alignment. See custom return path and tracking domains and verifying your sending domain. If a domain used for bounces cannot be resolved, replies from receivers cannot reach you either, so you stop learning about invalid addresses. For help reading what a bounce is telling you, see how to read a bounce code.
Prevent it
- Use fully qualified, real sender domains in every application, script and device. Never leave placeholder or local hostnames.
- Keep domain registration on auto-renew and keep the registrar contact details current.
- Monitor DNS: alert on nameserver failures and on changes to MX, SPF and DNSSEC records.
- After a DNS provider migration, check every record type with
digagainst the new nameservers before switching the registrar. - Use a null MX for sending-only domains, and see parked and non-sending domains for the matching SPF and DMARC records.
Verify your domain before you send Check your sending and bounce domains, with the DNS records you need shown step by step.
References and further reading
Frequently asked questions
What does sender address rejected domain not found mean?
The receiving server could not find usable DNS records for the domain of the envelope sender, so it refused the message.
What is the difference between 4.1.8 and 5.1.8?
4.1.8 is temporary, often a DNS timeout, and the message is retried. 5.1.8 is permanent, for example when the domain does not exist.
Why does this happen for a domain that works in my browser?
Websites need an A record, while the mail check looks at the envelope sender domain for MX or address records, and may come from a resolver that sees different data.
How do I fix it if I send from an application?
Correct the envelope sender and From addresses to a real domain, make sure the domain has MX or address records and check that the nameservers are healthy.
Should I disable sender domain verification on my server?
No. Fix the sender instead. If DNS timeouts cause temporary rejections, use a local caching resolver to make lookups reliable.