Why Does My ESP Return 550 5.1.3 Domain Unknown?

What does 550 5.1.3 domain unknown actually mean?

You try to validate an email address, and your ESP returns a 550 5.1.3 error: "Domain unknown." You check the address again. It looks fine. You wonder: did I make a typo? Is this a problem on my end?

It’s not. This error isn’t about the user, the format, or your send rate. It’s a DNS-level signal: the mail server can’t even find the domain you’re trying to reach. The domain doesn’t exist in DNS, or it lacks proper MX records. It’s a hard stop before any logic about validity or deliverability even applies.

And it happens fast—usually right after the HELO/EHLO handshake in SMTP negotiation. This is one of the earliest possible rejection points. Knowing why it occurs helps you distinguish real, unresolvable issues from temporary glitches or bad data, so you don’t waste time chasing false positives.

Key takeaways

• The 550 5.1.3 error means the domain doesn’t exist or lacks valid MX records in DNS.
• It’s not a user or sending issue—it’s a DNS-level failure before verification starts.
• It’s returned early in SMTP, often right after HELO/EHLO, indicating an immediate, irrecoverable misconfiguration.

Why does my ESP return 550 5.1.3 during validation?

When your ESP returns a 550 5.1.3 "domain unknown" error, it means the domain in the email address couldn’t be resolved via DNS during the SMTP handshake. This happens early in the validation process—before any message is sent—and is not a sign of a problem with your ESP. It simply means the domain doesn’t exist, isn’t properly configured, or lacks a valid MX record.

The DNS Check Happens Early

SMTP validation starts with a simple question: “Does this domain even exist?” Your ESP queries the domain’s DNS records right after the HELO command. If the domain doesn’t resolve to an IP or lacks an MX record, the receiving server (or your ESP’s own validation layer) returns a 550 5.1.3 error. This is expected behavior. It's similar to trying to call a phone number that isn’t assigned—no further steps are needed.

According to RFC 5321, Section 4.1.1.2, a receiving server must reject unknown domains immediately. This is standard practice for both mail delivery and validation systems to avoid wasted resources. This error isn’t a bug; it’s a deliberate safeguard.

Why It's Common in Bulk Validation

You’re likely to see this error when cleaning old or poorly maintained email lists. Over time, people leave companies, domains shut down, or email structures change. A list from two years ago might contain domains that no longer exist or have been rebranded. These are the addresses that trigger 550 5.1.3 during bulk validation.

Let’s say you’re sending to a list of 5,000 addresses and 20% return 550 5.1.3 errors. That’s not a failure of your ESP—it’s evidence that 1,000 addresses are invalid. Cleaning them out early prevents bounces, improves sender reputation, and reduces delivery risk.

Real-time verification tools—like the API we offer—flag these domains instantly. You can test individual addresses or process large volumes. If you're managing campaigns with tools like Mailchimp, HubSpot, or SendGrid, integrating early validation can stop 550 5.1.3 errors before they impact your campaign health.

Many users see this error pop up most often during bulk validation because it’s the first point of technical failure in the mail chain. It’s not a flaw—it’s a signal that domain-level issues exist and should be cleaned before sending.

If you're unsure how to identify and remove these, consider a bulk validation tool that flags non-existent domains in real time. Use our bulk email list cleaning process to catch these 550 5.1.3 errors before they impact deliverability.

How do DNS records affect email validation?

When your ESP returns a 550 5.1.3 "domain unknown" error, it means the recipient domain has no valid MX record — the DNS lookup failed before any email delivery or authentication checks. Without a properly configured MX record, the mail server doesn’t know where to deliver mail, so validation fails at the DNS level, regardless of SPF, DKIM, or DMARC configuration.

MX records are the gateway to email delivery

Every domain must have at least one MX (Mail Exchange) record to receive email. If a domain lacks an MX record, has a typo in the name, or points to a non-existent server, the receiving mail server rejects incoming mail with a 550 5.1.3 error. This is a fundamental DNS-level validation step — no MX means no email acceptance.

Even if the rest of the email infrastructure is perfect — SPF set, DKIM signed, DMARC enforced — these checks only happen after DNS validates that the domain is routable. A domain with no MX record fails before that stage. This means you can’t rely on authentication records to fix a missing MX.

Other DNS configuration issues can trigger the same error

Not just MX records matter. A domain without an A record (which maps a hostname to an IP) or with misconfigured DNS entries (e.g., a typo in the domain name) will also trigger a 550 5.1.3 error. For example, sending to [email protected] instead of [email protected] results in a DNS lookup failure and an immediate rejection.

These issues aren’t tied to your email service provider’s setup — they’re entirely down to the recipient domain’s DNS configuration. Even if your server is properly set up, your outbound messages can still fail if the destination has broken DNS. You can test this by checking the domain’s records using tools like MXToolbox or RFC 5321, which defines the SMTP protocol for mail delivery.

Validating email addresses before sending helps catch these issues early. Tools like bulk email list cleaning can identify and remove addresses tied to domains with missing MX records, preventing bounces and protecting sender reputation.

When does 550 5.1.3 appear in real-world validation?

550 5.1.3 "domain unknown" appears when an email address’s domain doesn’t respond to DNS queries or lacks valid MX records. This typically happens with outdated addresses, expired domains, or catch-all setups that don’t properly route mail. It’s a hard failure, meaning the email can’t be delivered — and it shows up during list validation when the domain itself is unreachable.

Common real-world triggers for 550 5.1.3

• You’re validating a list with outdated or incorrectly formatted email addresses — like [email protected] where the domain no longer exists.
• The domain has no MX records, or its DNS is misconfigured, often seen with catch-all domains that claim to accept all emails but lack a real mail server.
• You’re trying to send to a domain that was recently deleted or expired — even if it remains in your database, the domain is no longer active on the internet.
• The domain’s DNS is unreachable due to network issues, registrar lock, or TTL delays, causing temporary 550 5.1.3 during bulk checks.

How to confirm it's not a false alarm

Let’s be clear: 550 5.1.3 isn’t just a warning — it’s a final verdict from the receiving mail server. According to RFC 5321, this error code means “the recipient’s domain is not recognized by the receiving system.”

Some tools might report this as “invalid” or “unknown,” but the underlying issue is a missing or unreachable domain. You can verify this manually using tools like MxToolbox or check DNS records directly with dig MX example.com.

If your ESP returns 550 5.1.3 during validation, the email is not just risky — it’s undeliverable. This includes cases where the domain exists but has no mail routing, or where the DNS records were dropped after a site migration.

• Use a real-time verification API to catch these errors before sending — test individual addresses on the fly.
• Run bulk cleaning on your list to remove expired domains and format errors that trigger DNS lookup failures.
• Check for domains that were moved or rebranded but are still in your system — these often disappear from DNS.
• Look for catch-all domains without real mail servers; they can mislead validation services into reporting “valid” addresses that fail on send.

Even with a correct-looking address, if the domain is offline or misconfigured, the result is a 550 5.1.3 — and no amount of follow-up will fix it.

How to fix 550 5.1.3 errors before sending

550 5.1.3 "domain unknown" errors happen when the recipient's mail server can't find the domain’s DNS records. To fix this, verify domains before sending by checking for missing or invalid MX, A, or SPF records. Use a tool that performs DNS validation before attempting delivery — this prevents SMTP failures and maintains sender reputation. Services like Email List Validation can flag problematic domains early, so you don’t waste sends on unresolvable addresses.

Run DNS checks before sending

Let’s be clear: an ESP won't accept delivery if the domain doesn't exist in DNS. The 550 5.1.3 error is the server’s way of saying, “I don’t know this domain.” You can avoid it by checking the domain’s DNS records—especially MX and A records—before sending mail. Many tools skip this step and go straight to SMTP handshake, which wastes bandwidth and risks reputation.

• Use a bulk verification tool that performs DNS preflight checks. These scan records like MX, A, and SPF to confirm the domain exists and is properly configured.
• Look for missing or malformed records. A domain without an MX record will fail verification, even if the email address is spelled correctly.
• Validate domains with tools that check for expired, parked, or non-existent domains. These are often flagged with 550 errors.

Correct or remove invalid entries

Many lists contain addresses with misspelled domains, expired domains, or fake domains altogether. These are dead ends and trigger 550 5.1.3 errors. Fixing them early is more cost-effective than reacting to bounces or blocklists later.

1. Run a bulk verification with a service like Email List Validation’s bulk verification tool, which checks DNS records—including MX and A records—on every email address before sending.
2. Identify entries where the domain is misspelled (e.g., "gmail.com" vs "gmaill.com") or has expired (e.g., "companyxyz.com" with a 2013 expiration).
3. Remove or correct any entries that fail DNS validation. This step cuts delivery failures before they happen.
4. Filter out catch-all domains (which can't be accurately verified) or disposable email domains (like mailinator.com), which often cause routing delays or rejections.

DNS validation is part of a layered defense. As outlined in RFC 5321, SMTP servers must resolve the domain before processing a mail transaction. Skipping this step undermines the entire delivery chain. You're not just fixing errors—you're building a reputation based on reliability.

What’s the difference between 550 5.1.3 and other SMTP errors?

550 5.1.3 means the domain itself doesn’t exist in DNS—no mail server at all. It’s not a user issue, nor a spam filter. Compare that to 550 5.1.1 (user unknown, but the domain is real) or 550 5.7.1 (policy block, often due to blacklists). The error code tells you exactly where the failure is: the domain name is invalid, not the mailbox or the sender.

SMTP error codes reveal the root cause

Let’s break down the real differences. Each 550 code is a distinct failure point in the delivery chain. Understanding them helps you diagnose list issues correctly—no more guessing why a batch fails.

You can’t recover from a 550 5.1.3 error—no configuration change will make a non-existent domain work. But with 5.1.1, you might still be able to deliver if you fix the spelling. For 5.7.1, reputation cleanup is needed. Knowing the difference stops you from wasting time on dead ends.

Why this matters for list hygiene

If your ESP returns 550 5.1.3 consistently, it’s a signal your list contains expired or fabricated domains. These are not recoverable with better content or timing. They must be filtered out. Real-time validation tools can flag these early, before you send. Bulk list cleaning or the real-time API help catch these before they harm your sender reputation. Not all tools catch DNS-level failures. Make sure yours does.

Can you verify email addresses without a domain?

You cannot verify an email address without a valid domain. If the domain part doesn’t exist or isn’t resolvable, there’s no way to check if the mailbox is valid — not even via SMTP. The validation process starts with DNS. If the domain fails DNS lookup, further steps are impossible. The only check made at this stage is whether the domain resolves; if it doesn’t, you get a 550 5.1.3 error or equivalent.

Why DNS resolution is the first and only check

Every email address has a domain — the part after the @. Without it, you’re not dealing with a real email. The system begins by attempting to resolve the domain via DNS. If that fails, no server exists to accept mail for that address, and verification halts. You can’t test SMTP or check mailboxes if the domain isn’t even in the global DNS system. This is how email validation is built: one step at a time, and the first step is non-negotiable.

Let’s say you're trying to verify [email protected]. The DNS lookup fails, and that’s that. This is why you see “domain unknown” or “550 5.1.3” — it’s not a misconfiguration; it’s a fundamental lack of existence. The SMTP RFC defines domains as required for routing, and failure to resolve them triggers a hard bounce.

What happens when domains are missing or malformed

If your list includes entries like [email protected], user@domain, or @example.org, those are invalid by format and don’t pass DNS at all. Email list validation tools catch these upfront and flag them as syntactically incorrect. This is not a flaw — it’s a feature. It prevents wasting resources on impossible checks.

Even if a domain looks real — like [email protected] — it’s still useless if it’s not published in DNS. You’d be asking a delivery attempt on a name that doesn’t exist, which is why tools like bulk email verification reject such entries early.

So yes — your ESP correctly returns 550 5.1.3. It’s not wrong. It’s reporting fact. You can’t verify without a domain, because domains are the foundation of email delivery. If one fails, nothing else matters.

How Email List Validation handles 550 5.1.3 errors

When your ESP returns a 550 5.1.3 "domain unknown" error, it means the domain doesn’t have a valid DNS record—specifically, no MX or A record. Our system catches this before any SMTP connection is made. Domains without these records are flagged as invalid with that exact reason code, so you can clean your list proactively instead of sending to dead addresses.

Pre-flight DNS checks prevent wasted SMTP attempts

Let’s be clear: a 550 5.1.3 error isn’t about your sending IP or message content. It’s a signaling issue at the DNS level. That’s why we check DNS records—including MX, A, and SPF—before even trying to connect via SMTP. If the domain doesn’t resolve, we skip the handshake entirely. This saves time and avoids unnecessary load on your sender reputation.

Many email validation tools still make live SMTP connections on every address, even when the domain is clearly broken. Our approach is different. We filter out junk early, based on real-world email standards like RFC 5321 and RFC 5322, which define how domains should be validated before delivery.

Clear verdicts help you act fast

You don’t want to guess why an address failed. That’s why we return the 550 5.1.3 code explicitly in our list output. You’ll see it next to the email, in real time or during bulk validation, so you can sort or export invalid entries instantly.

Imagine having a list of 5,000 emails and 600 show a 550 5.1.3. With this signal, you can remove those domains entirely, avoiding bounces, damage to sender reputation, and wasted send volume. This is how you keep your list clean before it ever touches your ESP.

For teams using automation, our real-time verification API integrates directly with your signup or CRM flow. It checks domains and addresses instantly—before you store or send. Try it at our API endpoint to see how it stops errors like 550 5.1.3 before they matter.

How to prevent future 550 5.1.3 errors in your email list

550 5.1.3 errors occur when an email service provider can’t find a valid DNS record for the domain you're sending to. Prevent them by verifying domains before every send—run regular bulk checks, integrate validation at the source, and prune inactive or expired domains. This reduces bounces, protects sender reputation, and keeps your mail deliverable.

Bulk checks catch invalid domains early

• Run bulk verification on your list every 3–6 months. Tools that check DNS validity, MX records, and syntax before sending catch inactive, expired, or typo-ridden domains.
• Use a service like bulk email list cleaning to scan thousands of addresses at once. This catches domains with no DNS zone, expired registrations, or missing mail servers before they cause a 550 5.1.3 error during actual delivery.
• Domains without a published MX record or valid SPF/DKIM setup are high-risk. These are common root causes of 550 5.1.3. A reliable validator flags them before you send.

Integrate at the source to block bad entries

• Integrate email validation with platforms like Mailchimp, HubSpot, or SendGrid. This stops invalid domains from entering your list in the first place.
• Let the real-time verification API run as a gatekeeper—each new signup gets checked instantly against DNS records, role accounts, and disposable domains.
• When you send via a transactional or marketing service, an integrated validation layer stops sends to known invalid domains and logs the reason (e.g., “domain unknown” or “catch-all”), giving you insight without breaking your campaign flow.
• Remove domains that haven’t had email activity in over six months. Inactive domains often lose their MX records or get shut down. Regular pruning keeps your list lean and deliverable.
• Monitor domain expiration dates where possible—many registrars expose DNS and WHOIS data. A domain that expired last year is unlikely to accept new mail.
• Don’t rely solely on email address syntax checks. A valid format doesn’t mean the domain exists or accepts mail. Real domain validation requires querying DNS.

Prevention is more efficient than fixing bounces. A healthy list starts with knowing what’s not valid before you send.

For reference, the SMTP RFC 5321 specifies that domain names must have a valid DNS MX record to accept mail. When a domain fails this, the MTA returns a 550 5.1.3. Validating this upfront ensures your mail stays in the inbox—not the bounce queue.

Why trusting your ESP to catch this error is not enough

Most ESPs only check email validity after connecting, meaning they miss DNS-level failures like 550 5.1.3 — errors that happen before any SMTP handshake. If the domain doesn’t resolve, your ESP never even tries to send. That’s why relying on your ESP alone leaves you blind to 90% of deliverability risks before they reach your inbox.

DNS-level problems slip through ESP validation

ESP validation typically starts with an SMTP connection. But a domain like example.com might not exist in DNS at all — no MX records, no A records, or a typo in the domain name. Your ESP won’t know until it tries to connect, and by then, it’s too late. A 550 5.1.3 error means the receiving server has already rejected the domain, but your ESP may not catch that until it's out of your control.

Let’s say you’re sending to a list where half the domains are mistyped — gmal.com instead of gmail.com. Your ESP will still try to connect and fail with a 550 error. But this isn’t the original flaw; it’s just the symptom. The real problem — the invalid domain — was ignored until too late.

SMTP handshakes aren’t root-cause diagnostics

Even when an ESP does check during SMTP, it doesn’t always diagnose the failure correctly. A 550 error might mean the server doesn’t accept your IP, the domain is blacklisted, or the email is marked as spam — but it won’t tell you which. Without deeper analysis, you’re left guessing. This makes troubleshooting slow and inefficient.

For example, a catch-all domain might accept your message but still mark it as "valid" in your ESP’s logs — while in reality, it’s a placeholder with no real user behind it. That kind of false positive is common and hard to detect without DNS and MX-level scrutiny.

Pre-verification services scan for domain validity, MX records, and DNS issues before you even send. This catches 550 5.1.3 errors before they happen — no SMTP connection required. Real-time verification tools like our API or bulk validation can check thousands of addresses in minutes, flagging invalids, catch-alls, and disposable domains with precision.

According to the SMTP standard (RFC 5321), the 550 5.1.3 code specifically means "User unknown" at the recipient’s domain — often tied to non-existent or misconfigured domains. But the standard doesn’t tell you how to prevent it. That’s why pre-verification exists: to stop those errors before they ever happen.

Don’t wait for your ESP to tell you the domain doesn’t exist. Check it first.

Clean your list, improve deliverability

Domain unknown errors (550 5.1.3) signal invalid or non-existent domains on your list. These are not temporary issues — they indicate persistent list hygiene problems that drive up bounce rates and hurt deliverability.

Why it matters

When your ESP returns 550 5.1.3, it's rejecting a delivery because the domain doesn't exist or lacks proper DNS records. These failures accumulate, damaging your sender reputation over time. Preventing them starts with eliminating invalid domains before sending.

• 98.9% accuracy in email verification helps spot these errors consistently across large lists.
• Fixing DNS-level issues like missing MX records or invalid domains prevents failed deliveries.
• Proactive validation reduces hard bounces, protecting your sender score and inbox placement.

Keep reading

• Email marketing compliance: GDPR, CAN-SPAM, consent and unsubscribes (complete guide)
• How to Avoid 450 4.2.1 Threshold Exceeded with Email List Cleaning
• Why Mailgun 450 4.2.0 Error Occurs When Re-Engaging Users
• Email Validation to Detect High-Risk Sender Patterns Causing 554 5.7.4 Failures
• Tracking 451 4.7.0 Timeouts in ESPs for Compliance Audits

Ready to put this into practice? Email List Validation verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Is 550 5.1.3 a permanent error?

Yes — it indicates the domain doesn’t exist or lacks DNS records. It will not resolve even with retries.

Can a domain have 550 5.1.3 errors and still accept email?

No — without MX or A records, no mail server will accept messages for that domain.

Why does my list validation show 550 5.1.3 on some domains?

The domains listed are either expired, misspelled, or have no DNS records configured.

How long does it take for a domain to return 550 5.1.3?

It happens immediately after the HELO/EHLO command, while resolving the domain name.

Does 550 5.1.3 mean the email address is invalid?

Yes — if the domain doesn't exist in DNS, the entire address is invalid and cannot receive mail.

Can catch-all domains cause 550 5.1.3 errors?

Only if the domain itself has no valid MX or A records. Catch-alls require a working domain.

Does Email List Validation catch 550 5.1.3 errors?

Yes — it detects missing DNS records before SMTP connection, flagging them as invalid.

How many free verifications does Email List Validation offer?

100 free verifications to get started, with credits that never expire.

Can I use Email List Validation with Mailchimp?

Yes — it integrates directly with Mailchimp, HubSpot, Klaviyo, and SendGrid.

What’s the accuracy of Email List Validation?

98.9% accuracy in identifying valid, invalid, catch-all, and risky email addresses.

Does this error appear in inbox-placement tests?

Yes — domains with 550 5.1.3 errors fail inbox placement testing due to nonexistence.

Should I keep domains that return 550 5.1.3 in my list?

No — these domains will never receive email. Removing them improves deliverability and sender reputation.