Fix Email Server Error 550 5.1.2 | Email List Validation

What Causes SMTP Error 550 5.1.2: Unknown Domain Resolution?

You send a campaign, and it bounces. The error says: “550 5.1.2 unknown domain resolution.” Not a spam verdict. Not a blocked sender. Just a hard stop at the door.

This isn’t about your message content or reputation—it’s about whether the domain in the email address even exists on the internet. If the domain can’t be resolved to an IP address via DNS, the mail server says “no entry” before even reading your message.

Key takeaways

SMTP error 550 5.1.2 occurs when a domain fails DNS resolution, meaning the domain doesn’t exist or isn’t properly configured.
This is a hard bounce caused by a domain-level failure, not spam, reputation, or content issues.
Correcting invalid domains before sending prevents wasted sends, improves deliverability, and protects sender reputation.

Why Domain Lookup is the First Step to Fixing Email Server Error 550 5.1.2

When your email bounces with error 550 5.1.2 — "unknown domain" — it means the recipient’s domain doesn’t resolve in DNS. No amount of correct mailbox checks will help if the domain itself doesn’t exist or can’t be reached. A domain lookup confirms whether the domain has valid MX records, A records, and proper email routing policies. Without this, delivery is impossible, regardless of the rest of the email address.

Domain Lookup Reveals the Foundation of Deliverability

Every email sent must first resolve to a working mail server through DNS. If the domain doesn’t have an MX record, or if the A record points to a server that doesn’t accept mail, delivery fails at the gate. Let’s be clear: an email can’t reach a mailbox if the domain doesn’t even exist in the global DNS system. This is why 550 5.1.2 isn’t a spam filter issue — it’s a basic infrastructure failure.

Checklists for SMTP delivery often miss this step. You might assume a domain is active because it has a website, but websites and mail servers use different DNS records. A domain can resolve via A records for HTTP but lack MX records for email. That’s why domain lookup is the first real diagnostic. It separates domains that are simply inactive from those that are misconfigured or intentionally unreachable.

Why 550 5.1.2 Is Different From Other Bounces

Many bounces — like 550 5.1.1 or 550 5.1.3 — can be ambiguous. They might indicate blocked mailboxes, temporary server issues, or content filtering. But 550 5.1.2 is unambiguous: the domain is not known to the receiving system. It’s a hard rejection. This isn’t a soft failure that might resolve on retry; it’s a structural problem.

It’s common for senders to assume a failed delivery means “spam” or “user not found,” but those are often symptoms of deeper DNS misconfigurations. In reality, over 75% of 550 5.1.2 bounces stem from non-existent domains or missing MX records — not mailbox issues. This is why tools like bulk email list cleaning focus on domain validation before sending: you can’t fix a non-existent domain after the fact.

For real-time verification, the same principle applies. Before sending, validate that the domain resolves and has email routing policies in place. This is not a luxury — it’s a necessity. For more on how to verify domains at scale, you can explore our real-time email verification API. The RFC 5321 specification (available via IETF RFC 5321) formalizes how mail servers should reject messages when a domain is unknown, reinforcing that this error is not optional — it’s protocol-driven.

How to Diagnose a Missing or Invalid Domain with Basic DNS Tools

You can quickly check if an email's domain is valid by querying its DNS records using command-line tools like dig or nslookup. If the domain returns NXDOMAIN or no response at all, it’s not registered in DNS or lacks a configured mail server—common causes include typos, expired domains, or misconfigured DNS. A simple query can confirm whether the domain exists before you send, preventing delivery failures like error 550 5.1.2.

Step-by-step DNS diagnosis

Run a DNS lookup for the domain’s MX records: Use dig MX example.com or nslookup -type=MX example.com. This checks if the domain has a mail server configured. If it returns nothing or NXDOMAIN, the domain doesn’t exist in DNS or doesn’t support email.
Check for common typos: A single typo—like gmai.com instead of gmail.com—can trigger a 550 error. These slip in when copying from spreadsheets or documents. Verify the spelling matches the official domain.
Confirm DNS registration status: Use ICANN's WHOIS lookup to check if the domain is registered and active. An expired domain won’t resolve in DNS, making it impossible to deliver to.
Look for DNS misconfiguration: Even if a domain exists, it might lack an MX record, a TXT record for SPF, or DKIM. Without these, mail servers reject messages with a 550 or similar error. Use dig TXT example.com to check for record presence.
Validate the root domain: Some services allow email routing via subdomains (e.g., mail.example.com), but the main domain must still resolve. Ensure the top-level domain is valid and properly configured.

When to consider automation

If you’re verifying hundreds of emails, manual DNS checks are impractical. Tools like bulk email list cleaning can flag invalid domains at scale, catching typos, expired domains, and missing MX records before sending. It’s not just faster—it’s more reliable than checking each one by hand.

The 5 steps described in “Step-by-step DNS diagnosis”, in order.

Even a single invalid domain in a list can reduce deliverability by causing hard bounces and hurting sender reputation over time.

Use these steps to isolate problematic domains before sending campaigns. It turns a vague error into a fixable configuration issue. With the right tools, you can catch domain-level problems early—and avoid the cost of failed deliveries.

Domain Lookup vs. Email Verification: What’s the Difference?

Domain lookup only confirms if a domain exists in DNS—no mailbox, deliverability, or server response signals are checked. Email verification goes further: it tests the full delivery path, including DNS resolution, SMTP handshake success, server behavior (like greylisting), and whether the mailbox accepts mail. A domain may resolve, but still reject messages due to spam filters, rate limiting, or policy rules. That’s why relying only on domain lookup leaves you exposed to bounces and deliverability issues.

Why DNS Resolution Isn’t Enough

Just because a domain appears in DNS doesn’t mean it accepts incoming mail. Many domains exist but block messages from unknown senders or have strict filtering rules. Some use greylisting—delaying delivery until a retry is sent—so an initial check won’t catch that. Others reject mail based on sender reputation or IP reputation, not domain existence.

Let’s say you’re sending to a user at example.com. A domain lookup says it exists. But if example.com uses a mail server that requires authentication, or if it’s filtering incoming traffic based on IP reputation, your email may still fail—even though the domain is valid.

How Real-Time Verification Works

Email verification tools simulate an actual delivery attempt. They start with DNS checks to confirm the domain exists, then initiate an SMTP handshake. They analyze the server’s responses—like 550 errors, delays due to greylisting, or temporary failures—to predict whether someone can actually receive your message.

This process includes checking for role accounts (like admin@, support@) and disposable email addresses, which often resolve in DNS but are never used for real communication. Tools like Email List Validation perform these checks at scale with an accuracy rate of 98.9%, helping you avoid wasted sends.

By combining domain lookup with real-time SMTP testing and behavioral signals, you get a much clearer picture than DNS alone. This isn’t just theory—industry standards like RFC 5321 and RFC 5322 define how mail servers should respond, and tools like Email List Validation follow those protocols to assess inbox delivery likelihood.

If you’re cleaning a large list, you’re not just checking domains—you’re testing whether mail can actually arrive. For this, go beyond DNS. Use a fully featured email verification tool to test the real delivery path: clean your entire list with real-time validation.

The Role of Bulk Verification in Preventing 550 5.1.2 Errors

You prevent 550 5.1.2 errors by validating every email address in your list before sending—specifically checking for domains that lack MX or A records. This catches invalid domains, typos, and non-existent addresses before they trigger hard bounces and damage your sender reputation.

Stop Invalid Domains Before They Fail

Every email sent to a domain with no DNS records will fail at the SMTP level, resulting in a 550 5.1.2 error. Bulk verification flags these domains in advance, so you’re not sending to ghost addresses or typos like exmple.com or gmaill.com. The difference between sending to 10,000 valid addresses and 10,000 broken ones is measurable: one keeps your reputation intact, the other can trigger blacklists.

Let’s say you’re sending a campaign to a list of 15,000 emails. Without verification, 2–5% might have invalid domains—many of which you'd never know were broken until the server rejects them. With bulk validation, you identify and remove those before sending. This isn’t guesswork. It’s DNS-level testing: checking for MX records (for mail delivery), A records (for mail server reachability), and proper SPF/DKIM alignment.

High-Volume, High-Accuracy Checks at Scale

Email List Validation checks over 5,000 domains per hour with 98.9% accuracy. It doesn’t just look at the domain—it simulates the delivery path, verifying the DNS setup in real time. This allows you to clean massive lists quickly, without waiting days to learn you hit 300 hard bounces.

For example, a typo like hotmaill.com might look like a real email, but it has no MX record. A verification tool spots that instantly. A real-time API can validate individual emails as they’re added to a list, preventing invalid entries altogether. If you’re using HubSpot, Mailchimp, or Klaviyo, you can integrate automated verification that works with those systems without friction.

Reducing bounce rates below 0.5% is a key deliverability benchmark. When you keep hard bounces low, ISPs like Gmail and Outlook treat your domain as trustworthy. You avoid reputation damage, reduce the risk of being flagged by blacklists like Spamhaus, and increase inbox placement. You might not see the 550 5.1.2 error—because you never sent to a domain that couldn’t resolve in the first place.

When you're ready to verify your list at scale, clean your entire list in minutes and get a report showing which domains failed and why. No trial, no risk—start with 100 free verifications.

How Email List Validation Detects and Reports 550 5.1.2 Issues

When an email bounce returns a 550 5.1.2 error, it means the recipient’s domain couldn’t be resolved—either because it doesn’t exist or lacks proper DNS records. Email List Validation identifies this by checking for the presence of an MX record and successful DNS resolution during verification. If the domain fails to resolve or has no MX record, the tool flags it as 'invalid' with the specific reason: 'unknown domain' or 'no MX record'. This prevents you from sending to non-existent addresses, reducing bounces and protecting your sender reputation.

DNS and MX Checks Are Foundational

Before attempting delivery, we run a full DNS lookup to confirm the domain exists and has a properly configured MX record. This mimics what an actual mail server would do. If the domain fails to resolve—whether due to typos, expired registrations, or misconfigured DNS—we know the email can’t be delivered. This detection happens at the pre-verification stage, not after a failed SMTP attempt.

For instance, a domain like example.com must have an MX record pointing to a receiving mail server. If it doesn’t, the server will reject the email with a 550 5.1.2 code. Our system checks this directly, using standard DNS protocols defined in RFC 1035 and RFC 5321—commonly used to govern mail routing.

Clear Verdicts, Real SMTP Behavior

We don’t guess. Every email result maps directly to observed SMTP responses. You get one of five verdicts: valid, invalid, catch-all, risky, or unknown domain. 'Unknown domain' specifically means the domain doesn’t resolve in DNS—exactly the root cause of a 550 5.1.2 error.

These outcomes are not speculative. They’re based on real-time responses from DNS queries and simulated SMTP handshakes. We don’t rely on pattern matching alone. If a domain fails to resolve, the system returns 'unknown domain' with a clear reason—and no chance of false positives.

Bulk list verification scans thousands of addresses in minutes, flagging every 550 5.1.2 scenario before you send. It’s a fast, accurate way to clean your list at scale.

Common Red Flags in Email Lists That Lead to 550 5.1.2

When your mail server returns error 550 5.1.2 "unknown domain resolution," your list likely contains invalid, outdated, or misconfigured domains. These include expired domains, typosquatting domains, recently registered domains without DNS propagation, or domains that once hosted email but no longer have MX records. Checking for these red flags before sending can prevent bounces and protect your sender reputation.

Expired or Misconfigured Domains

Domains with expired registrations often fail DNS resolution entirely. If a domain registrar lets it lapse, DNS records — including MX records — disappear, leading to 550 5.1.2 errors. You can check domain status through WHOIS, but it’s time-consuming at scale.
Some domains have no active mail server configuration. Even if the domain is registered, the absence of valid MX records or SPF/DKIM alignment makes delivery impossible. This often happens with old business domains that no longer support email.

Typo-Driven & New Domain Issues

Common typo domains like gmial.com or gmaill.com are not only incorrect but frequently used for mail collection scams. These domains have no valid infrastructure and are blocked by most MTAs. Always flag and remove such addresses.
Recently registered domains, especially those less than 24–48 hours old, may not yet have fully propagated in global DNS. While some DNS resolvers may return a response, receiving servers can still fail to resolve them, resulting in 550 errors. Waiting 72 hours is ideal, but you can test validation status via real-time tools.
Domains that once accepted mail but now lack MX records (e.g., discontinued services or migrated emails) are a major red flag. The email may resolve but fail to deliver because the receiving server has no route to accept it. This is often silent in basic checks but detected by deeper validation.

Preventing 550 5.1.2 errors starts with cleaning your list before sending. Tools like bulk email list cleaning test domain validity, detect typos, and verify DNS and MX configuration in real time. This reduces bounce rates and maintains sender reputation. For ongoing campaigns, an API integration lets you verify new sign-ups instantly, avoiding invalid data from ever entering your system. You can also use inbox placement testing to simulate delivery before sending at scale. Always verify the integrity of your domain foundation — DNS, MX, and SPF records — as a baseline. For more details on email validation mechanics, RFC 5321 defines the SMTP protocol and resolution requirements for mail delivery.

How to Use Email List Validation to Fix Your 550 5.1.2 Errors

You can fix 550 5.1.2 "unknown domain resolution" errors by running your email list through a bulk verification tool that checks domain DNS records and mailbox responses. This isolates invalid or mistyped domains before you send, preventing bounces and protecting your sender reputation. Let’s walk through how Email List Validation handles this.

Run a Bulk Verification to Diagnose the Issue

Upload your list to Email List Validation's web app or use its real-time API. This starts a full check on every address, including domain-level checks like MX record resolution and DNS reachability.
The system performs actual SMTP-level checks to confirm the domain exists and accepts mail. It’s not just checking DNS—this includes validating that the domain is properly configured and open to incoming mail, which is how it detects "unknown domain" errors like 550 5.1.2.
After processing, the tool assigns a verdict for each address: valid, invalid, catch-all, risky, or unknown domain. The "unknown domain" status specifically flags addresses where the domain fails DNS resolution, often due to typos or non-existent domains.

Filter and Correct Problematic Addresses

Use the platform’s filtering tools to isolate all entries marked as "unknown domain" or "invalid". These are the exact addresses that will trigger SMTP error 550 5.1.2 during delivery.
Remove them from your list before sending. You can also use the in-app AI assistant to spot patterns—like .com being miswritten as .cm or .co—which reveals common typos across your list.
For high-value contacts, use the email finder to recover the correct address when your list has a known first name and company.
Once cleaned, your list contains only domains that resolve and accept mail. Sending only verified addresses reduces bounce rates and helps maintain a healthy sender reputation—key to avoiding spam filters and blocklists.

Domain resolution issues like 550 5.1.2 are often preventable. According to RFC 5321, when a receiving server cannot resolve a domain’s MX record, it returns a 550 error with code 5.1.2. A pre-send validation step catches these issues before they hit your inbox.

Even a single invalid domain in your list can trigger a bounce, harm deliverability, and hurt your brand’s trust with email providers.

Integrating Verification with Mailchimp, SendGrid, Klaviyo, and HubSpot

You can prevent email server error 550 5.1.2 by validating your mailing list before syncing with Mailchimp, SendGrid, Klaviyo, or HubSpot. Email List Validation plugs directly into these platforms, automatically filtering out invalid domains and catch-all addresses before they hit the send queue. This stops bounces at the source, protecting your sender reputation and inbox placement.

Prevent Bounces Before They Happen

When you sync a list from Mailchimp to SendGrid, every email enters an automated validation pipeline. Invalid domains—those that fail DNS resolution or lack an MX record—are caught and blocked. This includes domains that no longer exist, are misspelled, or have been decommissioned. By stopping these 550 5.1.2 errors before delivery, you avoid the damage they cause to your return rate and sender reputation.

Our integration works in real time with Mailchimp, SendGrid, Klaviyo, and HubSpot. After you connect your account, you can trigger a bulk validation prior to any campaign. The platform returns a clean list with only valid, deliverable addresses. For teams using automated workflows, you can schedule re-verification during re-engagement campaigns or list segmentation to maintain quality over time.

Automate & Scale Without Waste

Think of list validation as a pre-flight check for your email campaigns. With Email List Validation, you don’t need to guess. Once verified, only domains that resolve to actual mail servers proceed to send. This aligns with best practices from organizations like RFC 5321 and Spamhaus, both of which emphasize proper DNS and MX resolution as foundational to email delivery.

Re-verification during segmentation—say, when filtering inactive users—keeps your list current. This is especially important when reactivating dormant subscribers or running win-back campaigns. Every verification uses one of your credits, and unlike other services, your purchased credits never expire. This flexibility means you can validate as often as needed without overpaying or losing unused allocations.

For ongoing use, our integration hub supports seamless setup across all major ESPs. You can also pull verified data into your CRM, sync via API, or use the real-time verification API for dynamic validation in customer onboarding.

What Happens If You Ignore 550 5.1.2 Errors?

Ignoring 550 5.1.2 errors—where an email server rejects a message due to an unknown domain—isn’t just a technical oversight; it’s a direct hit to your deliverability. You’re sending to addresses that don’t exist, which inflates hard bounces, damages your sender reputation, and can get your domain blocked. This hurts every campaign, even those to valid addresses.

Here’s what happens when you don’t act:

You generate hard bounces for every invalid domain. Most email providers treat repeated hard bounces as a red flag, and can flag your domain as unreliable.
Reputation systems like SenderScore monitor bounce rates and domain health. A spike in 550 5.1.2 errors lowers your sender score, directly reducing inbox placement across Gmail, Outlook, and Yahoo.
Email providers with strict filtering policies—like Google and Microsoft—start throttling or outright blocking mail from domains with high bounce rates, even if your content is clean.
Each unverified address wastes your bandwidth and campaign resources. If you're sending 10,000 emails and 20% are invalid, you’re burning time and money on destinations that can never receive mail.
Even small bounce spikes can trigger outbound security policies in platforms like SendGrid or Amazon SES, which automatically pause sending until thresholds are corrected.

The real risk isn’t just delivery—it’s sustainability

Once a domain gets blacklisted—or even flagged as high-risk—recovery takes weeks. According to Spamhaus, it’s not uncommon for domains with frequent 550 errors to be added to reputation-based blocklists, even if they haven’t sent spam.

Let’s be clear: a single 550 5.1.2 error is not a crisis. But ignoring them at scale? That’s a signal to email providers that you’re not managing your list responsibly. The system assumes if you can’t fix a missing domain, you won’t fix anything else.

Use real-time verification before every send. You can catch 98.9% of unknown domains before they ever hit your ESP. The cost of a small validation check is negligible compared to the cost of being blocked.

Check your list before you send. Clean it with a trusted tool that checks MX records, domain existence, and syntax—without inflating your bounce rate. Run a bulk verification today to find and remove 550 5.1.2 errors before they hurt your reputation.

Preventing 550 5.1.2 Errors: A Proactive List Hygiene Strategy

Mail server error 550 5.1.2 often stems from invalid or misspelled domains, unresolvable DNS records, or outdated list data. Preventing it starts long before the send—by ensuring your list is clean and resolved.

Run verification before every major campaign, especially with cold outreach or re-engagement. Use real-time validation at the point of capture to stop bad addresses at the source. Audit your list regularly to remove inactive, malformed, or non-existent domains.

Track error codes over time to spot patterns—like recurring 'gmal.com' typos—indicating data quality issues. Combine email validation with filtering for role accounts, disposable domains, and catch-all addresses to maintain peak list health and sender reputation.

Keep reading

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

Frequently asked questions

What does email server error 550 5.1.2 mean?

It means the recipient domain could not be resolved via DNS. The domain either doesn’t exist, has no mail server, or has a configuration issue.

Can I fix 550 5.1.2 errors by correcting typos?

Yes—common causes include misspelled domains like 'gamil.com'. Correcting these after verification prevents the error.

Does email verification catch 550 5.1.2 errors?

Yes—via DNS and MX record validation. A domain that fails to resolve will be flagged as 'invalid' or 'unknown domain'.

How accurate is Email List Validation in detecting invalid domains?

It achieves 98.9% accuracy across bulk and real-time verification, including detection of invalid domain resolution.

Can I verify email lists before sending with SendGrid or Mailchimp?

Yes—Email List Validation integrates directly with SendGrid, Mailchimp, Klaviyo, and HubSpot for pre-send validation.

Do purchased credits ever expire?

No—credits never expire. You can use them anytime, even months after purchase.

Why does my email bounce with 'unknown domain' instead of 'user unknown'?

A 'unknown domain' bounce (like 550 5.1.2) occurs at the DNS level, not at the mailbox level. It means the domain doesn’t exist or can’t be resolved.

Is DNS lookup the same as checking if a domain accepts mail?

No—DNS lookup only confirms existence. Mail acceptance requires an SMTP handshake. Verification tools simulate both.

How does Email List Validation handle catch-all domains?

It identifies them as 'catch-all' and flags them as 'risky'—they can receive mail but often lead to poor engagement and spam traps.

What is the benefit of integrating with HubSpot or Klaviyo?

It validates leads or contacts before syncing, avoiding hard bounces and protecting sender reputation across campaigns.

Can I use Email List Validation to find the right email address?

Yes—it includes an email finder that locates valid addresses using company domain data and public sources.

Do real-time API checks support bulk domain validation?

Yes—real-time API enables high-speed validation of domains and addresses, ideal for onboarding or dynamic form validation.