# 5.1.8 Bounce: Bad Sender's System Address

URL: https://email-validation.org/bounce-codes/5-1-8/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

**At a glance**

- **Type:** permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
- **Basic code:** varies; the enhanced code is the part that identifies the problem.
- **Enhanced code 5.1.8:** “Bad sender's system address” in the IANA registry (RFC 3463), in the group addressing status (RFC 3463 §3.2).

The receiving system refused the domain of your sender address. In Microsoft 365 the same code usually means something more serious: your own account has been blocked from sending because it sent spam.

## What it means
[RFC 3463 §3.2](https://www.rfc-editor.org/rfc/rfc3463) defines X.1.8 as bad sender's system address. The sender's domain does not exist or cannot accept return mail; for a domain name, the part to the right of the @ is invalid for mail. Receivers check this because bounces and replies need somewhere to go. The basic code that comes with it varies by server.

## Common causes
- The envelope sender uses a domain that does not exist or has expired.
- The sender domain has no working mail server, so it could not receive a bounce.
- The sender domain publishes a null MX. [RFC 7505 §4.1](https://www.rfc-editor.org/rfc/rfc7505) gives that case its own code, [550 5.7.27](https://email-validation.org/bounce-codes/550-5-7-27/), and §4.2 says domains used in sender addresses should not publish a null MX.
- A test or internal domain, such as one ending in `.local`, leaked into the sender address.
- In Microsoft 365: a compromised account sent a burst of spam and was restricted.

## How providers use it
**Microsoft 365** returns `5.1.8 Access denied, bad outbound sender` when the sending account is blocked for sending too much spam. Microsoft notes that this typically happens because the account was compromised ([Exchange Online NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online)). Here the domain is not the issue at all: the block sits in your own organization, not at the recipient.

## How to fix it
If the bounce came from a recipient's server:
1. Look up your sender domain's MX records with `dig MX yourdomain.com` and check that the domain is still registered.
2. Make sure the envelope sender uses a real domain that can receive bounces, not an internal or placeholder one.
3. If you publish a null MX for the domain, either stop sending from it or replace the null MX with real MX records.

If the bounce came from Microsoft 365 with "bad outbound sender":
1. Treat the account as compromised. Reset its password, sign it out of all sessions and review its sign-in activity.
2. Check the mailbox for forwarding or inbox rules its owner did not create.
3. Find out how the account was taken over, and close that gap before the block is lifted, or it will return.
4. Ask a Microsoft 365 administrator to remove the sending block, following the steps for 5.1.8 in Microsoft's NDR reference.
5. If the spam went on for a while, recipients may also refuse your organization's IP addresses; see [5.7.606](https://email-validation.org/bounce-codes/5-7-606/).

## Related codes

- [553 5.1.7](https://email-validation.org/bounce-codes/553-5-1-7/): The sender's address is not valid syntax
- [5.7.606](https://email-validation.org/bounce-codes/5-7-606/): Banned sending IP (Microsoft)
- [550 5.7.1](https://email-validation.org/bounce-codes/550-5-7-1/): Delivery not authorized: refused for policy reasons

See [every bounce code](https://email-validation.org/bounce-codes/) in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our [free email checker](https://email-validation.org/email-checker/), or [clean a whole list](https://email-validation.org/bulk-email-verification/) before you send.