The 550 5.1.2 error means the destination domain is invalid or cannot accept mail — also known as “bad destination system address” or “domain not found.”
Fix it by verifying the domain spelling (the part after @), checking DNS/MX records, and clearing cached auto-complete entries that may hold outdated addresses.
Unlike 550 5.1.1 (which targets the mailbox portion), the 5.1.2 code specifically flags problems with the domain itself. The receiving server either can’t find the domain or determines it lacks valid mail routing.
Ignoring repeated 5.1.2 bounces signals to email providers that you’re sending to non-existent destinations — a fast track to sender reputation damage.
Quick skim — 550 5.1.2 error overview
The 550 5.1.2 error represents a permanent failure tied to addressing problems at the domain level.
| Attribute | Details |
| Error code | 550 5.1.2 |
| Category | Addressing / system-level error |
| Meaning | Destination domain is invalid or not mail-capable |
| Severity | Permanent (hard bounce) |
| Common causes | Domain typos, expired domains, missing MX records, DNS resolution failures |
| Fix approach | Verify domain spelling → check DNS → correct or suppress |
What does 550 5.1.2 mean?
The 550 5.1.2 error indicates the destination “system” — meaning the domain to the right of the @ symbol — does not exist or cannot accept mail. Email providers phrase this as “bad destination system address,” “host not found,” or “domain not mail-capable.”
SMTP code breakdown
Breaking down 550 5.1.2 reveals what each component signals:
| Component | Value | Meaning |
| Basic code | 550 | Permanent failure — won’t resolve with retry |
| Enhanced class | 5 | Permanent condition |
| Enhanced subject | 1 | Addressing problem |
| Enhanced detail | 2 | Bad destination system (domain invalid) |
The key distinction from 550 5.1.1: while 5.1.1 means the mailbox doesn’t exist on a valid domain, 5.1.2 means the domain itself is the problem.
Provider variations
Different systems phrase the same underlying error differently:
| Provider | Error Message |
| Microsoft 365 | 550 5.1.2 RESOLVER.ADR.BadDest; domain not found |
| Generic SMTP | 550 5.1.2 Bad destination mailbox address |
| Exchange | 550 5.1.2 The recipient domain is not reachable |
Vs similar codes
Distinguishing 550 5.1.2 from related errors prevents misdiagnosis:
| Code | Target | Example Cause |
| 550 5.1.1 | Mailbox portion | john.doe doesn’t exist at valid company.com |
| 550 5.1.2 | Domain portion | company.con is misspelled or company.com has no MX records |
| 550 5.1.3 | Address syntax | Missing @, illegal characters, malformed format |
Why does the 550 5.1.2 error occur?
Domain-level failures stem from either sender-side data problems or recipient-side infrastructure issues. Understanding which applies determines your fix path.
Domain typos
The most common cause — simple spelling errors in the domain:
- gmail.con instead of gmail.com
- outlok.com instead of outlook.com
- company.cm instead of company.com
- Hidden trailing punctuation copied from spreadsheets
Expired domains
Domains require annual renewal. When a recipient’s organization lets its domain lapse, all mail to that domain starts bouncing. The domain technically exists in DNS history, but no longer routes mail.
Missing MX records
Every domain that receives email needs MX (Mail Exchanger) records pointing to valid mail servers. Some domains exist for websites only — they publish A records for web traffic but never configure mail routing. Sending an email to such domains triggers 5.1.2.
DNS resolution failures
Occasionally, the domain is valid, but your sending infrastructure can’t resolve it:
- Your DNS servers are misconfigured or unreachable
- The recipient’s DNS is temporarily down
- Network-level issues block resolution
DNS failures sometimes produce 5.1.2 bounces that would succeed if retried later (though the 5xx code technically indicates permanence).
Authoritative domain misconfiguration
For Microsoft 365 administrators: if your accepted domain type is set incorrectly (Authoritative vs. Internal Relay), Exchange may reject mail destined for valid external domains. The system thinks the address should exist internally — and when it doesn’t, returns 5.1.2.
How do you fix 550 5.1.2?
Fixing 5.1.2 requires identifying whether the problem is sender-side (your data) or recipient-side (their infrastructure).
Verify domain spelling
Start with the obvious — copy the bounced address from your DSN and examine the domain character by character:
- Check for transposed letters (gmial.com)
- Look for wrong TLDs (.con, .cm, .og)
- Watch for invisible characters or trailing spaces
- Confirm the company hasn’t rebranded to a new domain
If you spot a typo, correct it in your database and resend.
Check MX records
Use a DNS lookup tool to verify the recipient domain has valid mail routing:
dig MX example.comor use online tools like MXToolbox. Valid output shows one or more MX records pointing to mail servers. If no MX records exist:
- The domain may be web-only (no mail)
- The domain owner hasn’t configured email
- The domain expired and lost its DNS records
For domains you don’t control, contact the recipient through alternate channels. For your own domains, add proper MX records in your DNS settings.
Clear auto-complete
Email clients cache addresses from previous sends. A cached entry with a typo keeps suggesting the wrong domain:
- Outlook: Start typing → highlight suggestion → press Delete
- Gmail: Hover over suggestion → click X
- Apple Mail: Window → Previous Recipients → remove entry
After clearing, manually type the corrected address.
Fix DNS resolution
If 5.1.2 errors affect multiple recipients across different domains, your DNS infrastructure may be the culprit:
- Test resolution from your sending server: nslookup example.com
- Verify your DNS servers are reachable
- Check for network-level blocks on DNS traffic
- Try alternate DNS resolvers temporarily
Admin fixes (Exchange/Microsoft 365)
For tenant administrators seeing internal 5.1.2 errors:
Accepted domains
The “toggle trick” can force a resync:
- Open Exchange Admin Center
- Navigate to Mail flow → Accepted domains
- Change the domain type from Authoritative to Internal Relay
- Save, wait 15 minutes
- Change back to Authoritative
- Allow propagation (up to 1 hour)
Hybrid environments
If running hybrid Exchange, verify on-premises directory sync is healthy. Stale directory data causes Exchange Online to reject addresses that exist on-premises.
Distribution groups
Check if the recipient belongs to a restricted distribution group that blocks external senders. Add the sender to allowed senders or enable external delivery.
Suppress invalid domains
After confirming a domain genuinely doesn’t exist or can’t receive mail:
- Add addresses to your suppression list
- Flag the contact for alternate outreach
- Remove from active campaigns
How do you prevent this error?
Domain-level bounces often indicate systemic data quality issues. Prevention requires validation at multiple stages.
Validate domains at entry
Implement real-time validation on forms that checks:
- Domain syntax is valid
- Domain has MX records
- Domain isn’t a known typo pattern
An email validation API catches these before bad data enters your system.
Monitor bounce patterns
Track 5.1.2 bounces separately from 5.1.1. A spike in domain-level errors suggests:
- Form validation failure
- Bad data import (list with typos)
- Partner company domain change
Regular bounce rate monitoring catches problems early.
Verify aged contacts
Domains change hands, companies rebrand, and organizations merge. Contacts from 2+ years ago warrant re-verification — their domain may no longer exist or route mail.
Still stuck after trying the fix?
Some email errors are easy to clear. Others point to deeper deliverability issues involving authentication, sender reputation, blacklisting, routing, or mailbox provider policy. If you would rather have an expert review it, speak with an email delieverability consultant for free and we can help diagnose the issue and fix it on your behalf.
We look beyond the error message itself to find what is actually breaking delivery, trust, or inbox placement.
From SPF, DKIM, and DMARC to blacklist cleanup, DNS alignment, and sending setup, we can guide or implement the fix.
We assess whether the error is part of a bigger pattern hurting opens, replies, and overall campaign performance.
Talk to a real deliverability expert, get honest guidance, and see the next best step without pressure or upsells.
When should you book a consultation? If the error keeps coming back, affects multiple mailboxes or domains, started after an ESP or DNS change, or is tied to spam placement, low inboxing, high bounce rates, or authentication failures, it is usually faster to get an expert involved early.
Frequently asked questions
Here are some commonly asked questions about this error:
The 5.1.1 error targets the mailbox (the part before @) while 5.1.2 targets the domain (the part after @). With 5.1.1, the domain is valid, but that specific mailbox doesn’t exist. With 5.1.2, the domain itself is invalid, expired, or lacks mail routing.
Retrying to the same address won’t help — the domain problem persists. However, if the cause was a temporary DNS failure (uncommon), a retry hours later might succeed. Generally, treat 5.1.2 as permanent and investigate the domain before attempting again.
Common reasons include domain expiration (owner didn’t renew), company rebranding to a new domain, acquisition/merger that consolidated email systems, or DNS misconfiguration introduced by the domain owner. Contact the recipient through alternate channels to get their current address.
Use MX record lookup tools (MXToolbox, dig, nslookup) to verify the domain publishes MX records pointing to active mail servers. No MX records means the domain can’t receive email. Additionally, verify you can open a connection to the listed mail servers.
