API for 550 5.1.2 & MX Check | Email List Validation

Why Does 550 5.1.2 Keep Killing Your Email Campaigns?

You send an email. It bounces. You check the error. "550 5.1.2 user unknown." You don’t know what it means—but you know it means the email never reached a real inbox. And you’re wasting sends on dead addresses.

That one error is a hard bounce. It’s not a temporary glitch. It’s a definitive “this user doesn’t exist.” Without catching it before sending, you’re dragging dead addresses through your list—hurting your sender reputation, inflating bounce rates, and lowering inbox placement. You’re not just sending to no one. You’re harming future deliverability.

A real-time email validation API that checks for 550 5.1.2 user unknown and DNS MX record presence stops that damage before it starts. It doesn’t just say “valid” or “invalid.” It looks for the exact errors that mean your email will fail—so you only send to addresses that have a chance of receiving.

Key takeaways

550 5.1.2 is a definitive hard bounce—meaning the recipient address does not exist on the destination server.
Without pre-verification, these hard bounces degrade sender reputation, increase bounce rates, and hurt deliverability.
An email validation API that checks for 550 5.1.2 and DNS MX record presence prevents sends to non-existent addresses before they leave your system.

How an Email Validation API Prevents 550 5.1.2 Bounces

You prevent 550 5.1.2 bounces by checking each email address against the target domain’s DNS MX records before sending. If no MX records exist, the address is flagged as invalid immediately. For domains with MX records, the API verifies whether the specific user exists. Only when both the domain’s delivery route and the user’s existence are confirmed does the address return as valid. This two-step check stops delivery failures before any SMTP connection is attempted.

The Two-Stage Check That Stops 550 5.1.2 Before It Happens

Check DNS MX records first — The API queries the domain’s DNS zone for MX records. Without them, messages can’t be delivered. If none exist, the email is rejected outright. This step alone catches invalid domains before any further effort is wasted.
Verify user existence on a valid domain — If MX records are present, the API performs deeper validation via SMTP-like probes that mimic the initial connection. It checks whether the specific username (local part) is recognized by the receiving mail server. This detects cases where the domain exists but the user does not.
Flag or reject known bad patterns — The API also checks for common indicators of invalid addresses: role-addresses (like admin@, info@), disposable domains, or suspicious formats, which often trigger 550 5.1.2 responses even if the domain is valid.
Return only proven valid addresses — Only addresses that pass both MX existence and user validation are returned as valid. Any failing address gets a clear verdict (invalid, catch-all, risky) so you avoid sending to known-broken paths.

Let’s be clear: the 550 5.1.2 error isn’t a delivery problem—it’s a user nonexistence problem. It means the mail server knows the domain but can’t find the specified user (RFC 5321, Section 4.2). This is a hard bounce that harms your sender reputation. The moment you send to such an address, you risk being flagged by ISPs.

According to industry benchmarks, emails sent to invalid addresses—especially those returning 550 5.1.2—can lead to increased bounce rates that trigger spam filters. Keeping your bounce rate below 0.5% is a standard benchmark for maintaining deliverability. Automated validation systems like email validation APIs help you meet that target consistently.

Why This Matters in Practice

Imagine sending 5,000 emails and getting 800 550 5.1.2 bounces. You’ve wasted bandwidth, damaged your sender reputation, and possibly triggered temporary blocklists. An API that acts before the SMTP handshake prevents all this.

With real-time email verification, every address is tested against DNS MX records and user existence. You get a verdict in under 500 milliseconds. No more wasted sends, no more false positives, no more surprise bounces.

What '550 5.1.2 user unknown' Really Means in SMTP Terms

The SMTP error 550 5.1.2 user unknown means the recipient’s mailbox doesn’t exist at the destination server. It’s a hard bounce indicating the email address is invalid, returned during the RCPT TO phase when the server checks if the user is known. This error is permanent — retrying will never succeed, and it harms sender reputation if repeated.

How This Error Appears in the SMTP Handshake

Let’s walk through the SMTP transaction. When you send an email, the server first checks the domain’s MX record to find where to deliver mail. If the domain has a valid MX record, the process continues. But during the RCPT TO command, the receiving server validates whether the specific user part of the email (the part before @) is known. If it isn’t, the server returns 550 5.1.2 user unknown.

This happens even if the domain is active and accepting mail. A valid MX record only confirms the domain receives email — it doesn’t confirm that a specific address exists. You can have a working domain with no such user, especially with role addresses (like sales@ or info@) or typos.

Why This Error Matters for Deliverability

Each 550 5.1.2 bounce counts as a hard bounce. Email providers track these and view repeated hard bounces as a sign of poor list hygiene. If your sender reputation degrades, future messages risk landing in spam folders or being outright blocked.

While you can’t fix a missing user address, you can prevent sending to them. An email validation API that checks for 550 5.1.2 errors in real time will detect invalid addresses before they’re sent. It checks for both the presence of a valid MX record and the existence of the mailbox, reducing hard bounces and protecting your reputation.

For example, tools like real-time email verification use SMTP-level checks to catch 550 5.1.2 before you send, so you’re not wasting bandwidth or risking your sender score. Even if the domain is valid, this kind of API can flag addresses that don’t exist, saving you time and preventing delivery issues.

For context, the RFC 5321 — the SMTP standard — defines this response code as a permanent failure for a user not found, reinforcing that this is not a retryable condition. You can find similar guidance on email deliverability from Spamhaus, which notes that persistent hard bounces harm sender reputation and are a red flag for filtering systems.

Validating MX Records Is the First Line of Defense

You can't send email to a domain without MX records—it’s like trying to mail a letter to a non-existent address. The Email List Validation API checks every domain in your list for valid MX records before any further validation. If no MX record exists, the domain is flagged immediately as invalid, preventing wasted sends and reducing bounce risk from the start.

MX Records: The Foundation of Mail Delivery

Every domain that receives email must have at least one MX record in its DNS configuration. These records tell the internet which servers are responsible for handling incoming mail. If a domain lacks them, mail systems won’t accept messages—regardless of whether the address is spelled correctly. That’s why detecting missing MX records early is critical.

Let’s say you’re sending to a list with an old or misconfigured domain like example.ltd. Without MX records, the domain is inherently undeliverable. Trying to send to it will result in a 550 5.1.2 “user unknown” error or a similar hard bounce. Catching that before transmission saves bandwidth, server load, and damage to sender reputation.

How the API Prevents Waste at Scale

With bulk processing, the Email List Validation API checks DNS MX records in real time across your entire list. It doesn’t rely on blacklists or heuristics—it uses the same layer of verification that email systems use. If a domain has no MX record, it’s marked as invalid right away.

This eliminates speculative sends to non-routable domains. You’re not just filtering out typos or disposable emails—you’re removing entire zones of impossibility. It’s a foundational step that reduces post-verification bounces by ensuring only domains with valid mail infrastructure are considered.

For example, if a domain has been decommissioned or never properly set up, no amount of address formatting will fix it. The API spots this in milliseconds, helping you avoid sending to addresses that will always return a routing failure. This step is especially important for high-volume senders aiming for inbox placement—your sender reputation suffers with every failed delivery, even before message content is evaluated.

You can test this verification process on your own list with real-time bulk email list cleaning to see how many invalid domains are removed before a single message is sent.

How Catch-All Domains Skew Email Validation Results

When an email domain accepts all messages—even for non-existent users—it creates false positives in validation. These catch-all setups reply “delivery successful” to every address, making invalid emails appear valid. This skews your list accuracy, harms deliverability, and wastes sends. The Email List Validation API detects this by probing the mail server during verification, identifying when a domain accepts all incoming mail regardless of user existence. It flags such addresses as ‘risky’—not invalid, but not reliably deliverable to a specific person.

Why Catch-All Domains Lie to Your Validation Tool

Let’s say you’re verifying an old customer email like [email protected]. The domain accepts all mail, so the server responds with a 250 OK, even if john doesn’t exist. That’s a successful SMTP handshake, but not a successful delivery. Validation tools that only check MX records and syntax will call this address valid. But it’s not valid in practice—no one receives the email, and your campaign fails.

Many large organizations, especially in B2B, use catch-all domains for operational simplicity. However, this practice inflates list size and hides dead or non-existent recipients. According to RFC 5321, the SMTP protocol doesn’t require a server to reject mail for unknown users—it only requires a response. This makes catch-all domains technically compliant, but practically misleading for email campaigns. You can’t assume a delivery confirmation proves a user exists.

How Email List Validation Stops the False Positives

Our API doesn’t stop at DNS and syntax checks. It performs a real SMTP-level connection and simulates the message submission process. If the server accepts mail for any address without validating the user, the API detects the catch-all behavior and marks the address as ‘risky’.

This isn’t a guess. It’s based on observed server responses during the verification process. A true, individual mailbox would reject an invalid user with a 550 5.1.2 “user unknown” error. But catch-all domains return a 250 OK, regardless. The API logs this behavior and applies the risk flag accordingly—keeping your list clean from unreliable addresses.

For teams running targeted campaigns, this distinction matters. An address marked as ‘risky’ isn’t a bounce, but it’s also not guaranteed to reach a real person. You can choose to keep it, but you should treat it as high risk. Real-time verification ensures you catch this before sending.

Use a trusted email validation API that goes past basic checks. Test your list with tools that inspect how the server actually behaves during delivery. If you're verifying at scale, see how our bulk verification service helps you clean entire lists with precise risk flags: clean and verify your entire email list.

Real-Time API Checks for 550 5.1.2 and MX Record Presence

Our email validation API checks for the 550 5.1.2 error and verifies DNS MX record presence by performing real-time SMTP and DNS lookups—no heuristics, no guesswork. It confirms whether an email address is deliverable by testing actual infrastructure, returning precise verdicts like valid, invalid, catch-all, or risky based on empirical results. You can trust it to surface bounces before they impact your sender reputation, and integrate it quickly with your existing workflows via REST.

How It Works: Protocol-Compliant Checks, Not Guesswork

Let’s be clear: this isn’t about pattern matching or fuzzy logic. Each verification query follows the actual SMTP and DNS protocols. First, we resolve the domain’s MX records—if no MX record exists, the email fails. Then we attempt a live SMTP connection to the mail server. If the server responds with 550 5.1.2 ("User unknown"), we flag it as invalid with a machine-readable code.

This is a standard outcome in the email ecosystem. According to RFC 5321, the 550 5.1.2 error code explicitly means the recipient user does not exist. Our API detects this exactly as it would in any production email transaction, so you’re not relying on a database of known bad addresses—only real-time validation.

Clear, Actionable Results You Can Depend On

When an address fails due to 550 5.1.2, the API returns the exact error code, along with a verdict of invalid. This eliminates ambiguity. You’re not left wondering why a delivery failed—your system gets a precise signal, so you can clean your list and avoid wasted sends.

The same applies to catch-all domains. If the server accepts the recipient, but we can’t confirm the mailbox exists, we return catch-all. This lets you decide whether to proceed, based on real behavior. No false positives from pattern-matching heuristics. Just facts from active infrastructure.

Integration is straightforward. Whether you're verifying a single address or validating thousands in bulk, the API supports both via REST. You can embed it directly into your sign-up flow, CRM, or email campaign pipeline. With no time limits on purchased credits, your list stays clean across multiple campaigns.

For teams that need a full workflow, you can start with our real-time verification API and connect it to tools like Mailchimp, HubSpot, or SendGrid through our pre-built integrations. The system is designed to work in production environments without adding latency. You get accuracy without compromise.

Why 550 5.1.2 Errors Are a List Hygiene Emergency

Every 550 5.1.2 error—indicating a recipient user doesn’t exist—is a red flag that your list is breaking deliverability rules. These hard bounces directly increase your bounce rate, which signals poor sender hygiene to email providers. If left unaddressed, this risks list suppression and domain-level blocking, even if your content is compliant and relevant. Proactively validating your list prevents this cascade.

How 550 5.1.2 Bounces Harm Your Sender Reputation

Every 550 5.1.2 hard bounce counts toward your overall bounce rate. A rate over 2% commonly triggers spam filters or domain-level filtering.
Email providers like Gmail and Outlook use bounce rate as a key signal in their inbox placement algorithms.
High bounce rates correlate with reduced sender reputation, even if your content is acceptable—this is not about message quality, but list hygiene.
Reputable providers use RFC 5321 and RFC 5322 standards to define recipient validation—DNS MX records must resolve and the user must exist.
A clean list with under 1% bounce rate consistently achieves higher inbox placement and trust scores.

Prevent Bounces Before They Happen

You can’t fix deliverability after the fact if your list contains invalid addresses. Prevention is the only scalable defense.
The Email List Validation API checks for 550 5.1.2 errors by validating DNS MX records and confirming mailbox existence before sending.
It detects invalid addresses with accuracy above 98.9%, including catch-all domains, role accounts, and disposable email patterns.
Using the real-time email verification API lets you catch errors at point of capture—before they enter your list.
It’s not just for one-time cleanup. The API enables continuous maintenance, so your list stays accurate across campaigns, segments, and time.
Unlike point-in-time validators, it integrates across your stack—Mailchimp, HubSpot, Klaviyo, SendGrid—to enforce hygiene from signup to send.

For a deeper look at how mailbox validation aligns with email delivery standards, refer to the SMTP RFC and Spamhaus guidelines on valid email infrastructure.

How We Test for 550 5.1.2 and MX Records in Practice

We verify email addresses by connecting directly to the recipient’s mail server using real SMTP sessions. Each address is tested against the domain’s actual MX records in sequence. If the server responds with 550 5.1.2 during RCPT TO, the address is invalid. If the same code appears during MAIL FROM, the domain itself fails DNS validation. We do not use third-party databases or pattern matching — only live server responses.

The Real-Time SMTP Validation Process

Retrieve the target domain’s MX records using authoritative DNS queries. We only proceed with domains that have valid, reachable MX records — a basic requirement for email delivery. This prevents wasted attempts on non-existent or misconfigured domains.
Initiate a live SMTP connection to the top-priority MX server. This mimics how mail servers actually communicate. We do not rely on cached data or lookup tables.
Begin the transaction with MAIL FROM. If the server responds with 550 5.1.2 at this stage, the domain itself is invalid. This is a clear signal the domain is not accepting mail — no further checks are needed.
Test the email address with RCPT TO. If the server replies with 550 5.1.2, the user does not exist. This message code means "User unknown" — a definitive indicator of an invalid address.
Log and classify the result. We record the exact server response, timestamp, and connection details. All validation is based on real, live server behavior — not inference.

Why this matters: Many services rely on pattern-matching or third-party databases that can’t detect real-time server behavior. We don’t guess. We test.

The 5 steps described in “The Real-Time SMTP Validation Process”, in order.

Why We Don’t Use Databases or Patterns

Third-party email validation tools often depend on large databases of known bad addresses or heuristics like "does it follow a common pattern" — a poor proxy for actual deliverability. These methods fail when a new, valid address is added or when a domain changes its mail system.

According to RFC 5321, section 4.1.1, the 550 5.1.2 response code is specifically defined as "User unknown" and should only be sent during the RCPT TO phase when a recipient doesn’t exist. This is the standard — and we follow it.

Our approach is transparent: we don’t mask failures behind false positives. If a server says an address is unknown, we report it as such. If it says nothing, we return "risky" — because the server is unreachable or misconfigured.

For teams that need to validate hundreds of emails in real time, our real-time verification API automates this entire process. It’s built for scale, accuracy, and full traceability.

Email List Validation API: Verdicts You Can Trust

Our Email List Validation API checks each address against real SMTP servers and DNS records, giving you four precise verdicts: Valid (MX exists, mailbox confirmed), Invalid (no MX or 550 5.1.2 error), Catch-all (domain accepts all addresses), or Risky (delivery delays or limits detected). You’re not guessing — you’re seeing what the mail server actually says.

How We Verify, Not Just Guess

Let’s cut through the noise: we don’t rely on heuristics or pattern matching. Instead, we simulate real delivery attempts. When we see a 550 5.1.2 "User Unknown" error, we flag it as invalid. When a domain lacks a proper MX record, we mark it as invalid. If the server accepts mail for any address, we label it Catch-all — not a mistake, just a risk.

The Verdicts, Clear and Actionable

Here’s what each result means in practice:

Verdict	What It Means	What To Do
Valid	MX record exists, SMTP session completes, mailbox exists.	Send with confidence. These are your best leads.
Invalid	No MX record, or server returned `550 5.1.2` (user unknown).	Remove immediately. These addresses will bounce for sure.
Catch-all	Domain accepts mail for any address, but we can’t confirm the user exists.	Flag for caution. High bounce risk if used in production campaigns.
Risky	MX exists, but server replies with greylisting delays, rate limits, or 4xx errors.	Delay sending or test before full rollout. Avoid bulk use.

These rules are based on SMTP standards and real mail server behavior. RFC 5321 outlines how mail servers respond to delivery attempts — we follow the same logic. This is not speculative. It’s how email actually works.

For example, a RFC 5321 compliant server will return a 550 5.1.2 when a mailbox doesn’t exist, and we respect that. A catch-all domain doesn’t care — it accepts every address, but that doesn’t mean it’s real. We don’t ignore that risk.

Use your list with certainty. Real-time validation via API lets you clean data as it comes in. Or, bulk validate large lists before sending. Both paths lead to better deliverability and lower bounce rates.

See how it works: integrate the Email List Validation API directly into your pipeline.

How This API Fits Into Your Existing Workflows

You can plug this email validation API directly into Mailchimp, HubSpot, Klaviyo, or SendGrid to clean your lists before sending, stop invalid sign-ups at the source with real-time checks, and proactively fix old lists with bulk verification. It doesn’t replace your existing tools—it works alongside them to keep your deliverability clean and your send rates high. For context, 550 5.1.2 user unknown errors often stem from invalid or non-existent mailboxes, and DNS MX record presence confirms a domain can receive email—both are critical to avoid hard bounces and sender reputation damage.

Automate List Cleaning Before Every Send

Connect the API to your email service provider (ESP) via integrations with Mailchimp, HubSpot, Klaviyo, or SendGrid to validate every list before a campaign goes live.
Run bulk verification on existing databases—no matter the size—to flag addresses returning 550 5.1.2 or failing DNS MX checks before you send.
Use the bulk list cleaning tool to process thousands of emails in minutes and identify inactive, malformed, or non-existent addresses.

Validate in Real Time, At Scale

Embed the real-time API into your sign-up forms, onboarding flows, or CRM data entry points to validate emails on input—catching typos, disposable domains, or invalid addresses before they enter your system.
Let the API check for 550 5.1.2 and MX record presence automatically—ensuring only deliverable email addresses reach your database.
Use the built-in real-time verification API with your own apps or custom forms for complete control over data quality at the point of entry.

Results aren’t just binary. The API returns specific codes: valid, invalid, catch-all, risky, or syntax error. The in-app AI assistant helps explain what each means and guides you toward actionable fixes—like separating role accounts or re-validating addresses flagged as potentially disposable.

Start with 100 free verifications—no strings attached, no expiry on future purchases.
Use the pricing page to see how credits work without time pressure, allowing you to plan cleanups over time without rush.
For deeper insights, test inbox placement with tools like inbox placement testing—a real-world check that goes beyond validation to confirm whether your messages actually land in inboxes.

SMTP, DNS, and DMARC are all behind the scenes. You don’t need to debug them—but you do need to ensure your emails are delivered. The API checks what matters: can the address receive mail? Does it follow the standard? If not, it flags it. That’s how you stop bounces, avoid blocklists, and protect your sender reputation.

Final Word: Your List Is Only as Good as Its Most Invalid Address

An email validation API that checks for 550 5.1.2 user unknown and DNS MX record presence doesn’t just catch bad addresses—it stops them from harming your sender reputation from the start.

Every invalid address you send to risks triggering spam traps, increasing bounce rates, and weakening your domain score. Real-time SMTP and DNS verification ensures you’re not relying on outdated or incomplete data.

Choose tools that validate through live checks, not just database lookups. Transparency in how results are determined matters—your inbox placement depends on the quality of every address you send.

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 550 5.1.2 mean in email delivery?

It means the recipient mailbox does not exist. It's a hard bounce that cannot be resolved by retrying.

Can an email domain have MX records but still return 550 5.1.2?

Yes. MX records indicate mail routing, but a user may not exist. The API detects this mismatch.

Does checking MX records prevent all 550 5.1.2 errors?

No—but it prevents sending to domains without mail servers. Only SMTP verification confirms user existence.

How accurate is real-time email validation with MX and 550 checks?

Our API achieves 98.9% accuracy by using actual SMTP and DNS checks, not heuristics.

Can catch-all domains pass an email validation API test?

Yes, but the API flags them as 'risky'—not valid—because delivery can’t be guaranteed to a specific user.

Do I need to worry about greylisting when validating emails?

Yes. The API detects greylisting behavior and marks affected addresses as risky.

How does Email List Validation compare to free email checkers?

Free tools often use data lookups. Ours uses real SMTP and DNS checks—more reliable, accurate, and transparent.

What integrations does Email List Validation support?

It integrates with Mailchimp, HubSpot, Klaviyo, and SendGrid for automated list cleaning before sending.

Yes. The API is designed for real-time validation of new email addresses at sign-up or onboarding.

Do purchased credits expire?

No. Credits never expire, so you can accumulate and use them at your pace.

What is the difference between a catch-all and a valid address?

A catch-all accepts all mail sent to the domain, even for non-existent users. A valid address exists and can receive mail.

How does invalid email detection improve sender reputation?

By reducing hard bounces, which ISPs use to assess sender reliability. Avoiding 550 5.1.2 errors helps maintain reputation.