HELO/EHLO Validation

Test how a mail server responds to the HELO/EHLO command, a critical part of the SMTP protocol used for server identification.

Evidence ASSESSED

Checked against: SMTP EHLO banner and hostname · RFC 5321 §4.1.1.1

RED TEAM 0 findings BLUE TEAM control did not hold

Understanding HELO/EHLO

HELO (and its modern successor EHLO) is the first command sent by a client after connecting to an SMTP server:

Identification: It tells the receiving server who is connecting.
Feature Negotiation: EHLO allows the server to list supported extensions like STARTTLS, AUTH, or SIZE limits.
Security: Many spam filters reject connections if the HELO hostname doesn't match the connecting IP's reverse DNS (PTR) record.
Compliance: RFC 5321 requires that a client sends HELO or EHLO to initiate the mail transfer session.

Our HELO/EHLO Validation checks the hostname your mail server announces when it opens an SMTP connection, and verifies it against the three conditions receivers test: a valid forward record, matching reverse DNS, and a fully qualified name.

What is HELO/EHLO?

HELO and EHLO are the commands an SMTP client sends to identify itself when opening a connection. EHLO is the extended form, used by essentially all modern servers because it also elicits the list of supported extensions.

The argument is a hostname — the name the connecting server claims to be. RFC 5321 requires it to be a fully qualified domain name that resolves, and receiving servers treat it as a basic identity claim to be verified rather than accepted.

The verification is straightforward. Does the announced name have a valid A or AAAA record? Does the reverse DNS of the connecting address match it? Are all three consistent? Failing any of these does not usually cause outright rejection on its own, but it contributes to a spam assessment that other factors then compound.

The hostname a mail server announces when connecting
EHLO is the extended form and also lists server extensions
RFC 5321 requires a fully qualified, resolvable name
Receivers verify it against forward and reverse DNS
Inconsistency contributes to spam scoring

Why HELO Validation Matters

The HELO hostname is the first thing a receiving server learns about you, before the sender address and long before the content. It is a cheap consistency check that legitimate senders pass trivially and misconfigured or spoofed senders frequently fail.

The specific failure that matters most is inconsistency between HELO, reverse DNS and the forward record. Any one of the three can be set by a different party — the HELO by your mail software, the PTR by your hosting provider, the A record by your DNS — so agreement between them indicates deliberate configuration rather than a default left in place. That is precisely what receivers are looking for.

The first identity claim a receiving server can evaluate
Consistency across three independently controlled records indicates real configuration
Default values such as localhost are a strong negative signal
Contributes to spam scoring at nearly every receiver
Cheap to fix and commonly overlooked

How This HELO Validation Works

The tool connects to the mail server and verifies the hostname it announces.

Validates the host input against format and SSRF safety checks
Opens an SMTP connection and reads the greeting
Extracts the hostname the server announces
Resolves that hostname forward to an A or AAAA record
Compares it against the reverse DNS of the connecting address

How to Use HELO Validation

Enter your mail server hostname in the input field
Run the validation to connect and read the greeting
Confirm the announced name is fully qualified
Check that it resolves forward to the server address
Confirm the reverse DNS of that address matches the announced name

Understanding Your HELO Validation Results

Validation checks several independent conditions:

Field / Value	Meaning
`Fully qualified`	The announced name includes a domain, such as mail.example.com rather than just mail. A bare hostname violates RFC 5321 and is penalised by most receivers.
`Forward resolution`	The announced name has a valid A or AAAA record. A name that does not resolve is an unverifiable claim and is treated as such.
`Reverse match`	The PTR record of the connecting address matches the announced name. The strongest of the checks, since it requires cooperation from the address block owner.
`Full consistency`	All three agree. This is the goal, and it is what distinguishes deliberate configuration from a default left in place.
`localhost or IP`	Announcing localhost, localhost.localdomain or a bare IP address. These are default values that were never configured, and receivers penalise them heavily.
`Domain mismatch`	The announced name belongs to a different domain than the mail is sent from. Not necessarily wrong for hosted mail providers, but worth understanding when it appears.

Common Problems & How to Fix Them

These are defaults that were never changed, and receivers treat them as a clear signal of a misconfigured or disposable sender.

Set the HELO hostname explicitly in your mail server configuration. In Postfix the setting is myhostname; in Exim it is primary_hostname; in Microsoft Exchange it is set per send connector. Use a fully qualified name on a domain you control.

The name is an unverifiable claim, since receivers cannot look it up to confirm anything about it.

Add an A record for the announced hostname pointing at the mail server address. mail.yourdomain.com is the conventional choice, and it should resolve to the same address the server connects from.

This is the most consequential mismatch, because it is the check receivers weight most heavily.

Make all three agree. Set the PTR record through your hosting provider to match the HELO hostname, and ensure that hostname has a forward A record pointing back to the same address. The PTR is the part you cannot set yourself, so it usually requires a provider ticket.

When several outbound servers share one HELO name, only one of them can have matching reverse DNS, so the others fail the consistency check.

Give each server its own hostname — mail1, mail2 and so on — each with its own PTR record and matching forward record. Consistency must hold per server, not per organisation.

This is normal and expected. When you use Google Workspace or Microsoft 365, their servers announce their own names with their own consistent DNS, and that is correct.

You do not need to change anything. Your responsibility in that arrangement is SPF, DKIM and DMARC alignment rather than the HELO hostname, which is not yours to configure.

Best Practices

Set the HELO hostname explicitly rather than relying on a default
Use a fully qualified name on a domain you control
Ensure the hostname has a forward A record pointing at the server
Set reverse DNS to match the announced hostname
Give each outbound server its own hostname and PTR record
Verify the configuration after any infrastructure change or server rebuild
Use a name that indicates the role, such as mail or smtp, rather than an internal identifier

Security Recommendations

Treat HELO consistency as one signal among several rather than as authentication, since the announced name is simply a claim
Remember an attacker can announce any hostname they like, which is why the reverse DNS check matters more than the claim itself
Avoid hostnames that disclose internal infrastructure roles or naming conventions
Verify HELO configuration after every server rebuild, since it commonly reverts to a default
Combine HELO validation with SPF, DKIM and DMARC, which provide the actual authentication
Consider rejecting connections announcing localhost or bare IP addresses on your own inbound servers

Frequently Asked Questions

HELO is the original command; EHLO is the extended version that also asks the server to list its supported extensions. Modern servers use EHLO and fall back to HELO only for very old implementations.

A fully qualified name on a domain you control, conventionally something like mail.yourdomain.com. It must have a forward A record pointing at the server, and the reverse DNS of that address should match it.

Because the two are set by different parties — your mail software and your address block owner — so agreement indicates deliberate configuration rather than a default. Receivers use it as a cheap consistency check that misconfigured senders fail.

Rarely on its own, but it contributes to spam scoring at nearly every receiver and compounds with other weak signals. Announcing localhost or a bare IP address is penalised heavily and some receivers do reject on it.

In Postfix set myhostname, in Exim set primary_hostname, and in Microsoft Exchange configure it per send connector. Cloud mail services manage it themselves and it is not yours to change.

No. Their servers announce their own hostnames with their own consistent DNS, which is correct. Your responsibility in that setup is SPF, DKIM and DMARC alignment rather than HELO configuration.

You can, but only one of them can have matching reverse DNS, so the others fail the consistency check. Give each server its own hostname with its own PTR and forward records.