What HELO/EHLO is and why it matters
When an SMTP connection starts, the sending server introduces itself to the receiving server. Historically this was done with HELO; modern servers use EHLO, which also advertises SMTP extensions supported by the sender. As part of that greeting, the sender provides a name (ideally a domain name) that becomes its “SMTP identity” for the session.
HELO/EHLO is not an authentication protocol like SPF, DKIM, or DMARC. However, many receiving systems treat the greeting identity as a quality signal. A badly chosen HELO name can raise suspicion, complicate troubleshooting, and in some environments contribute to filtering decisions—especially when other signals (like IP reputation) are not yet strong.
Where HELO/EHLO fits in the SMTP conversation
In a simplified SMTP exchange, the TCP connection is established, the receiver presents a banner, and then the sender issues EHLO (or HELO). After that, the session may upgrade to TLS (STARTTLS), authenticate (AUTH on submission), and proceed with MAIL FROM, RCPT TO, and DATA.
Because EHLO happens so early, it often shows up prominently in logs and policy checks. If you ever have to investigate “why are we getting deferred?” or “why is that partner rejecting our mail?”, the recorded helo value is one of the first things you’ll look at.
Best practice: use a real FQDN as your HELO/EHLO name
The most reliable approach is to use a fully qualified domain name (FQDN) that you control, such as mail.example.com or mta1.example.com. Avoid single-label names (like “mail” or “server”), internal-only naming (“mail01.local”), or anything that looks random.
What a good HELO FQDN should look like
- Owned by your organization: It should be under a domain you control, not a third-party domain.
- Resolvable in public DNS: The name should have a corresponding A/AAAA record.
- Stable over time: Frequent HELO changes make pattern-based filtering and operational troubleshooting harder.
- Understandable naming for multiple servers: If you have multiple outbound MTAs or IPs, names like mta1/mta2 or smtp1/smtp2 are practical.
PTR (reverse DNS) and how it relates to HELO
A PTR record (reverse DNS) maps an IP address back to a hostname. Many receivers check whether the connecting IP has rDNS and whether it looks reasonable. Some also compare it to the EHLO identity or at least expect both to be plausible and consistent.
Reverse DNS is often treated as “infrastructure hygiene.” It doesn’t prove you’re authorized to send for a domain (that’s what SPF/DKIM/DMARC are for), but it helps show that the sending IP is intentionally operated and properly named rather than being an ephemeral or mismanaged host.
A practical consistency model
- IP PTR: 203.0.113.10 -> mail.example.com
- Forward A record: mail.example.com -> 203.0.113.10
- SMTP EHLO/HELO: mail.example.com
This “triangle” of consistency reduces false positives in some filtering stacks and makes your mail flow easier to support.
What fcrDNS is (and what it is not)
Forward-confirmed reverse DNS (fcrDNS) typically means: the PTR hostname for the connecting IP must resolve back to the same IP via A/AAAA. In other words, reverse points to a name, and the name points back to the same address.
fcrDNS should not be viewed as a security guarantee. It is, however, a common sanity check used by mail systems and security gateways. Failing it doesn’t always mean rejection, but it can contribute to higher spam scoring or stricter handling—especially for new senders or high-risk traffic patterns.
Common mistakes that can hurt deliverability
1) Using an IP address in EHLO
Some systems are configured to send “EHLO 203.0.113.10”. While not strictly forbidden, it often looks like low-quality automation and can be treated as a negative signal.
2) Using internal or non-resolvable names
Values such as “EHLO mail01.local” or “EHLO exchange01” do not resolve publicly and can trigger policy checks or simply make your organization look poorly configured.
3) Leaving a generic PTR in place
It’s common for providers to assign a default PTR like “static-203-0-113-10.isp.example”. This is not always fatal, but for business sending it’s usually better to set a PTR under your own domain to improve consistency and operational clarity.
4) Expecting multiple PTRs per IP to solve naming
Although multiple PTR records can exist, the ecosystem largely expects one clear reverse identity per IP. A single, consistent PTR is typically the cleanest approach.
Designing hostnames for multiple MTAs and multiple outbound IPs
If you send mail from multiple outbound IP addresses, assign each IP a dedicated hostname and align it end-to-end:
- 203.0.113.10 PTR -> mta1.example.com
- 203.0.113.11 PTR -> mta2.example.com
- Each server uses its own matching EHLO name
If a single MTA sends from a pool of IPs, some operators keep EHLO fixed. That can work, but it reduces transparency when troubleshooting because you lose a neat one-to-one mapping between “who said hello” and “which IP actually connected.” When possible, keep the identity clean and predictable.
The DNS pieces you need: A/AAAA and PTR (and who controls them)
Forward DNS (A/AAAA) for your hostname is managed in your domain’s DNS zone. PTR (reverse DNS) is usually managed by whoever owns the IP space: your hosting provider, data center, VPS provider, or ISP. This surprises many teams: you can’t always set PTR in the same DNS control panel where you manage your domain records.
A sensible change plan
- Pick a naming scheme: Decide on mail.example.com, mta1/mta2, etc.
- Publish A/AAAA records: Ensure the chosen names resolve to the correct IPs.
- Set PTR through the IP owner: Request or configure reverse DNS to point to your chosen hostnames.
- Update the MTA’s EHLO/HELO setting: Then monitor logs and recipient feedback.
DNS TTL planning can make forward-DNS changes more predictable, but PTR TTL is not always under your control.
How HELO relates to SPF/DKIM/DMARC
HELO/EHLO does not replace SPF, DKIM, or DMARC. SPF evaluates the connecting IP against the envelope sender domain (MAIL FROM). DKIM signs message content. DMARC evaluates alignment between authentication results and the visible From domain.
That said, receivers often assess multiple signals together. You can pass SPF and DKIM and still create unnecessary friction if your EHLO is obviously incorrect or your rDNS setup is inconsistent. Think of HELO and rDNS as foundational hygiene: not sufficient on their own, but missing them adds avoidable risk.
Quick pre-flight checklist
- Is EHLO a proper FQDN? Not a single word, not “.local”.
- Does the EHLO hostname resolve? A/AAAA exists and points where you expect.
- Does the outbound IP have a PTR? If not, configure it via the IP provider.
- Does PTR map back correctly (fcrDNS)? PTR name’s A/AAAA returns the same IP.
- Are your identities consistent? Banner, EHLO, and reverse DNS should form a coherent story.
- Are you monitoring after changes? Watch for 550/554 rejections, deferrals, and unusual spam-folder placement reports.
Conclusion: cleaner signals and fewer surprises
SMTP HELO/EHLO configuration is one of those small details that becomes very important when something goes wrong. Using a controlled FQDN, aligning it with PTR and forward DNS, and aiming for fcrDNS consistency helps reduce avoidable deliverability issues and speeds up troubleshooting with partners and mail gateways.
If you are standardizing your email setup as part of a migration or a DNS cleanup—whether on MX1Mail or any other well-managed business email environment—add HELO/EHLO and reverse DNS consistency to your checklist alongside SPF/DKIM/DMARC. It’s a practical step toward a more predictable mail flow.