Try SMTPing

550 Access Denied: Invalid HELO Name: Causes and Fix

Alaa Alaa
22 July 2026
12 Views
SMTP Codes
Alaa
By Alaa
SMTPedia documents email infrastructure end to end: SMTP standards from the RFC archive, delivera...
3 min read Updated Jul 22, 2026 37 views
PERMANENT FAILURE · X.7.x SECURITYFIX HELO HOSTNAME

SMTP response received

550 Access denied: Invalid HELO name

You received this code because the receiving mail server refused delivery because the hostname your MTA announced in EHLO or HELO did not pass the receiver validation rules. Common triggers: the announced hostname is unqualified (a bare word rather than a fully qualified domain name), contains a bracketed IP literal, does not resolve in DNS, or does not match the reverse DNS of the sending IP. This is a permanent policy rejection driven by the receiver anti-spoofing posture, per RFC 5321 section 4.1.1.1 which requires a fully-qualified primary hostname in the SMTP greeting. The fix is on your sending MTA configuration: publish the right hostname and make sure DNS agrees.

๐Ÿ‘ค Who sees this code

  • Operator of a self-hosted Postfix, Exim, or Sendmail server whose outbound mail bounces at strict receivers
  • Ops team migrating email between cloud instances where the default hostname is a bare cloud-generated string like ip-10-0-1-24 or localhost.localdomain
  • Deliverability lead debugging a new outbound relay that ships with vendor defaults for the SMTP banner

๐Ÿ”ง What this guide fixes

  • Identify the exact hostname currently being sent in EHLO / HELO from your outbound MTA
  • Configure your MTA to announce a fully-qualified hostname that resolves and matches reverse DNS
  • Verify the fix with a manual SMTP dialogue and confirm the next production send succeeds

โšก Do these 3 things first (before diving deeper)

1

Capture the exact EHLO or HELO your MTA sends

The receiver rejects based on the specific string your MTA offered as its identity. Grab it directly from the SMTP conversation. In Postfix, enable smtp_helo_name logging via debug_peer_list = destination.example.com and reproduce a failing send. In Exim, check helo_data in the smtp transport. Alternatively, use openssl s_client -connect mx.example.com:25 -crlf and read the greeting. The exact string sent is what the receiver evaluated.

2

Verify the announced hostname resolves in DNS

The hostname you send in EHLO must resolve to an A or AAAA record that maps back to your sending IP. Run dig +short A your-helo-name.example.com and confirm the returned IP matches your outbound IP. If DNS returns NXDOMAIN, the receiver flags the HELO as unresolvable. Modern receivers (Gmail, Yahoo, Microsoft, Proofpoint) uniformly require the HELO to resolve. Legacy MTAs that ship with defaults like localhost or a private hostname will fail this test.

3

Check that reverse DNS of your sending IP matches the HELO

Beyond DNS resolution, the receiver often checks that the reverse DNS (PTR record) of your sending IP resolves to the same hostname you announced in EHLO. This forward-confirmed reverse DNS (FCrDNS) is the gold standard identity check. Run dig -x YOUR.SENDING.IP.HERE and confirm the returned hostname matches your HELO. Our PTR and rDNS records guide covers the full FCrDNS setup pattern.

Common causes of 550

  1. HELO hostname is unqualified or a bare word. RFC 5321 section 4.1.1.1 requires a fully-qualified primary hostname in EHLO. Strings like localhost, mailserver, or a bare instance name are rejected by strict receivers. Cloud VMs frequently ship with a default hostname that is not a valid FQDN. Application-level SMTP libraries sometimes default to localhost.localdomain or the OS hostname without qualifying it. Either scenario produces 550 Access denied: Invalid HELO name at Gmail, Microsoft, and Yahoo.
  2. HELO hostname does not resolve in DNS. Even a syntactically valid FQDN triggers rejection if DNS does not have a matching A or AAAA record. This is common when: a private hostname is announced in a public SMTP dialogue, DNS records were never published for the sending host, or a typo in the MTA configuration produced a hostname that looks correct but has no DNS entry. Verify with dig +short A your-helo-name.example.com and publish the missing A record if needed.
  3. HELO announces an IP literal instead of a hostname. RFC 5321 allows a bracketed IP address literal in HELO ([192.0.2.10]) but virtually every modern receiver rejects this at RCPT TO or later. Bracketed IPs are a strong spam signal because legitimate mail servers use named hostnames. If your MTA is configured to fall back to a bracketed IP when the hostname is unavailable, override that fallback and hard-code a proper FQDN.
  4. Forward-confirmed reverse DNS (FCrDNS) mismatch. Even when the HELO hostname resolves in DNS, receivers cross-check that reverse DNS of your sending IP matches. If your PTR record points to a shared hosting hostname (like colo-123.provider.example.com) but you announce your own domain in HELO, the mismatch triggers rejection. Fix by publishing a matching PTR record at your hosting provider, then aligning your HELO to that PTR value. Full walkthrough in 550 5.7.25 PTR reverse DNS.
  5. HELO name matches the receiver own domain (spoofing signal). Sending EHLO with a hostname that matches the receiver own MX or domain triggers immediate rejection as a spoofing attempt. Some misconfigured relays echo the destination hostname back in HELO, producing 550 Access denied because Gmail treats an inbound connection announcing "gmail.com" as clearly forged. The fix is to always send YOUR domain in EHLO, never the destination domain, regardless of what the destination MX returns in banner.

How to fix 550, step by step

  1. Set the Postfix HELO hostname explicitly. In /etc/postfix/main.cf: myhostname = mail.yourdomain.com and smtp_helo_name = $myhostname. This overrides any default and forces every outbound SMTP conversation to announce mail.yourdomain.com. Reload with postfix reload. Test by sending to a monitored inbox and check the Received header, it captures the exact HELO your MTA sent. The full Postfix parameter map is documented in our Postfix guide.
  2. Set the Exim primary_hostname and helo_data. In Exim, define primary_hostname = mail.yourdomain.com in the main configuration, then in the smtp transport add helo_data = $primary_hostname. Restart Exim. For sites that need per-destination HELO customization (rare, but happens with multi-tenant relays), helo_data accepts Exim string expansion so you can compute it dynamically.
  3. Set the Sendmail confDOMAIN_NAME and confCLIENT_OPTIONS. In Sendmail, edit /etc/mail/sendmail.mc and add define(`confDOMAIN_NAME',`mail.yourdomain.com')dnl. Rebuild the .cf with m4 sendmail.mc > sendmail.cf and reload. Sendmail also supports per-connection HELO override via the SendmailOptions M4 directives if you need fine-grained control.
  4. Publish DNS A and PTR records aligned with your HELO. The HELO hostname you announce must resolve to an A record that returns your sending IP, and the PTR record of your sending IP must resolve back to the same hostname. Contact your hosting provider to set the PTR record, most cloud providers expose this in the console. Then publish or verify the A record at your DNS host. Once both agree, the forward-confirmed reverse DNS check passes at every major receiver. See our PTR and rDNS guide for the exact steps per provider (AWS, GCP, Azure, DigitalOcean, Hetzner).
  5. Verify with a live SMTP dialogue. Confirm the fix works end to end: openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp -crlf. Send EHLO mail.yourdomain.com manually and observe Gmail response. A clean 250 response with capability list means your HELO passes. Also send a test message with swaks: swaks --to test@gmail.com --server gmail-smtp-in.l.google.com --ehlo mail.yourdomain.com. The exercise proves the full path, not just the HELO step.
  6. Monitor Received headers on delivered messages. After the fix, inspect the Received header on messages delivered to a monitored inbox. The header captures the HELO string exactly as the receiver saw it. Consistent mail.yourdomain.com in Received headers across Gmail, Microsoft, and Yahoo confirms the fix stuck. If any receiver still shows the old bad HELO, that path is caching stale connection metadata or your MTA has multiple outbound routes and only some were updated. Audit all outbound paths, not just the primary. Reference the Authentication-Results header for the sibling auth verdicts.

๐ŸŒ How each provider sends this exact code

Provider
Exact response
Likely cause
Gmail (gmail-smtp-in)
550 5.7.1 Access denied: Invalid HELO name
HELO does not resolve or FCrDNS mismatch
Microsoft 365 (protection.outlook.com)
550 5.7.1 HELO is not a valid FQDN
EOP requires fully-qualified HELO
Yahoo (Nemesis ESMTP)
553 Requested action not taken: Bad HELO command
Yahoo rejects unqualified or IP literal HELO
Postfix (smtpd_helo_restrictions = reject_invalid_helo_hostname)
550 Invalid HELO name
Receiver Postfix enforcing HELO syntax

โš– How this code differs from adjacent ones

Code
Real meaning
Action
450 4.7.1 Cannot find your hostname
Transient version of HELO/rDNS failure
Same fix, retry once corrected
553 5.7.1 HELO is SLD
HELO announces a second-level domain
Use full FQDN, not bare domain
421 Offline: HELO/rDNS mismatch
Transient FCrDNS failure
Fix FCrDNS then retry

Prevention going forward

Invalid HELO rejections stem from operational drift: the hostname your MTA announces gets out of sync with DNS, PTR, or the receiver expectations. Preventing recurrence is about tying HELO, DNS A record, PTR record, and TLS certificate CN to one consistent identity that changes together.

  • Standardize on one canonical sending hostname across MTA configuration, forward DNS A record, PTR record, and TLS certificate common name. Any drift between these four surfaces produces receiver rejections. Consider infrastructure-as-code to enforce consistency.
  • Audit HELO strings quarterly by sending test mail to a monitored inbox at Gmail, Microsoft, and Yahoo, then parsing the Received header. Store the observed HELO values in a monitoring dashboard and alert on any change.
  • Publish PTR records for every outbound IP at your hosting provider on day one of provisioning. New cloud instances default to generic PTR values like ec2-1-2-3-4.compute-1.amazonaws.com that receivers correctly flag as generic. Our PTR guide has provider-specific console steps.
  • When migrating email infrastructure, verify HELO configuration on the new stack BEFORE cutting over production traffic. A common migration failure mode is default HELO on the new server passing internal tests but failing the moment production volume hits stricter external receivers.
  • Combine HELO discipline with strong SPF, DKIM, and DMARC alignment. Receivers combine identity signals (HELO, PTR, SPF, DKIM, DMARC) into a composite trust verdict. HELO discipline alone is a hygiene baseline; the auth stack is what carries deliverability.

Frequently asked questions about 550

What is the difference between HELO and EHLO?
EHLO is the extended version introduced in RFC 1869 and codified in RFC 5321. Both greet the receiver and announce the sender hostname. EHLO additionally triggers the receiver to advertise supported extensions (STARTTLS, PIPELINING, 8BITMIME, etc.) in a multi-line response. Modern MTAs always send EHLO first; if the receiver responds with a syntax error or does not support extensions, the sender falls back to HELO. From the invalid-hostname perspective, both are treated identically by receivers: the argument you pass must be a valid FQDN that resolves. 550 Access denied applies regardless of whether the client used HELO or EHLO.
Why does Gmail reject my HELO when internal servers accept it?
Internal servers often accept whatever HELO you send because they trust the connection based on network location (allowlisted subnet, VPN, private route). External receivers like Gmail have no basis for that trust and enforce the RFC 5321 requirement that HELO be a resolvable FQDN. Internal delivery success gives you false confidence. The right test is a live SMTP dialogue to gmail-smtp-in.l.google.com from outside your network. If that fails, Gmail is signalling exactly what strict receivers will do at scale once you send production volume.
Can I use a bracketed IP literal in HELO?
RFC 5321 allows it syntactically (HELO [192.0.2.10]) but virtually every modern receiver rejects on that basis alone. Bracketed IP literals correlate strongly with spam sources, so receivers treat them as a soft signal. Do not send bracketed IPs in production. Always send a hostname, and make sure that hostname resolves. If your MTA is falling back to an IP literal because the configured hostname is empty, fix the configuration.
How is HELO validation different from SPF or DMARC?
HELO validation checks the syntactic and DNS validity of the hostname argument you pass in the EHLO/HELO command. It happens at the connection level, before any authentication. SPF, DKIM, and DMARC are authentication mechanisms that happen after the SMTP envelope is delivered. HELO validation is preliminary hygiene; if you fail it, the receiver rejects before evaluating anything else. Some receivers (like Microsoft EOP with strict anti-spoofing policy) combine HELO signals with DMARC alignment, so a HELO fix often improves DMARC pass rates as a side effect.
What if my sending IP has a shared PTR record that I cannot change?
This is common on shared hosting and cheap VPS providers. If you cannot get a dedicated PTR record for your IP, you have two options: migrate to a hosting provider that supports custom PTR (all major clouds do, most reputable VPS providers do), or route your outbound mail through a reputable SMTP relay that handles the HELO/PTR concerns for you (SendGrid, Mailgun, SES, Postmark). Trying to send high volume from an IP with a shared PTR record produces persistent rejections at every strict receiver and is not fixable through configuration alone.
Do I need to change HELO when I add a new outbound sending IP?
Not necessarily. The HELO string identifies your sending server, not the specific IP. If you add a second outbound IP that shares the same sending server (multi-homed host), the HELO stays the same and you publish a matching PTR for the new IP pointing to the same hostname. If you add a completely separate outbound server (different hostname), that server sends its own HELO with its own hostname. The consistent rule: whatever HELO you send, DNS forward and reverse must agree with it for that specific IP.

Stop 550 bounces before they happen.

SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes before you send. Fewer bounces means less firefighting and a healthier sender reputation. 13 validation types, 25 free daily, no card required.

Try SMTPing free โ†’

About the Author

Alaa - SMTPedia author

Alaa ยท LinkedIn

Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. Iโ€™ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.

About SMTPedia

SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.

We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.

SMTP Codes

551 5.1.1 Recipient Is Not Exist: Causes and Fix

 SMTP Codes

451 Sender Host Not Yet Authorized to Deliver

 SMTP Codes

585 5.1.1 Recipient Address Rejected: Undeliverable

 SMTP Codes

453 You Are Trying to Use Me as a Relay

      No widgets added. You can disable footer widget area in theme options - footer options