5.7.506 "Access Denied, Bad HELO" means the connecting client introduced itself with a HELO or EHLO name that identifies Microsoft’s own servers rather than the sender. That pattern is a classic spam-bot signature, and Exchange Online rejects the connection outright.
Most common causes
- The SMTP client is configured with the destination hostname as its own HELO identity
- A copied mail-server configuration preserved the wrong hostname
- A relay or appliance generates an invalid EHLO name
What to verify next
- Run Reverse DNS & HELO Auditor for the sending host
- Capture the SMTP conversation and confirm the EHLO value
- Configure a stable fully qualified identity for the sending server
- Verify the corrected identity also resolves consistently where appropriate
What the HELO name should be
RFC 5321 requires the HELO argument to be the sending host’s fully qualified domain name. Presenting the destination’s hostname — or a bare label, a literal IP without brackets, or an unrelated name — is a misconfiguration. Presenting a Microsoft hostname is treated as impersonation.
The error typically comes from a copied mail-server configuration where the hostname field was set to the smart host, a relay appliance with its HELO derived from the wrong interface, or an application library defaulting to the remote host name.
Capture and confirm
Run the Reverse DNS & HELO Auditor for the sending host with the HELO name it uses; it checks whether the name resolves and matches reverse DNS. Better still, capture the SMTP conversation from the sending server and read the EHLO line directly.
Consistency between HELO, PTR and forward resolution is what receivers reward. Divergence is the profile of poorly maintained or compromised infrastructure.
- HELO must be the sender’s own FQDN.
- It should resolve to the connecting address.
- PTR, HELO and forward DNS should agree.
Fix on the sending system
Set the mail server’s hostname or HELO override to a fully qualified name under your domain that resolves to the sending address, and ensure the address has a matching PTR. Restart the service and send a test.
If a device or application is the source, check its SMTP settings for a hostname field, and consider routing it through a properly configured relay instead.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisReverse DNS & HELO Auditor
Check reverse identity, forward confirmation and SMTP greeting consistency.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- The rejection reflects the HELO of the connecting host, which may be a relay rather than the originating system.
- Some appliances do not expose the HELO setting; the vendor may need to be involved.
Common questions
We use a Microsoft smart host. Is that the HELO?
No. HELO is your server’s own identity, regardless of where it relays to. Do not use the smart host name.
Does the HELO need to match PTR exactly?
Not strictly, but consistency between HELO, PTR and forward DNS is what avoids suspicion.
Is this related to SPF?
Only indirectly. SPF can be checked against the HELO identity as well, so a proper HELO helps there too.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.