550 Unrouteable Address & Sender Verify Failed: 2026 Fix Guide

TL;DR#

• 550 unrouteable address means the receiving server cannot find a route to deliver mail to the recipient's domain — usually broken MX records, dead DNS, or a typo in the address.
• 550 sender verify failed means the recipient's server tried a reverse SMTP callout to your domain and your mailbox failed verification — typically MX/A record problems on your sending domain, a missing postmaster mailbox, or a catch-all that bounces.
• Both errors are produced almost exclusively by Exim mail servers using verify = sender or verify = recipient ACLs, which are common on cPanel/WHM hosts.
• Fixes split cleanly: recipient-side bounces require list hygiene; sender-side rejections require fixing your own DNS, PTR, MX, and SPF setup.
• Most "mystery" bounces of these two strings disappear after a proper email verification pass plus a 10-minute DNS audit.

If you only have two minutes, run your list through an email verifier, then confirm your sending domain has valid MX, PTR, and a working postmaster@ address. That fixes 80% of these bounces.

What does "550 unrouteable address" actually mean?#

550 unrouteable address is a permanent SMTP rejection (5xx = hard fail) returned by the recipient's mail server when it cannot determine where to deliver your message. In practice the Exim daemon — which powers most cPanel, WHM, DirectAdmin, and shared-hosting mail stacks — has run a recipient verify ACL, asked DNS "where does mail for example.com go?", and gotten nothing usable back.

The literal causes are narrow:

• The recipient domain has no MX record and no A record fallback.
• The recipient domain's MX points to a hostname that itself doesn't resolve.
• The recipient address is local to the server, but the local part doesn't exist and the server runs verify = recipient/callout.
• A typo turned gmail.com into gnail.com and you bounced on the unregistered domain.

This is not a content filter. It is not a reputation problem. It is a routing problem. The mail never reached an inbox — it never even reached the right building.

What does "550 sender verify failed" mean?#

550 sender verify failed is the flip side. The recipient's Exim server received your message, then performed a sender callout verification: it opened a fresh SMTP session back to your sending domain's MX and asked, "Does the address that claims to be sending this actually exist?" If your server can't be reached, refuses the callout, or says the sender mailbox doesn't exist, Exim issues a 550.

The callout looks roughly like this:

> HELO recipient-server.example
> MAIL FROM:<>
> RCPT TO:<you@yourdomain.com>
< 550 No such user

If the RCPT TO returns anything other than a 250, your message is rejected with sender verify failed. The recipient never sees it.

Common triggers:

• Your sending domain's MX record doesn't resolve, or points to a host with no SMTP listener on port 25.
• Your mailbox literally does not exist on your own server (common with "from" addresses spoofed by misconfigured forms).
• Your server has RCPT TO rate-limiting that returns 4xx — which Exim interprets defensively as failure.
• Outbound port 25 is blocked by your hosting provider, so the recipient's callout times out.
• A catch-all that 5xx-rejects on verification probes.

Are these errors the same as "user unknown" or "mailbox does not exist"?#

No, but they overlap. Plain 550 5.1.1 User unknown is the standard SMTP response when the recipient address doesn't exist on the destination server. 550 unrouteable address is more specific: the server isn't even saying "no such user" — it's saying "I have no idea where to send this." That distinction matters because the fix is different:

If you're seeing the first two in a single batch send, that's a list-quality issue. If you're seeing the third on every message, that's a configuration issue on your side.

How do I diagnose a "550 unrouteable address" bounce?#

Work from the address outward. Most of the time, the address is bad or the domain is dead.

Step 1: Check the address itself. Look for transposed characters, missing dots, country-code mistakes (.co vs .com). The vast majority of unrouteable bounces in cold outreach are typos that survived a CSV export.

Step 2: Resolve the MX manually. From a terminal:

dig MX example.com +short

If the response is empty and the domain has no A record either, the domain is unreachable for mail. Drop it from your list — no amount of resending fixes a domain without MX.

Step 3: Check whether the domain even exists. A surprising number of unrouteable addresses come from domains that lapsed:

whois example.com | grep "Domain Status\|Registry Expiry"

Step 4: Run the address through a verifier. A proper email verification check tests MX resolution, performs a non-destructive SMTP handshake, and catches catch-all domains before you ever send. This converts hundreds of 550 unrouteable address bounces into clean "invalid" labels on your list.

How do I diagnose a "550 sender verify failed" bounce?#

This is the harder one because the fault is on your side. The recipient is telling you, politely, that you look like a fraud.

Run this checklist against your sending domain:

1. MX record exists and resolves. dig MX yourdomain.com +short should return at least one priority/hostname pair, and each hostname should itself have an A record.
2. Port 25 is open and answers SMTP. From a different network: telnet your-mx.example 25. You should get a 220 banner. Many residential ISPs and cloud providers block port 25 outbound by default — that's why callouts fail.
3. Postmaster mailbox accepts mail. RFC 5321 requires postmaster@yourdomain.com to exist. Some Exim configs do callouts against this address explicitly.
4. The exact MAIL FROM address exists as a real mailbox. If you send as noreply@yourdomain.com but no such mailbox is provisioned, callouts fail.
5. PTR / reverse DNS matches your HELO. dig -x your.sending.ip +short should resolve to a hostname that itself forward-resolves back to the same IP.
6. SPF authorizes your sending IP. Not strictly required for sender verify, but Exim configurations often combine the two ACLs.
7. No greylisting on inbound callouts. If your server greylists with 4xx, a one-shot callout will fail and the recipient won't retry.

A 60-second sanity check: send yourself a test message from an unrelated provider (a Gmail or Outlook personal account) to the address that's getting sender verify failed. If your reply works, the inbound path is fine and the problem is purely on the callout side.

Why is Exim so strict compared to Postfix or Microsoft 365?#

Exim's verify = sender/callout ACL is more aggressive than the defaults on Postfix, Sendmail, or Microsoft 365 because it does synchronous verification during the SMTP transaction. Postfix can be configured to do the same with reject_unverified_sender, but it's off by default. Microsoft 365 relies on SPF/DKIM/DMARC plus reputation scoring rather than live callouts.

A few characteristics of Exim callouts to know:

• They use MAIL FROM:<> (the null sender) to avoid loops.
• They cache results in /var/spool/exim/db/callout — so a fix may take hours to propagate until the cache expires.
• Many hosts run them only on senders from domains they have not seen before, which is why your first cold email to a host hits the wall and subsequent emails go through.
• They are widely criticized as a deliverability anti-pattern (you can read Spamhaus's stance on aggressive callouts), but they remain common on shared hosting.

For the deeper protocol context, the Exim documentation on callout verification is the canonical reference.

What are the actual fixes for each error?#

If you are the sender getting sender verify failed:#

1. Run dig MX yourdomain.com — does it return anything? If not, add an MX record pointing to your mail server.
2. Telnet your own MX on port 25 from an external box. Get a 220.
3. Create postmaster@yourdomain.com and abuse@yourdomain.com as real mailboxes. Forward them to a monitored inbox.
4. Make sure every From: address you send from is a real mailbox on the server — no phantom senders.
5. Set PTR/reverse DNS at your hosting provider.
6. Wait for Exim callout caches to expire (default TTL is 24 hours; sometimes longer).
7. Retest with the same recipient.

If you are the sender getting unrouteable address on a list:#

1. Stop sending to the list immediately — continued sends to invalid addresses tank your sender reputation.
2. Export the list and run it through bulk verification. See our guide on bulk email finder and catch-all verifier workflows.
3. Remove every address marked invalid, unknown, or catch-all-risky.
4. Re-send to the cleaned list in batches of 50-100 to monitor bounce rate.

Does this bounce hurt my sender reputation?#

Yes — significantly. Both errors register as hard bounces with reputation services like Postmaster Tools, SNDS, and SenderScore. A bounce rate above 2% routinely triggers throttling at Gmail and Outlook. Above 5% and you'll see throughput collapse within 24 hours.

The compounding problem: an Exim callout failure on a 550 sender verify failed means recipient servers may cache the negative result for hours or days. Even after you fix the underlying issue, your domain remains "tainted" in the recipient's callout database until the cache expires. This is why fixing your DNS and waiting feels infuriating — the receiving infrastructure isn't re-checking on every attempt.

For the deliverability side of the story, our email deliverability glossary walks through how hard bounces and reputation interact.

How do I prevent these bounces at the source?#

Three layers, in order of impact:

Layer 1 — Verify before you send. This is the single highest-ROI move. Catching an unrouteable address before it leaves your outbox saves your reputation and your sender-score. Tools like Tomba's email verifier test MX resolution, SMTP handshake, and catch-all status without firing a real message.

Layer 2 — Audit your sending domain monthly. Run dig against your own MX, PTR, SPF, DKIM, and DMARC records. Use a free SPF checker and a blacklist checker to confirm you're not on a major RBL. Most "sudden" deliverability drops trace back to a record change made weeks earlier.

Layer 3 — Architect your sending properly. Use a dedicated sending domain (not your corporate root domain). Warm IPs slowly. Don't send transactional and marketing from the same domain. Keep your From: addresses real and monitored. See HubSpot's deliverability primer and Google's bulk sender guidelines for the modern baseline.

Comparison: tools that catch these bounces before they happen#

The fastest path for a cold-outreach team is verifier + DNS audit. The fastest path for a transactional sender is DNS audit + inbox-placement test. Either way, Tomba's pricing starts at $49/mo for the Starter plan with 500 verifications, which is usually enough to clean a mid-sized outreach list end-to-end.

When should you escalate to the recipient's postmaster?#

Almost never. 550 sender verify failed from a major provider (Gmail, Outlook, Yahoo) usually means you have a real configuration problem — fix it on your side first. 550 unrouteable address is the recipient's problem, but it's not worth chasing unless the address is high-value and you have a second channel to ask "is this address still active?"

The one exception: if you have a contractual relationship with the recipient organization and their server is rejecting every legitimate sender, contact their IT team with the bounce string verbatim. Don't paraphrase — the literal Exim response narrows the diagnosis instantly.

Wrap up#

550 unrouteable address and 550 sender verify failed look like cryptic SMTP errors, but they decompose neatly: the first is almost always a recipient-list quality problem, the second is almost always a sender-side DNS or mailbox problem. Both reward a 10-minute audit far more than they reward retrying.

If most of your bounces are in the first category, the fix is upstream — verify before you send. Pipe your list through Tomba's email finder and email verifier before any campaign goes out, and you'll cut these specific bounce strings to near zero. Start on the free tier (25 searches/month) or move to Starter at $49/mo once you're sending at volume.