If you are seeing `message undeliverable`, the error is telling you only one useful high-level fact: the mail did not complete delivery.

It is not telling you why.

That is the part teams miss. "Undeliverable" can mean an invalid recipient, a full mailbox, a sender-auth problem, a blocked relay, an oversized message, or a temporary infrastructure condition that should not be handled like a permanent failure.

## Quick answer

A `message undeliverable` error usually falls into one of these buckets:

- the recipient address is invalid
- the mailbox cannot currently accept mail
- the sender failed a policy or authentication check
- the message was too large
- the route, relay, or DNS path was wrong
- the provider temporarily deferred the message

The first job is classification.

Do not just resend. Find the SMTP status, bounce notice, or provider event that tells you whether the failure is permanent or temporary.

If your next question is specifically about retries, suppression, and temporary vs permanent failure handling, continue with [Soft bounce vs hard bounce](/guides/soft-bounce-vs-hard-bounce/).

## What "message undeliverable" usually means in practice

The phrase is a wrapper, not a root cause.

Depending on the system, it might represent:

- a bounce notification
- a server-generated delivery status report
- an application send failure
- an ESP event label
- a user-facing inbox notification with the technical details hidden

That means the visible error text is often less useful than the evidence behind it:

- SMTP code
- enhanced status code
- provider rejection reason
- raw bounce text
- mail headers
- sending logs

## The fastest classification table

| Symptom                                 | Likely class                                  | Typical next step                                    |
| --------------------------------------- | --------------------------------------------- | ---------------------------------------------------- |
| `550 5.1.1` or user unknown             | invalid recipient                             | verify the address and suppress if confirmed bad     |
| `550 relay denied`                      | auth or relay policy                          | fix submission endpoint, credentials, or relay rules |
| `554 rejected due to policy`            | reputation or authentication                  | inspect SPF, DKIM, DMARC, and sender quality         |
| mailbox full or temporarily unavailable | soft bounce                                   | retry with backoff and threshold limits              |
| size limit exceeded or `552`            | message too large                             | reduce payload or use a hosted download link         |
| `421` or throttling                     | temporary infrastructure or provider pressure | slow down and retry later                            |

This table alone saves time because it separates:

- bad recipient data
- sender configuration problems
- message construction problems
- short-lived transport conditions

## Recipient-side causes of message undeliverable

### Invalid or mistyped address

This is the classic permanent failure. The mailbox does not exist, or the address format and domain combination is wrong.

If the address is business-critical, verify:

- local-part spelling
- alias mapping
- whether the recipient changed domain
- whether a plus alias or role address was removed

### Mailbox disabled or unavailable

Sometimes the address exists but the mailbox is disabled, blocked, or otherwise unable to accept mail.

### Recipient policy blocks

The recipient system may not accept external mail, may reject specific senders, or may require a trust relationship you do not have.

This is where the error often looks like a recipient problem even though the real issue is sender trust.

## Sender-side causes of message undeliverable

### SMTP auth or relay mismatch

If the app uses the wrong host, port, credentials, or auth mode, the message can fail before queueing properly.

Start with:

- [SMTP tester](/tools/smtp-tester/)
- [SMTP authentication guide](/blog/smtp-authentication/)
- [Fixing SMTP 550 errors](/blog/fixing-smtp-550-errors/)

### SPF, DKIM, or DMARC failure

Many undeliverable incidents are really sender-auth incidents.

This becomes likely when:

- mail started failing after DNS changes
- a new sender or relay was introduced
- a From domain changed
- DMARC enforcement was tightened

Use:

- [SPF checker](/tools/spf-checker/)
- [DKIM checker](/tools/dkim-checker/)
- [DMARC checker](/tools/dmarc-checker/)
- [DMARC fail](/guides/dmarc-fail/)

### Reputation or content rejection

The message may technically be well formed but still be rejected because of:

- poor domain or IP reputation
- complaint spikes
- link quality problems
- blacklist pressure
- abusive or unexpected sending patterns

Useful next steps:

- [Email blacklist checker](/tools/email-blacklist-checker/)
- [Email spam checker](/tools/email-spam-checker/)
- [SpamCop](/guides/spamcop/)



{{LANDING_SHORTCODE:POST_CTA_BANNER:%7B%22title%22%3A%22Turn%20an%20undeliverable%20report%20into%20a%20repeatable%20test%22%2C%22content%22%3A%22Send%20a%20controlled%20test%2C%20compare%20inbox%20and%20spam%20placement%2C%20inspect%20authentication%20results%2C%20and%20keep%20evidence%20before%20and%20after%20the%20delivery%20fix.%22%2C%22buttonHref%22%3A%22%2Fproduct%2Finbox-placement-deliverability-tests%2F%22%2C%22buttonText%22%3A%22Explore%20inbox%20placement%20testing%22%2C%22buttonTheme%22%3A%22emerald%22%2C%22image%22%3A%22%2Fassets%2Fhome%2Finbox-placement.png%22%2C%22imageAlt%22%3A%22MailSlurp%20inbox%20placement%20test%20results%22%2C%22imageWidth%22%3A%22800%22%2C%22imageHeight%22%3A%22381%22%2C%22imagePosition%22%3A%22%22%7D}}



## Message construction causes

### Oversized message or attachment

This is often missed because the file size looked acceptable before encoding.

Remember:

- attachments grow during MIME and base64 encoding
- the limit applies to the full message, not only the file

If the message is large, review:

- [Email size limits](/guides/email-size-limits/)
- [Email attachments API](/guides/email-attachments-api/)

### Malformed message structure

Headers, MIME parts, or submission formatting issues can cause certain providers or gateways to reject mail even when the message looked fine in a local test.

That is especially common in custom SMTP implementations and rushed template changes.

## Temporary vs permanent failures

This distinction determines the right response.

### Permanent failures

Examples:

- invalid recipient
- relay denied
- explicit policy rejection
- mailbox unavailable in a permanent sense

Action:

- fix before retrying
- suppress bad recipients
- correct auth or routing

### Temporary failures

Examples:

- throttling
- server unavailable
- greylisting
- mailbox full
- transient DNS or queue pressure

Action:

- retry carefully with backoff
- monitor repeat frequency
- escalate if the condition persists

This is why `message undeliverable` should never be handled as one generic retry rule.

## What to check before you resend

Use this sequence:

1. read the exact SMTP code or provider event
2. decide whether the failure is permanent or temporary
3. validate the recipient address and mailbox assumptions
4. inspect sender authentication and `Return-Path`
5. check payload size and recent template changes
6. test the workflow with a controlled inbox

If you only do step 6 without steps 1 to 5, you are testing blind.

## Message undeliverable during product releases

Be especially suspicious when the incident began after:

- switching ESPs or relays
- rotating DKIM selectors
- changing a From domain
- moving to a new SMTP host or port
- adding attachments or larger HTML
- changing suppression or verification logic

That pattern usually means the mail system changed, not the recipient.

For recipient-facing workflows like invites, resets, invoices, and alerts, "message undeliverable" is a release-quality issue as much as a support issue.

## How MailSlurp helps

MailSlurp helps teams turn vague undeliverable incidents into reproducible evidence.

Use it to:

- capture controlled inbound tests in [Email sandbox](/product/email-sandbox/)
- inspect raw headers and routing signals with [Email header analyzer](/tools/email-header-analyzer/)
- validate auth posture with [DMARC, SPF, DKIM monitoring](/product/dmarc-spf-dkim-monitoring/)
- run a full [Email deliverability test](/testing/email-deliverability-test/) before and after fixes
- diagnose recipient-side hard failures with [550 permanent failure for one or more recipients](/guides/550-permanent-failure-for-one-or-more-recipients/)

That matters because many "undeliverable" problems only become obvious when you compare:

- what the sender thought it sent
- what the receiver actually saw
- what the provider reported in between

## FAQ

### Does message undeliverable always mean the address is wrong?

No. It can also mean policy rejection, relay failure, throttling, oversize payload, or other infrastructure problems.

### Should I resend an undeliverable email immediately?

Not until you know whether the failure was temporary or permanent. Blind retries can make reputation or queue problems worse.

### What is the difference between undeliverable and bounced?

In many systems, an undeliverable message results in a bounce or delivery status report. The exact wording depends on the provider or mail client.

### Can DMARC cause a message undeliverable error?

Yes. If DMARC alignment fails and the receiver enforces the sending domain's policy, the message can be rejected or filtered.

### Can a message be undeliverable because it is too large?

Yes. Attachment-heavy or HTML-heavy mail can exceed provider limits once the full message is encoded.

## Final take

`Message undeliverable` is a symptom, not a diagnosis. The fastest way to fix it is to classify the failure correctly, inspect the actual sender and message evidence, and stop treating every delivery problem as either a bad address or a random temporary glitch.
