# 5.7.506: access denied, bad HELO

URL: https://iblockspam.com/smtp-errors/550-5-7-506
Last updated: 2026-11-03

Code: 550 5.7.506 (permanent failure, the message bounced)
Provider: Microsoft 365 / Outlook.com

Your mail server introduced itself in the HELO or EHLO greeting as the server it was connecting to, not by its own name, so Microsoft 365 refused the connection.

What the bounce says:

```
Access Denied, Bad HELO
```
Microsoft's text for 5.7.506, as listed in its Exchange Online NDR reference.

Microsoft's NDR reference lists 5.7.506 "Access Denied, Bad HELO": the sending server is trying to introduce itself in HELO as the server it's connecting to, rather than by its own fully qualified domain name. Microsoft says this behavior isn't allowed and is characteristic of typical spambot behavior.

RFC 5321 says the HELO or EHLO argument is the client's fully qualified domain name if one is available, and that the name must be the host's primary name or, if it has none, an address literal. Claiming to be the receiver, for example greeting a Microsoft 365 MX host with the recipient's domain or Microsoft's host name, is a cheap trick spam software uses, so receivers reject it.

Legitimate servers hit this when the HELO name is set by hand to the wrong value, often after copying settings from the recipient side, or when an app or device takes the greeting name from the recipient domain. Set the HELO name to your server's own host name, one that resolves in DNS and matches the PTR record of the sending IP.

## Common causes

- The server's HELO or EHLO name is set to the recipient's domain or Microsoft's host name.
- An app or device builds its greeting from the destination it's connecting to.
- Spam software forging the greeting, which is what the check is designed to stop.

## How to fix it (sender)

- Set the HELO/EHLO name to your server's own fully qualified host name, such as mail.yourdomain.com.
- Make sure that name resolves to the sending IP and matches the IP's PTR record.
- Resend after changing the setting.

## How to fix it (recipient or admin)

- No action needed by recipients: the sending server has to identify itself correctly.

**Q: What should my mail server's HELO name be?**
Its own fully qualified host name, such as mail.yourdomain.com, which RFC 5321 asks for. It should resolve to the sending IP and match that IP's PTR record. Never use the recipient's domain.

**Q: Why does Microsoft treat a wrong HELO as spam behavior?**
Microsoft says greeting a server with that server's own name instead of yours is characteristic of typical spambot behavior. Spam software does it to look trusted, so Microsoft 365 rejects it outright.

Sources:
- Email nondelivery reports (NDRs) and SMTP errors in Exchange Online (Microsoft Learn): https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online
- RFC 5321, section 4.1.1.1: Extended HELLO (EHLO) or HELLO (HELO): https://www.rfc-editor.org/rfc/rfc5321#section-4.1.1.1

---

Source: iBlockSpam, https://iblockspam.com/smtp-errors/550-5-7-506 (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt