5.7.506: access denied, bad HELO
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.
Access Denied, Bad HELO
Microsoft's text for 5.7.506, as listed in its Exchange Online NDR reference.
What 550 5.7.506 means
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.
Likely 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
If you sent the message
- 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.
If you're the recipient or their admin
- No action needed by recipients: the sending server has to identify itself correctly.
Frequently asked questions
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.
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)
- RFC 5321, section 4.1.1.1: Extended HELLO (EHLO) or HELLO (HELO)
Provider messages are quoted as the provider publishes them. Servers can change their wording, so the bounce you received may differ slightly.
Related codes
- 501 SMTP 501: syntax error in parameters or arguments
- 550 5.7.25 550 5.7.25: reverse DNS validation failed
- 550 5.7.1 550 5.7.1: delivery not authorized, message refused
- 550 5.7.512 5.7.512: access denied, message must be RFC 5322 section 3.6.2 compliant
- 550 5.7.510 5.7.510: access denied, recipient domain does not accept email over IPv6
- 550 5.7.501-503 5.7.501 to 5.7.503: access denied, spam abuse detected or banned sender
- 550 5.7.12 5.7.12: sender was not authenticated by organization
Related guides
Reverse DNS and PTR records for mail servers
What a PTR record is, why Gmail, Yahoo and others require forward-confirmed reverse DNS for sending IPs, who can set it, and how to check yours is right.
8 min read Email security basicsWhat is a mail transfer agent (MTA)?
What a mail transfer agent does, how it differs from the MUA, MSA and MDA, how MTAs queue, retry and relay mail, and where spam filtering sits in the path.
9 min read Email security basicsWhat is SMTP and how does it deliver email?
How SMTP moves email between servers: the EHLO, MAIL FROM, RCPT TO and DATA dialogue, envelope vs header From, relays, retries and what reply codes mean.
9 min read