Test SMTP HELO EHLO Commands Manually

Why manually testing HELO EHLO commands matters for deliverability

You send a message. The receiving server checks the first line of the conversation: HELO or EHLO. If it doesn’t match your domain, or if it’s missing, the email drops into the spam folder—or worse, gets rejected outright. No warning. No explanation.

HELO and EHLO aren’t just formality—they’re the identity card of your sending server. Misconfigure them, and your reputation takes a hit before a single email lands in an inbox.

Testing HELO/EHLO commands manually isn’t just for experts. It’s how you catch hidden issues that automated tools might overlook: typos, misaligned domains, or missing DNS records that block deliverability. You’ll see exactly what the receiving server sees—including when you fail the identity check before the message even begins.

Key takeaways

HELO/EHLO is the first SMTP command and defines your server’s identity; incorrect values trigger spam filters or rejections.
Manual testing reveals misconfigurations like mismatched hostnames or missing DNS entries before they damage sender reputation.
Automated verification tools can’t always expose identity-level issues—manual HELO/EHLO checks confirm whether your server presents itself as expected to receiving mail servers.

What happens when HELO EHLO commands fail

When your server sends mail without a valid HELO or EHLO command, or if the command is malformed or doesn’t match the reverse DNS of your IP, receiving mail servers may reject your message outright. This can happen immediately during the SMTP handshake, before any content is even processed. A missing or mismatched HELO/EHLO is a red flag that can trigger strict filters, leading to bounces, quarantines, or outright blocking.

How servers interpret HELO/EHLO failures

Receiving mail servers check the HELO/EHLO value as part of their initial validation. If the domain in the HELO command doesn’t resolve to your IP via reverse DNS (PTR record), or if the domain is invalid, the server may treat your connection as suspicious. This is especially true for large providers like Gmail and Microsoft, which use HELO/EHLO as a signal in their spam filtering stack.

According to RFC 5321, Section 4.1.1, the HELO command is required during SMTP negotiation. Skipping it is a violation of standard SMTP behavior, and while not all servers enforce it strictly, the ones that do see it as a sign of poor sending hygiene. Let's be clear: a missing or incorrect HELO/EHLO isn’t just a technicality—it can damage sender reputation over time.

Reputation and delivery risks

Some servers use the HELO/EHLO string as a reputation signal. If the domain you use has no known history, is recently registered, or is associated with known spam sources, the receiving server may classify your message as risky—even if the content is clean.

Misidentifying your server as a bot or a spam source increases the odds your mail gets flagged. This is especially true if your IP has been listed on a blocklist, or if your HELO domain doesn’t match the MAIL FROM domain, which raises red flags in advanced spam scoring systems.

That’s why it’s essential to test HELO/EHLO behavior manually before sending to real users. You can use tools like MxToolbox or IANA's RFC repository to validate your SMTP handshake. For teams doing bulk sending, a real-time verification API helps catch these issues early. Try testing your server's HELO/EHLO response with full SMTP debug tools, or integrate a verification API that checks email address validity and delivery readiness ahead of sending.

How to test HELO EHLO commands manually using Telnet

You can test HELO/EHLO commands manually by connecting to a mail server over Telnet on port 25 or 587, sending the EHLO command with your domain, and checking the server’s response. A successful response starts with 250 and lists supported extensions. If you get 501, 502, or 553, the server rejects the command. This helps diagnose connection issues before sending email.

Step-by-step: Manually testing HELO/EHLO with Telnet

Open your terminal or command prompt. You don’t need special software — Telnet is built into most systems and available by default.
Connect to the target mail server using the command telnet mail.example.com 25. Replace mail.example.com with the actual domain of the receiving server. Use port 587 if testing submission.
Wait for the server’s banner. It typically starts with 220, indicating the server is ready. This is your confirmation the connection succeeded.
Send the EHLO command: EHLO yourdomain.com. Replace yourdomain.com with your actual sending domain. This tells the server who you are and asks for supported features.
Observe the server’s response. A valid response starts with 250 and lists extensions like STARTTLS, SIZE, or AUTH. If the reply starts with 501, 502, or 553, the server rejected the HELO/EHLO — often due to invalid or suspicious domain syntax.

Understanding common responses

Responses like 250 mean the server accepted the command and listed supported features. That’s good: your HELO/EHLO is valid and the server is ready to proceed.

The 5 steps described in “Step-by-step: Manually testing HELO/EHLO with Telnet”, in order.

Responses starting with 5xx indicate errors. 501 means the server couldn’t parse the command — usually because the domain is malformed. 502 means the command isn’t supported or requires configuration. 553 often indicates rejected sender domains or issues with reverse DNS.

These tests are part of a broader email deliverability check. The same domains that fail HELO/EHLO are likely to be blocked or marked as spam. According to industry standards, RFC 5321 governs SMTP command behavior, including EHLO. The specification defines how servers must respond to HELO/EHLO, and deviations can trigger filters.

If you’re managing a bulk send list, use real-time tools to test each domain in your list before sending. MailTester offers bulk verification to spot domain-level issues early. Verify large email lists and catch rejected HELO/EHLOs before they hurt deliverability.

Common HELO EHLO command failures and their causes

You’ll fail HELO/EHLO validation if your server sends an IP address instead of a domain, uses a hostname that doesn’t match the reverse DNS record, includes invalid characters like spaces or symbols, or sends from a shared IP with a generic HELO like server123.contoso.net. These flaws trigger rejection by strict mail servers. Fixing them improves inbox placement and sender reputation over time.

Domain or IP misconfiguration

Don’t use an IP address in HELO/EHLO. Modern email systems require a proper domain name — sending HELO 192.0.2.1 is treated as invalid.
Ensure the reverse DNS (PTR record) for your sending IP points to the same hostname used in HELO. A mismatch often leads to rejection, especially from large providers like Gmail and Outlook.
Never include spaces, special symbols, or non-ASCII characters in the HELO/EHLO value. Only valid domain characters are allowed — a typo or stray punctuation breaks SMTP handshake.

Shared or compromised infrastructure

Using a generic HELO like server123.contoso.net or mailhost.example.com from a shared IP is a red flag. Many providers block traffic from such setups due to past abuse.
If you're on a shared server or using a third-party mail relay, confirm your HELO domain is unique, not reused across customers, and properly configured.
Check your sending IP against public blocklists like Spamhaus or MxToolbox. If it’s blacklisted, even correct HELO/EHLO won’t prevent rejection — you need to resolve the underlying reputation issue first.

SMTP is deterministic: a single failure in the pre-transaction phase can block delivery. Fixing HELO/EHLO early reduces hard bounces and protects sender reputation.

Let’s say you manage a bulk email campaign and notice high bounce rates. You check the logs and see 553 invalid HELO responses. You're not alone — this is a common cause of delivery failure, especially when automated tools or shared hosting providers generate generic HELO values. Testing your SMTP commands manually — including HELO/EHLO — is the fastest way to diagnose this.

Use tools like RFC 5321, Section 4.1.1 to confirm your HELO/EHLO syntax is valid, and always validate that your domain’s PTR record aligns with the HELO hostname. You can manually test this with telnet or OpenSSL commands, but for scale — especially in campaigns with thousands of addresses — verifying the list first reduces errors before sending.

If you’re testing your list before sending, use MailTester’s real-time email checker to catch invalid or risky addresses early, including those that may trigger HELO-related issues when sent from problematic infrastructure.

Testing HELO EHLO with a real email-verification service

You can test HELO and EHLO commands in real time with MailTester’s API during inbox-placement tests. It doesn't just check if the command is accepted—it verifies whether your domain's identity matches your sending infrastructure. This catches mismatches early, preventing delivery failures and protecting your sender reputation before you send.

How HELO/EHLO validation works in practice

When you send an email, your server starts with an EHLO or HELO handshake. A mismatch between the domain you claim and the one your IP is authorized to use can trigger filtering. MailTester’s real-time verification API includes this check as part of inbox-placement testing, scanning the actual SMTP exchange. It confirms whether your server responds appropriately and whether your declared identity aligns with DNS records like SPF and reverse DNS.

Let’s say your email is sent from mail.example.com but your reverse DNS resolves to mail123.spamhost.net. Even if the message passes other checks, this inconsistency can cause problems. MailTester detects this and flags it as a risk. This is not just about protocol compliance—it’s about reputation. According to RFC 5321, the initial HELO/EHLO must be a valid domain, and mismatched identities are commonly seen in low-deliverability campaigns.

Leverage real-world testing to reduce bounces

Manual HELO/EHLO testing is tedious and unreliable without access to actual mail servers. MailTester’s inbox-placement test automates this, simulating real delivery conditions across multiple providers. You get a realistic read on whether your setup will survive filtering, including HELO/EHLO alignment.

If your domain identity doesn’t match your server, ISPs may reject your messages or mark them as suspicious. MailTester’s checks help you find and fix these issues before they hit your list. This is especially important for senders using third-party services or shared IPs, where misidentification is common.

For developers and operations teams, this level of visibility is critical. You’re not just validating syntax—you’re validating the integrity of your entire sending stack. You can run these tests inline via the real-time verification API, integrate with platforms like SendGrid, or test individual addresses before sending in bulk using the email checker. The result: fewer bounces, lower risk of being flagged, and higher inbox placement in real campaigns.

To explore how MailTester catches these issues before they cost you reputation, try the inbox-placement tester or get started with 100 free verifications on the pricing page.

How real-time verification helps with HELO/EHLO issues

MailTester’s real-time verification API performs full SMTP checks, including EHLO/HELO negotiation, during inbox-placement tests. It catches mismatches between your sending domain and your server’s reported identity—common when using third-party SMTP relays or migrating servers—before they trigger rejections or spam filters. This early detection prevents delivery failures and protects your sender reputation.

Why HELO/EHLO mismatches cause problems

When you send an email, your server identifies itself using the HELO or EHLO command. Receiving mail servers check if the domain in that command matches your sending domain and your reverse DNS (PTR record). If it doesn’t, many systems flag the message as suspicious, especially if the sending IP is newly registered or unverified.

According to RFC 5321 (the SMTP standard), a server must report a valid, resolvable domain in its EHLO/HELO greeting. Failing that can lead to outright rejection or poor inbox placement—especially with providers like Gmail and Microsoft. These checks are non-negotiable in modern email infrastructure.

How MailTester catches these issues before they matter

During inbox-placement testing, MailTester simulates the full SMTP handshake, including the EHLO/HELO step. It verifies that the domain your server reports is valid, properly resolved to your IP, and matches your sending domain. If the server says it’s “mail.example.com” but you’re sending from “yourcompany.com,” we flag it.

This catches migration issues—like when moving from a legacy server to a new one—before your first batch of campaigns launches. It also exposes problems when using external services like SendGrid or Amazon SES, where the relay may report a different domain than your own.

Let’s say you’re setting up a new SMTP relay. You set it up, but forget to update the HELO domain. Without testing, your emails might be delayed or blocked. MailTester finds that mismatch during real-time verification and gives you a clear signal so you can fix it.

It’s not just about syntax. It’s about reputation. Repeated HELO mismatches across multiple messages can signal spoofing to filters. Even if the content is clean, these inconsistencies build red flags. By catching them with each verification, MailTester helps maintain inbox trust.

Use MailTester’s real-time API to test individual addresses or bulk lists. It runs a full SMTP validation loop, including HELO/EHLO, so you’re not relying on guesses or outdated configurations. You get actionable data—not just “valid” or “invalid,” but why a delivery fails.

With MailTester’s inbox placement test, you can verify how your message performs across major providers—including how the HELO/EHLO setup affects deliverability—before sending to real users. This is especially useful when auditing or onboarding new systems.

Run a full inbox placement test to see real-world results, including HELO/EHLO behavior across Gmail, Outlook, and Apple Mail.

Why domain-based HELO/EHLO is critical for sender reputation

You can’t build sender reputation on SPF, DKIM, and DMARC alone—those verify message authenticity, but HELO/EHLO confirms your server’s identity. If your HELO/EHLO doesn’t match your sending domain, email providers flag it as suspicious. A consistent, domain-based HELO/EHLO signals legitimacy, reduces bounce risk, and helps maintain long-term deliverability. Without it, even well-authenticated emails may land in junk folders.

HELO/EHLO: More Than Just a Protocol Step

HELO and EHLO are the first commands your mail server makes when connecting to a recipient’s SMTP server. They announce your sending domain. If you’re using a shared IP or a generic hostname like mailserver123.example.com, you’re sending a signal that says “I don’t belong here.” That mismatch can trigger alarms in modern spam filters.

Domain-based HELO/EHLO—where the greeting matches your public sending domain—aligns your server’s identity with your brand. It makes your setup predictable and trustworthy. This consistency strengthens your sender reputation over time, especially when combined with proper DNS records.

What Happens When Identity and Behavior Don’t Match?

Let’s say your SPF record allows mail.example.com, but your server announces smtp-75-123.net. That mismatch is a red flag. Email providers see it as a sign of poor infrastructure, impersonation risk, or even compromised systems. They may apply throttling, delay delivery, or mark your messages as low trust.

Over time, repeated inconsistencies hurt your reputation. Even if messages pass SPF/DKIM, the lack of alignment in server identification weakens overall trust. Reputable anti-spam systems like Spamhaus and MxToolbox track these patterns and adjust score thresholds accordingly. You can’t skip the basics—even if your DKIM is flawless.

Testing your HELO/EHLO commands manually—before sending—lets you catch mismatches early. Use a script or an SMTP client with verbose output to validate behavior. You can also use tools like MxToolbox or RFC 5321 to audit SMTP handshake behavior in real time.

If you’re sending at scale, verify your entire email infrastructure. MailTester’s inbox placement tester checks how real inboxes receive your messages, including how HELO/EHLO behavior affects delivery. You can also use our real-time verification API to validate domains and test server behavior before deployment.

HELO/EHLO best practices for email senders

You must use your sending domain (like smtp.yourcompany.com) in HELO/EHLO, not an IP or generic value. Ensure that domain has a matching PTR record, never reuse localhost or mailserver.example across servers, and always test new configurations before going live. These basics prevent rejection by receivers and help avoid being flagged as spam. For reliable results, verify your setup with real-world checks — we test this in our inbox placement tool.

Do it right: your HELO/EHLO value matters

Always set HELO/EHLO to your actual sending domain, such as smtp.yourcompany.com — never use an IP address or placeholder like localhost.
Verify that the domain in HELO/EHLO has a valid PTR (reverse DNS) record pointing to your sending IP. This is a standard requirement checked by major email providers.
Avoid reusing generic values like mailserver.example or smtp.domain.com across multiple servers. Each sending server should have a unique, meaningful identifier.
Use only a single, consistent HELO/EHLO domain per server to avoid triggering spam filters that flag inconsistent behavior.

Test before you send: validate your configuration

Before sending to real customers, manually test each new server or relay with tools that simulate SMTP exchange. Some providers require your HELO/EHLO to match both DNS and reverse DNS — a mismatch will fail validation.

Tools like MxToolbox or RFC 5321 provide standards-based guidelines for HELO/EHLO behavior — following these ensures alignment with recipient server expectations. Use a real SMTP client to check if your server’s response is accepted.

For high-volume senders, integrating verification into your workflow reduces risk. Test individual addresses before sending via our real-time email checker, or use our API to validate domains and servers programmatically.

Using MailTester’s inbox-placement testing for HELO/EHLO

You can test HELO/EHLO commands manually by simulating real email delivery through MailTester’s inbox-placement test. This tool validates your SMTP handshake—including HELO/EHLO identity—across Gmail, Outlook, and Apple Mail in real time, revealing if your server’s name is accepted or blocked by major providers. It’s the closest you can get to testing from the inbox provider’s perspective without sending actual mail.

How inbox placement tests validate HELO/EHLO

When your server sends mail, it begins with an EHLO or HELO command. The receiving mail server checks this identity against DNS, reputation, and known patterns. Many providers reject connections if the HELO/EHLO name looks malformed, generic, or inconsistent with the sending IP’s reverse DNS.

MailTester’s inbox-placement test sends a real, isolated message through the full SMTP transaction. During the handshake, it records whether the remote server accepts your HELO/EHLO value and logs any errors or rejections. This includes common issues like mismatched reverse DNS, missing SPF, or invalid host names.

What you learn from real inbox testing

You’ll see exactly how providers like Gmail and Outlook respond—not just to your deliverability score, but to the actual handshake. Some HELO/EHLO values that seem valid may still trigger filters if they’re listed in known bad pattern databases (such as those maintained by Spamhaus or MxToolbox).

For example, using a plain hostname like mail01.company.com might work fine with some providers, but Gmail may reject it if the reverse DNS doesn’t resolve cleanly or if the domain is associated with bulk senders. The test shows you which provider blocked your attempt—and why—based on the actual SMTP reply.

Testing this in advance helps you avoid deliverability issues before sending to real users. It’s not just about catching invalid addresses; it’s about ensuring your entire sending infrastructure—from DNS to handshake—meets inbox standards.

Use MailTester’s inbox placement tester to validate your HELO/EHLO identity with real-world providers. You can run it on individual addresses or test your full sending domain’s reputation.

What MailTester’s HELO/EHLO testing reveals

When you test SMTP HELO/EHLO commands manually, MailTester shows whether the recipient server accepts your server's greeting, if the domain matches DNS and reverse DNS records, and if it correctly advertises supported extensions like STARTTLS or ESMTP. You’ll see exactly how your server is perceived at the connection level—before any mail content is sent.

Key insights from HELO/EHLO tests

Whether the recipient mail server admits your HELO/EHLO hostname as valid at the TCP handshake stage, preventing early rejection.
If your HELO/EHLO domain has a matching reverse DNS (PTR) record, which major providers like Gmail and Outlook check for legitimacy.
Whether the server responds with expected ESMTP extensions—like STARTTLS, 8BITMIME, or PIPELINING—after EHLO, indicating proper configuration.
If the domain in your HELO/EHLO is a publicly resolvable, routable domain (not a local IP, loopback, or reserved network space).
Whether the server rejects the greeting outright or issues a warning, hinting at potential reputation or security issues.
How your server appears to recipients—especially when using shared IPs or generic hostnames like “mailserver.example.com” instead of a specific, verified domain.

Why this matters in practice

Many bounces and rejections happen before email content is even evaluated. A server that rejects your HELO/EHLO by design is not going to deliver your message, regardless of list quality or content. This step is critical for sender reputation.

For example, if your HELO domain doesn’t match your reverse DNS, or if the domain is non-existent or misconfigured, modern mail servers treat that as a red flag. This is a known pattern in spam filtering—see RFC 5321 section 4.1.1 for the standard requirements.

Let’s say your server says EHLO mail.example.com but no PTR record exists for that IP, or the domain resolves to a different IP. That mismatch triggers filters. Tools like MailTester surface these issues in real time, so you can fix them before sending to real users.

If you're verifying a list or building an email delivery pipeline, testing HELO/EHLO is a foundational step. It’s not just about syntax—it’s about how your sending infrastructure is perceived at the network layer. You can check a single address first with the email checker, or run bulk validations using our bulk verification tool to catch issues across multiple addresses.

Conclusion: HELO/EHLO is a silent delivery gatekeeper

HELO and EHLO are the first handshake in SMTP. A misconfigured or invalid value here can trigger automatic rejection, even if every other part of the email is correct.

Even small errors—like a missing or malformed domain—can lead to permanent blacklisting or deep filtering by recipient systems. This isn’t a rare edge case; it’s a common root cause of undelivered messages.

Proactive validation of HELO/EHLO isn’t an optional check. It’s a foundational part of any disciplined deliverability strategy. Test it manually or with a trusted tool like MailTester before your list ever sends.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What is the difference between HELO and EHLO in SMTP?

HELO is the original command used in SMTP. EHLO (Extended HELO) is its modern version, used to request extended SMTP features. Most servers now expect EHLO.

Can I use an IP address in the HELO command?

No. Using an IP address in HELO is uncommon and often rejected. Use a valid, configured domain name instead.

Why does my HELO command fail even with a valid domain?

The most common reason is reverse DNS (PTR) mismatch — the IP’s PTR record must match the HELO domain.

How do I check my server’s reverse DNS?

Use tools like dig or nslookup to query the PTR record for your IP. Ensure it resolves to the domain you’re using in HELO/EHLO.

Can MailTester test HELO/EHLO for me?

Yes. MailTester’s real-time API and inbox-placement tests include SMTP handshake validation, including HELO/EHLO behavior.

What happens if my HELO domain doesn't match the sending domain?

It raises suspicion and can be flagged by spam filters. It’s best to use the same domain for HELO/EHLO and your message From field.

Do I need to test HELO/EHLO every time I change my mail server?

Yes. Any change to the server IP or configuration should trigger a HELO/EHLO test to ensure no delivery issues arise.

Can HELO/EHLO cause my IP to be blacklisted?

Not directly, but frequent mismatches or abuse of HELO commands can lead to reputational damage and IP blacklisting.

What does a 501 response code mean during HELO/EHLO?

It means the server cannot handle the HELO/EHLO parameter — usually due to a malformed or invalid domain format.

Is HELO/EHLO required for every SMTP session?

Yes. Every SMTP transaction begins with HELO or EHLO. Without it, the session will fail or be rejected.

Can I use multiple HELO domains across different IPs?

Yes, but each domain must have a matching reverse DNS. Using different HELO domains on the same IP without proper configuration increases risk.

Are there tools to automate HELO/EHLO testing at scale?

MailTester’s API provides automated HELO/EHLO validation for bulk checks, including inbox placement and deliverability metrics.