Stop 550 5.1.2 Errors in SendGrid | Email List Validation

Why does SendGrid return 550 5.1.2 unknown domain errors?

You send a campaign. The queue clears. Then, a few hours later, you see a batch of hard bounces with the error: 550 5.1.2 unknown domain. Not a typo. Not a glitch. It’s real. And it’s killing your deliverability.

This error means SendGrid tried to deliver your message, but couldn’t find the domain part of the email address in DNS. No MX record. No domain. Or a misconfigured one. Either way, the address is unreachable — and your sender reputation takes a hit for every failed attempt.

These aren’t just soft errors. Each one counts as a hard bounce. You’re not just wasting sends — you’re training filters to mark your future messages as spam.

Key takeaways

550 5.1.2 errors occur when the domain in an email address has no valid DNS configuration, including missing or invalid MX records.
SendGrid immediately hard bounces messages to domains that fail DNS resolution, which harms sender reputation and inbox placement.
Pre-delivery domain validation catches these issues before sending, reducing bounces and protecting deliverability.

How pre-delivery domain validation prevents 550 5.1.2 errors

Pre-delivery domain validation stops 550 5.1.2 unknown domain errors by checking if a domain’s DNS records exist and are properly configured before sending. You catch invalid or non-existent domains early—before they ever hit SendGrid’s SMTP gateway—reducing bounces and protecting your sender reputation. Let’s break down how this works.

The mechanics behind 550 5.1.2 errors

When you send to an email address, SendGrid checks the domain’s MX records via DNS. If the domain doesn’t exist, has no MX record, or is misconfigured, the SMTP server responds with a 550 5.1.2 error.

This is not a temporary issue. It’s a hard failure. The recipient server isn’t just rejecting the message—it’s saying the domain itself doesn’t exist. If you send to hundreds or thousands of such addresses, you’re wasting resources and risking reputation penalties.

How domain validation stops failures before they happen

Instead of relying on SendGrid to catch these errors during delivery, you validate domains upfront. Tools like Email List Validation check the actual DNS records—MX, A, SPF, and DKIM—before any email is sent.

This means you only send to addresses tied to domains that are live, properly configured, and theoretically reachable. That’s not guesswork. It’s DNS-level verification.

By doing so, you reduce bounce rates significantly, especially hard bounces. This has a direct impact on sender reputation, which is monitored by systems like Microsoft’s SmartScreen and Google’s Gmail infrastructure. High bounce rates trigger alerts—even if your message content is perfect.

And yes, this saves bandwidth, reduces load on SendGrid’s infrastructure, and helps keep your account in good standing. It’s not about avoiding spam filters. It’s about sending only to domains that can actually receive mail.

For real-time verification at scale, consider using an API-driven solution. Email List Validation’s real-time verification API checks domains as you build your list, catching invalid entries before they ever enter your campaign. It integrates directly with SendGrid, Mailchimp, HubSpot, and other platforms.

Want to clean a large list ahead of time? Their Bulk Email List Cleaning tool runs full DNS checks on thousands of addresses in minutes. All while preserving your domain reputation.

What does "unknown domain" actually mean in SMTP terms?

When SendGrid returns a 550 5.1.2 "unknown domain" error, it means the receiving mail server couldn't find a valid mail exchanger (MX) record for the domain in DNS. This is a hard rejection at the protocol level—your message isn’t rejected for spam, content, or temporary issues. It fails because the domain itself doesn’t exist, isn’t configured for email, or has a misconfigured DNS. This isn’t a delay; it’s a permanent no.

The SMTP Reality: No MX, No Delivery

In SMTP, delivery starts with DNS lookup. The sending server queries DNS for an MX record matching the recipient’s domain. If no MX record exists, or the domain doesn’t resolve at all, the receiving server responds with a 550 5.1.2 error. This is not optional behavior—it’s defined in RFC 5321, the core SMTP specification.

These errors are immediate and final. There’s no retry or soft bounce. This isn’t a sign of poor sending reputation or spam filtering—it’s a sign the domain simply can’t receive mail, even if you’re technically a good sender.

Common Causes You Should Recognize

Unknown domain errors usually point to one of three things: a typo in the email address (e.g., [email protected] instead of [email protected]), a domain that never had email configured, or a domain that was removed or expired. Even if the address looks valid, a missing MX is a fatal flaw.

It’s important to distinguish this from other 5xx errors—like 550 5.1.1 (user unknown) or 554 (rejected by policy)—which may imply the user exists but is blocked, or the server has filtering rules. Unknown domain is stricter: it says “we don’t know what this domain even is.”

Let’s say you’re sending to 10,000 addresses. If 1% return 550 5.1.2, you’re wasting sends, risking deliverability health, and eroding sender reputation. You’re not just losing a few emails—you’re sending to infrastructure that doesn’t exist.

Preventing these errors isn’t about tweaking your SPF or DKIM. It’s about ensuring every domain in your list is real, active, and properly configured in DNS. Tools like bulk email list cleaning help catch these issues early—before you send.

Common causes of unknown domain errors in bulk sends

You’re hitting 550 5.1.2 unknown domain errors in SendGrid because your list includes mistyped domains, outdated addresses with defunct domains, role-based emails with no real mail servers, or disposable domains that resolve but don’t accept mail. These aren’t just typos—they’re delivery blockers that inflate bounce rates and hurt sender reputation. Let’s break down what’s actually happening.

Typographical errors in email domains

One misplaced letter—like gmal.com instead of gmail.com—triggers a 550 error because the domain doesn’t exist.
Domains vary only by one character, but DNS won’t resolve them. Check spelling with tools that validate the full domain structure.
These are easy to catch early—bulk verification with a service like bulk email list cleaning can flag these before sending.

Outdated or unverified domains

Email lists grow stale. A domain might have been valid last year but now redirects, shuts down, or has no MX record.
Companies rebrand, merge, or shut down without updating contact data. These domains appear real but fail to resolve.
Pre-delivery domain validation checks DNS records in real time—before you send, it confirms the domain still exists and accepts mail.
For real-time checks on high-volume sends, use the real-time verification API to catch dead domains as you build your list.

Role-based addresses with no functional MX records

Addresses like [email protected] or [email protected] often have no real mailbox behind them.
Some domain owners set up catch-all domains for convenience, but others don’t—so a valid-looking address can still fail.
Even if the domain exists, the mail servers may not accept inbound messages for that specific address.
True verification checks whether the domain has an MX record and whether it accepts mail for that address.
Check your list against known patterns of role-based emails, especially in B2B or support-heavy campaigns.

Disposable domains that resolve but don’t deliver

Disposable domains like tempmail.com or 10minutemail.com appear valid—they have domains, DNS, and MX records—but don’t retain mail.
Spam filters and sending platforms like SendGrid block or reject messages to these domains, often returning 550 errors.
These domains are commonly used for fake signups, so they’re flagged early by robust verification systems.
Preventing these in your list is not about blocking by name—it’s about checking if mail can actually be delivered.
Our inbox placement testing includes validation of domain legitimacy and mail server responsiveness.

Domain validity is not just about DNS lookup—it’s about whether mail sent there can be accepted and delivered.

How Email List Validation detects unknown domains before you send

You prevent 550 5.1.2 unknown domain errors in SendGrid by catching invalid domains before sending. Our service checks every domain in your list using real-time DNS lookups and live SMTP handshakes. If a domain has no MX record, fails DNS resolution, or lacks a responsive mail server, we flag it as invalid—so you never waste sends or hurt your sender reputation.

How the validation process works

Real-time DNS MX lookup Every domain in your list is checked against public DNS records. We query for MX (mail exchange) records, which are required for incoming email. If no MX record exists, the domain cannot receive mail—and we mark it as invalid.
Live SMTP handshake sequence For domains with MX records, we simulate a real email delivery attempt using a full SMTP handshake. This tests whether the mail server is active, responsive, and configured to accept messages. A failed handshake means the server isn’t ready to receive email, even if DNS says it exists.
Domain resolution failure detection We verify that the domain resolves correctly at the DNS layer. If a domain returns a SERVFAIL, NXDOMAIN, or times out, it’s treated as unreliable. Many 550 5.1.2 errors stem from these issues, and we catch them early.
Flagging invalid domains Any domain that fails DNS lookup, has no MX record, or fails the SMTP handshake is returned with a verdict of invalid. These are the domains you must remove to avoid SendGrid bounces and potential sender reputation damage.

Why this matters

SendGrid returns a 550 5.1.2 error when it cannot deliver to a domain because the mail server doesn’t exist or isn’t reachable. Preventing this isn’t a guess—it’s a technical check, and we do it with actual network-level tests. According to RFC 5321, proper SMTP delivery requires a valid MX and working server connection.

Many tools only check whether an email address is properly formatted. That’s not enough. You need to validate the domain’s ability to receive email—not just its syntax. Services that skip live DNS or SMTP checks may miss invalid domains entirely.

To see how this works at scale, run a bulk verification on your list: clean your entire list with 98.9% accuracy in minutes. Or integrate our real-time verification API to check addresses as they’re entered.

How to integrate Email List Validation with SendGrid

You can avoid 550 5.1.2 unknown domain errors in SendGrid by validating domains before sending. Use Email List Validation’s real-time API or bulk upload to flag invalid domains—including those with unknown or non-existent mail servers—before they hit SendGrid’s SMTP. This stops bounces at the source and keeps your sender reputation healthy. You’re not guessing; you’re filtering.

Validate before sending: the real-time API workflow

Insert the Email List Validation API into your pre-send logic. Every new email address gets verified in milliseconds before entering your SendGrid pipeline.
Use the real-time email verification API to check syntax, domain existence, and mailbox responsiveness. It checks MX records, DNS, and SMTP-level reachability—exactly what SendGrid relies on later.
Reject any address flagged as "unknown domain" or "invalid domain" before delivery. This avoids the 550 5.1.2 error, which happens when SendGrid tries to deliver to a domain with no mail server.

Scale with batch validation and automated sync

For large lists, upload your email data to the Email List Validation bulk verification tool. It processes thousands in minutes and returns a clean list with full validity status.
Set up a webhook or scheduled sync to push validated data into SendGrid. This keeps your campaign lists updated and removes risk before you even send.
Enable auto-removal of invalid addresses during the sync process. Your SendGrid list stays clean—no manual cleanup needed, no unnecessary load on your IP reputation.

Domain validation is not optional when you send at scale. A single unknown domain can trigger an SMTP rejection, and repeated failures hurt send reputation. The RFC 5321 specification outlines how mail servers respond to invalid domains; SendGrid follows this strictly. Tools like MxToolbox confirm that missing or unreachable MX records are a common cause of delivery failure.

Let’s be clear: you don’t need to accept every address. A 98.9% accuracy rate means you’re catching the vast majority of problems before they reach SendGrid’s SMTP gate. That’s not optimism—it’s a measurable outcome of pre-verification. If your campaign’s deliverability drops, the root issue is often an unchecked domain. Fix that at the source.

Tools like SendGrid, Mailchimp, and HubSpot accept verified data. When you integrate Email List Validation early—whether via API or bulk upload—you ensure every delivery attempt has a real target.

What happens when you send to a domain with no MX record?

When you send an email to a domain with no MX record, SendGrid’s SMTP handshake fails during DNS lookup. The server receives a 550 5.1.2 "unknown domain" error immediately, before any message data is sent. This counts as a hard bounce, raises your bounce rate, and can trigger rate limiting or IP blocking if repeated.

How the error surfaces during delivery

SendGrid checks DNS for the recipient domain’s MX record before initiating the SMTP transaction. If no MX record exists—whether due to misconfiguration, a typo, or a non-existent domain—the connection fails at the very first step. You don’t get to send the message body; the error comes straight from the receiving server’s DNS response.

This behavior is standardized in RFC 5321, the core SMTP specification. It requires recipients to publish valid MX or A records, or risk connection rejection. A missing MX record is treated the same as an unknown or unreachable domain, and the receiving server must reject the connection politely—and clearly—with a code like 550 5.1.2.

Let’s be clear: this isn’t a temporary hiccup. It’s a hard failure. The bounce is logged as permanent. If you're blasting to a list with even a few of these domains, your sender reputation begins to degrade. High bounce rates correlate directly with poor inbox placement, and some ESPs like SendGrid will rate-limit or block your IP if you consistently hit unknown domains.

Why ignoring this causes long-term damage

Even one invalid domain might not hurt today. But send to 500 such domains in a week? That’s 500 hard bounces. Even if those recipients never existed, the system treats it like spam signaling. Your volume drops. Your reputation plummets.

Many teams discover this too late—after complaints from marketing, or after their campaign gets flagged. Prevention is far easier than recovery.

Validating domains before sending avoids this entirely. Tools like bulk email list cleaning check for MX records, DNS reachability, and other red flags at scale. You catch the unknown domains before they ever reach SendGrid’s outbound queue.

For real-time systems, real-time email verification can confirm a valid domain structure instantly during sign-up or transactional delivery. No DNS lookup failure. No bounce. No reputational harm.

Real-world impact: How unknown domain errors affect deliverability

Every 550 5.1.2 error you send adds to your hard bounce rate, which directly harms your sender reputation. Over time, consistent bounce rates above 2% significantly increase the risk of inbox placement drops or blacklisting. Even if the issue lies with the recipient's domain, repeated failures can trigger automated filters that block your entire sending domain.

Bounce rates and sender reputation

Mail providers track how many invalid addresses you send to over time. A single 550 5.1.2 error might not matter, but hundreds or thousands do. SendGrid and other ESPs use this data to assess your sending health. If your bounce rate trends upward, your messages get deprioritized — or blocked entirely.

High bounce rates are a red flag in systems like SenderScore and Google’s spam filters. They’re not just about delivery failure — they signal poor list hygiene. If you're sending to domains that don’t exist, your infrastructure appears unreliable to receiving servers.

What happens when domains keep failing

Even if the error originates with the destination domain, repeated delivery attempts can still harm your reputation. Some receivers flag senders who persistently fail on known invalid domains, especially if the pattern correlates with high-volume sending or spikes in failures.

It’s not just about the address — it’s about the pattern. If you're sending to 100 new domains per day and 20% return 550 5.1.2 errors, that’s a signal that your list is not being validated pre-send. This is not a “they’re at fault” scenario — the system treats you as the source of the noise.

According to RFC 5321, the 550 5.1.2 code explicitly indicates an unrecognized recipient domain. While this is ultimately a receiving server’s decision, senders who repeatedly encounter it face real consequences. It’s one of the most common indicators of list quality issues in deliverability audits.

Let’s say you’re running a SendGrid campaign and notice a 4% hard bounce rate. That’s not trivial. It’s often enough for inbox placement tools to label you as “high risk.” You might still be delivering, but to spam folders, or not at all. The fix isn’t in adjusting your content — it’s in cleaning your list before sending.

Use bulk domain validation to flag invalid domains before sending. Catching these issues early reduces hard bounces and keeps your sender reputation intact. This is not a one-time cleanup — it’s a daily discipline.

Email List Validation verdicts: What 'unknown domain' means in context

If you see a 550 5.1.2 unknown domain error in SendGrid, it means the recipient’s domain doesn’t resolve in DNS—no MX record, no DNS entry, or it’s outright fake. This isn’t a deliverability issue; it’s a dead end. Email List Validation catches these before they even hit your sending tool, saving you bounces, sender reputation damage, and wasted credits. Let’s break down what the app actually checks when it flags a domain.

Understanding the verdicts

Every email address is verified through multiple checks: DNS, SMTP, and behavioral patterns. Here’s what each verdict tells you in practice.

Verdict	What It Means	Why It Matters for SendGrid
Valid	Domain has a working MX record and responds to SMTP connection tests. It’s a real, active email system.	Safe to send. No immediate delivery risk from DNS or basic infrastructure failure.
Invalid	Domain doesn’t exist, is misspelled, or lacks valid DNS records—this includes all 550 5.1.2 errors.	SendGrid will reject these immediately. They waste your sending quota and hurt domain reputation if sent repeatedly.
Catch-all	Domain accepts mail for any address, even invalid ones. The server doesn’t reject unknown recipients.	Even if the address is wrong, the server says "accepted"—leading to hard bounces later or spam detection. Often linked to disposable domains or poor email hygiene.
Risky	Domain exists but has a weak deliverability track record, disposable patterns, or known abuse history.	High potential for inbox placement issues, even if DNS and SMTP check out. May trigger filters on major inboxes.

For example, a common source of 550 5.1.2 errors is a domain that’s been dropped or is misconfigured. You might see “example.com” in a list, but if it has no DNS A or MX record, email delivery fails at the first gate. That’s why pre-delivery validation is non-negotiable.

According to RFC 5321, the SMTP protocol requires a valid MX or A record before accepting a delivery. Without it, the server must reject the message with a 5xx error—exactly what SendGrid returns as 550 5.1.2. You can’t “fix” the error after it’s sent; the only way to prevent it is to catch it before sending.

If you're managing large lists, bulk verification tools are essential. You can clean up your entire list in minutes. Clean your list before sending with real-time feedback on every address. For integration with marketing platforms like Mailchimp or HubSpot, check out the available integrations. You don’t need to guess what's wrong—your list will tell you.

Use pre-delivery validation to keep SendGrid sender reputation strong

Sending only to valid, deliverable addresses prevents your IP and domain from being flagged by ISPs due to high bounce rates.

Low bounce rates are a measurable signal of responsible sending behavior, directly influencing inbox placement algorithms used by Gmail, Outlook, and others.

By catching 550 5.1.2 unknown domain errors before you send, you maintain predictable, consistent sending patterns that align with ISP expectations.

Pre-delivery validation gives you real-time insight into your email list's health, so you know what’s deliverable before it hits the wire.

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

Can SendGrid fix unknown domain errors on its own?

No. SendGrid cannot resolve non-existent or misconfigured domains. The error is client-side due to invalid DNS records.

Does using a domain validation tool guarantee no 550 5.1.2 errors?

It drastically reduces them. Known invalid domains are caught before sending, but rare edge cases may still occur due to transient DNS issues.

How accurate is Email List Validation for detecting invalid domains?

It achieves 98.9% accuracy by combining DNS, MX, and SMTP-level checks. Invalid domains are identified through multiple validation layers.

What’s the cost of ignoring unknown domain errors?

Ignoring them increases hard bounce rates, risks sender reputation, and can lead to IP blacklisting over time.

Do disposable domains also trigger 550 5.1.2 errors?

No. Disposable domains usually have valid MX records but reject messages after delivery. They return different errors, but still harm list hygiene.

Can role accounts cause 550 5.1.2 errors?

Not directly. Role accounts (like admin@ or support@) may lack mailboxes, causing 5.1.1 or 5.7.1 errors—but not unknown domain errors.

Is email validation required with SendGrid?

It’s not required, but it’s a best practice. SendGrid does not verify addresses; your list hygiene determines success.

How do you test if a domain is valid before sending?

Use DNS lookup tools like dig or MXToolbox, or integrate a real-time email verification service to check domains programmatically.

Can a domain be valid but still not deliver mail?

Yes. A domain may have valid MX records but reject deliveries due to filters, greylisting, or blacklisted IPs. Verification tools detect this in real time.

What’s the difference between a 550 5.1.2 error and a 550 5.1.1 error?

550 5.1.2 means the domain is unknown (no DNS MX). 550 5.1.1 means the specific user address doesn’t exist at a valid domain.

How often should you validate your email list?

At least once before every major send. For persistent lists, monthly validation helps prevent decay from outdated addresses.

Does Email List Validation work with SendGrid’s SMTP API?

Yes. It integrates seamlessly with SendGrid via API or bulk upload. You can verify addresses prior to using SendGrid’s SMTP gateway.