Your outbound mail is “working” until it isn’t. Then one morning Sales reports that proposals arrive hours late,
password resets show up after the user has rage-clicked “resend” twelve times, and your monitoring is green because the queue
is technically draining… just not at a human pace.
One of the quietest causes is also one of the dumbest: your SMTP server introduces itself with a bogus HELO/EHLO name.
Big providers notice. Some will throttle you. Others will outright refuse you. And the worst part is you can run like this
for months—until a policy tweak, an IP reputation wobble, or a new outbound relay pool turns your “minor misconfig” into
an incident.
What HELO/EHLO is really used for (and why providers care)
SMTP starts with introductions. The client connects, the server presents a banner, and then the client says either:
HELO (old-school) or EHLO (extended SMTP). That single line includes a “name” the client
claims as its identity. It’s not authentication. It’s not a cryptographic proof. It’s an assertion—often honest, sometimes sloppy,
occasionally malicious.
Receiving providers still care because HELO/EHLO acts like a cheap, early signal. It’s part of a broader consistency story:
does the connecting IP’s reverse DNS look sane, does it align with the claimed name, does the TLS certificate name match the
presented identity, does the envelope sender domain have SPF, does DKIM pass, does DMARC align, does behavior match history?
HELO/EHLO is one thread in that tapestry. A frayed thread won’t always sink you. Enough frayed threads, and you’re in the slow lane.
In practice, providers treat a bad HELO/EHLO as one of:
- Misconfigured infrastructure (not malicious, but not professional)
- Compromised host (desktop PC pretending to be a mail server)
- Bulk sender cutting corners (because corners are where deliverability dies)
What counts as “bad”? The greatest hits:
- HELO/EHLO is
localhost,localhost.localdomain, or some internal hostname. - HELO/EHLO is an IP literal or bracketed IP when it shouldn’t be.
- HELO/EHLO is a domain with no A/AAAA record.
- HELO/EHLO is a domain that resolves, but doesn’t match reverse DNS policy expectations.
- HELO/EHLO changes unpredictably across retries or across a relay pool.
If you run production email, you want the receiving side to see a stable, routable, fully qualified domain name (FQDN) that you control,
with matching forward and reverse DNS where possible. Not because a spec demands perfection, but because deliverability is an ecosystem
of heuristics, and you don’t get to vote.
Interesting facts and historical context
Six-to-ten quick points, because history explains today’s weird policies:
- HELO predates most modern anti-spam thinking. Early SMTP assumed cooperative networks; “identity” was mostly for logging and routing sanity.
- EHLO arrived with ESMTP to negotiate features. It’s not just a greeting; it unlocks extensions like SIZE and STARTTLS depending on the server.
- Reverse DNS became an anti-abuse workhorse in the spam era. Providers leaned on rDNS because it was expensive for botnets to maintain consistently.
- Some receivers still treat “no PTR record” as suspicious. It’s not always an RFC violation, but it’s a strong correlation with junk mail sources.
- HELO checks existed in early MTA configs long before SPF. Many Postfix/Sendmail rule sets used HELO sanity checks as cheap filtering.
- IP reputation systems incorporate greeting anomalies. An EHLO of
localhostfrom a public IP looks like a compromised machine, because it often is. - TLS made identity more complicated. You now have banner name, EHLO name, and certificate name; inconsistencies can trigger scoring penalties.
- Cloud scaling increased the odds of mismatch. Autoscaling pools and ephemeral hostnames make it easy to ship an MTA that “works” but introduces itself badly.
- Deliverability became product-critical. Password resets and MFA codes aren’t “marketing email”; throttling becomes an availability issue.
How a wrong HELO/EHLO fails in production
1) Soft throttling that looks like “random slowness”
Many providers prefer to throttle rather than reject. They’ll accept a small trickle and defer the rest with temporary failures
(4xx responses). Your MTA retries. The queue grows. Eventually, users scream.
The smoking gun is not a total outage; it’s a time-to-delivery cliff. And because retries can “eventually succeed,” on-call sometimes
shrugs and goes back to the “real” outage. That shrug is how you end up with a permanent slow lane.
2) Hard rejects with unhelpful error strings
Some receivers reject with “bad HELO” or “invalid hostname,” which is at least honest. Others return vague policy failures.
If your logs don’t preserve the remote reply text, you’ll misdiagnose it as “provider being flaky.”
3) Reputation decay: you don’t notice until you do
A wrong EHLO can be tolerated when your IP/domain reputation is pristine. Later, one compromised account sends a burst of spammy mail,
or a new outbound IP warms up poorly, and suddenly the receiver’s scoring flips. Your HELO misconfig becomes the convenient excuse to penalize you.
4) TLS and identity mismatches pile on
If your EHLO says mail.example.com but your TLS cert is for smtp-out.example.net, and your PTR is for
ec2-203-0-113-10.compute-1.amazonaws.com, you’ve built a small museum of inconsistency. No single mismatch is always fatal.
The collection is.
Paraphrased idea from Werner Vogels (Amazon CTO): “Everything fails all the time; design to detect and recover.” Email identity is part of detection—just on the receiver’s side.
Joke #1: Your mail server saying “HELO localhost” is like showing up to a customer meeting wearing a badge that says “Hi, I’m someone else.”
Nobody gets arrested, but nobody trusts you either.
Fast diagnosis playbook
When delivery slows or bounces spike, don’t start by rotating API keys or blaming DNS “in general.” Do this, in order, and you’ll usually
find the bottleneck in under 20 minutes.
First: confirm whether the receiver is deferring or rejecting you
- Check outbound logs for 4xx deferrals and their text.
- Identify top recipient domains being deferred (Gmail, Microsoft, Yahoo, custom corp domains).
- Confirm whether the same recipients succeed hours later (classic throttling behavior).
Second: capture the exact SMTP conversation your client presents
- Banner you receive from the remote.
- Your EHLO/HELO string.
- Whether STARTTLS changes anything.
- Whether the remote complains explicitly about HELO/EHLO.
Third: verify identity alignment (EHLO ↔ forward DNS ↔ reverse DNS ↔ TLS)
- Does the EHLO name resolve (A/AAAA)?
- Does the connecting IP have PTR, and does it look sane?
- Does PTR resolve back to the connecting IP (forward-confirmed reverse DNS), where feasible?
- Is your TLS certificate name consistent with what you claim you are?
Fourth: check MTA config and sender routing
- Are you using multiple relays or NAT egress IPs?
- Is your HELO overridden per transport, per sender, or per relayhost?
- Did an “optimization” change it recently (container image, autoscaling template, new relay)?
Fifth: only then chase SPF/DKIM/DMARC
Those matter enormously. But when you’re debugging throttling that started right after you moved outbound IPs or rebuilt mail nodes,
HELO/EHLO and reverse DNS are the fastest win. Get your introduction right before you negotiate trust.
Practical tasks: commands, outputs, decisions
These are real checks you can run from a mail host or a nearby diagnostic box. Every task includes:
a command, sample output, what it means, and what decision you make.
Task 1: See what your server sends as EHLO (from logs)
cr0x@server:~$ sudo grep -R "EHLO" /var/log/mail.log | tail -n 5
Jan 03 09:12:41 mx1 postfix/smtp[22104]: <remote>: EHLO localhost
Jan 03 09:13:02 mx1 postfix/smtp[22177]: <remote>: EHLO mx1.internal
Jan 03 09:13:30 mx1 postfix/smtp[22230]: <remote>: EHLO mail.example.com
Jan 03 09:14:05 mx1 postfix/smtp[22301]: <remote>: EHLO localhost.localdomain
Jan 03 09:14:40 mx1 postfix/smtp[22392]: <remote>: EHLO mail.example.com
What it means: Your clients are presenting inconsistent EHLO values: localhost, internal names, and a proper FQDN.
Decision: Stop the randomness. Configure a single, stable EHLO name for outbound SMTP and ensure all nodes use it.
Task 2: Reproduce the SMTP conversation with OpenSSL (STARTTLS)
cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com < /dev/null
CONNECTED(00000003)
---
220 mx.google.com ESMTP
---
no peer certificate available
---
What it means: You can reach port 25 and get a banner. This only proves connectivity, not your EHLO. You need to actually speak SMTP.
Decision: Use an interactive session to send EHLO and observe server responses (next task).
Task 3: Speak SMTP interactively and see if EHLO triggers policy
cr0x@server:~$ nc -v gmail-smtp-in.l.google.com 25
Connection to gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!
220 mx.google.com ESMTP
EHLO localhost
550-5.7.1 Invalid HELO/EHLO domain. See https://support.google.com/mail/?p=InvalidHelo
550 5.7.1 Bad HELO/EHLO
What it means: The receiver explicitly rejects your EHLO value. That’s not a “reputation” ghost story; it’s a concrete misconfiguration.
Decision: Fix EHLO name immediately. Until then, retries won’t help; you’re getting a policy block.
Task 4: Validate the EHLO name resolves (forward DNS)
cr0x@server:~$ dig +short A mail.example.com
203.0.113.10
What it means: The EHLO name has an A record. That’s table stakes.
Decision: Keep going: also check AAAA and whether this IP is actually your egress.
Task 5: Check AAAA presence (don’t surprise yourself with IPv6)
cr0x@server:~$ dig +short AAAA mail.example.com
What it means: No IPv6 record. That’s fine if you’re not sending over IPv6. It’s also a hint: if you are sending over IPv6, you might be using a different name/path.
Decision: Confirm which IP family your MTA actually uses to reach major providers.
Task 6: Identify the actual outbound IP (don’t guess)
cr0x@server:~$ curl -s ifconfig.me
203.0.113.10
What it means: This host’s default egress public IP is 203.0.113.10 (at least for HTTP). SMTP might still differ if you have policy routing or a relay.
Decision: Cross-check with logs and NAT/firewall rules; don’t assume “curl IP” equals “SMTP IP.”
Task 7: Check reverse DNS (PTR) for the outbound IP
cr0x@server:~$ dig +short -x 203.0.113.10
mail.example.com.
What it means: PTR points to mail.example.com. This is the good path: the IP claims a name you control.
Decision: Ensure your EHLO name matches this PTR (or at least is in the same controlled domain with consistent forward DNS).
Task 8: Check forward-confirmed reverse DNS (FCrDNS)
cr0x@server:~$ host mail.example.com
mail.example.com has address 203.0.113.10
What it means: PTR → name, and name → same IP. Many receivers like this symmetry.
Decision: If this fails, fix DNS before you chase MTA tuning. Receivers use this as a trust hint.
Task 9: Inspect what Postfix thinks your hostname/HELO is
cr0x@server:~$ sudo postconf -n | egrep '^(myhostname|mydomain|smtp_helo_name|smtp_helo_timeout|smtp_host_lookup|inet_protocols)'
myhostname = mx1.internal
mydomain = internal
inet_protocols = all
What it means: Your myhostname is an internal-only name, and you haven’t set smtp_helo_name. Postfix may use $myhostname as EHLO. That’s how you end up saying “hi, I’m mx1.internal” to Gmail.
Decision: Set myhostname to a public FQDN orsmtp_helo_name to the public FQDN used for outbound greetings (often safer when internal naming must remain).
Task 10: Apply a safe Postfix EHLO fix (and verify)
cr0x@server:~$ sudo postconf -e 'smtp_helo_name = mail.example.com'
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf smtp_helo_name
smtp_helo_name = mail.example.com
What it means: Outbound SMTP should now use mail.example.com for EHLO.
Decision: Immediately retest with a remote SMTP session (Task 3), and watch for policy response changes.
Task 11: Confirm Exim’s HELO setting (if you run Exim)
cr0x@server:~$ sudo exim -bP helo_data
helo_data =
What it means: No explicit HELO override is set. Exim will derive it from system hostname in many setups.
Decision: If system hostname is internal or unstable, set a consistent helo_data to a public FQDN and ensure DNS matches.
Task 12: Verify the system hostname isn’t sabotaging you
cr0x@server:~$ hostname -f
mx1.internal
What it means: Your OS believes its FQDN is internal. Many MTAs default to this for greetings unless overridden.
Decision: Either correct the host’s FQDN to a public name (if appropriate) or explicitly configure the MTA’s helo name for outbound traffic.
Task 13: Check what you present on the receiving side (banner vs EHLO)
cr0x@server:~$ sudo postconf -n | egrep '^(smtpd_banner|myhostname)'
myhostname = mx1.internal
smtpd_banner = $myhostname ESMTP
What it means: Your inbound banner advertises mx1.internal. That’s not the same as EHLO, but it’s another identity surface. Some receivers and scanners correlate these signals when your server acts as a client elsewhere (relays, smarthost chains).
Decision: If this host is publicly reachable, fix myhostname and banner. If it’s outbound-only behind a relay, prioritize outbound EHLO but avoid broadcasting internal domains if possible.
Task 14: Confirm you’re not accidentally sending from IPv6 with broken rDNS
cr0x@server:~$ postconf -n | grep inet_protocols
inet_protocols = all
What it means: Postfix can use IPv6. If your network has IPv6 egress but no PTR for the v6 address, you can get throttled or blocked in ways that look “random,” because some destinations prefer v6.
Decision: If you can’t maintain IPv6 rDNS and reputation yet, consider inet_protocols = ipv4 temporarily while you fix v6 properly.
Task 15: Observe real-time queue pressure while you fix identity
cr0x@server:~$ mailq | head -n 20
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2A81C04E* 2199 Fri Jan 3 09:10:12 noreply@example.com
user@gmail.com
(host gmail-smtp-in.l.google.com[142.250.102.26] said: 550 5.7.1 Bad HELO/EHLO (in reply to EHLO command))
What it means: The queue explicitly records the remote rejection tied to EHLO. That’s your root cause in plain text.
Decision: Fix EHLO and then flush the queue selectively. Don’t blindly purge—your users want their mail.
Task 16: After fixing, force a retry and confirm acceptance
cr0x@server:~$ sudo postqueue -f
cr0x@server:~$ sudo tail -n 20 /var/log/mail.log
Jan 03 09:22:10 mx1 postfix/smtp[24511]: 3F2A81C04E: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=716, delays=715/0.01/0.2/0.3, dsn=2.0.0, status=sent (250 2.0.0 OK 1704273730 a1-20020a170902d1c100b003d7f9c0d1a9si1234567plb.123 - gsmtp)
What it means: The message was accepted (2.0.0). Your fix likely worked. The long delay reflects the time it spent failing before correction.
Decision: Monitor for sustained improvement: queue depth, deferrals per domain, and complaint rates. One successful send is not a trend.
Common mistakes: symptoms → root cause → fix
1) Symptom: Gmail rejects with “Bad HELO/EHLO”
Root cause: EHLO is localhost, internal domain, or invalid (no dot, no DNS).
Fix: Configure outbound HELO/EHLO to a public FQDN you control (Postfix: smtp_helo_name; Exim: helo_data), and ensure it resolves.
2) Symptom: Microsoft 365 accepts some mail then defers heavily (4xx)
Root cause: Inconsistent identity: rotating EHLO names across nodes/IPs, or EHLO doesn’t align with PTR/reputation.
Fix: Standardize EHLO across the sending pool and align reverse DNS per IP. If you use multiple egress IPs, each should have sane PTR in the same domain family.
3) Symptom: Deliverability fine for weeks, then suddenly slow after a rebuild
Root cause: New image/template reverted hostname to localhost.localdomain or changed cloud-init behavior. MTA now greets incorrectly.
Fix: Codify HELO in configuration management. Add a post-deploy integration test that speaks SMTP and checks EHLO string.
4) Symptom: Only some destinations fail, others fine
Root cause: Different providers have different HELO strictness; some are forgiving, some are not. Or you’re dual-stack and only IPv6 path fails.
Fix: Check per-domain logs and confirm which IP family is used. If IPv6 is the culprit, fix v6 rDNS or temporarily force IPv4.
5) Symptom: Receiver says “HELO name does not resolve”
Root cause: Your EHLO name has no A/AAAA record, or split-horizon DNS means it only resolves internally.
Fix: Publish public DNS for the EHLO name. Don’t use an internal-only zone name for public SMTP identity.
6) Symptom: Receivers complain about “invalid hostname” even with a FQDN
Root cause: You used underscores, illegal characters, or a name that violates basic hostname rules.
Fix: Use a plain DNS hostname: letters, digits, hyphens, dots. No underscores. Keep it boring.
7) Symptom: You “fixed” EHLO but throttling persists
Root cause: The IP reputation is now damaged, or your PTR/TLS/SPF alignment is still messy. HELO was one of multiple penalties.
Fix: Verify rDNS and TLS name consistency, then evaluate SPF/DKIM/DMARC alignment and sending patterns. Expect a warm-up period if you changed identity signals recently.
8) Symptom: Everything works from one node, fails from another
Root cause: Pool nodes have divergent configs: hostname, MTA parameters, NAT egress, or DNS resolver behavior.
Fix: Treat MTA identity config as immutable infrastructure. Audit all nodes, diff configs, and enforce with CI/CD.
Three corporate mini-stories from the mail trenches
Mini-story 1: The incident caused by a wrong assumption
A mid-size SaaS company moved outbound mail from a couple of pets (hand-managed VMs) to a small autoscaled pool.
The team did the right big things: DKIM signing, SPF updates, DMARC policy in monitor mode, queue monitoring.
They assumed the greeting was “just cosmetic.” It wasn’t.
The new images came from a hardened baseline. Good stuff: CIS-ish sysctls, locked-down SSH, sane logging.
But the baseline also set the system hostname to the instance ID. Postfix picked it up. The pool introduced itself to the world
as ip-10-2-3-4 and sometimes localhost depending on boot timing and cloud-init.
For a week, nobody noticed. Most corporate recipients were permissive, and the volume wasn’t huge.
Then a big provider started deferring more aggressively, and the retry backoff did what it does: built a queue.
Support tickets arrived with the worst phrase in operations: “intermittent.”
The on-call tried rate limits, added more nodes, and watched the queue get larger—because scaling out a misconfiguration is how you turn a bug into a lifestyle.
Finally someone pulled one raw SMTP transcript and saw the EHLO. The fix took five minutes. The apology tour took two days.
The lesson wasn’t “read the RFC.” It was simpler: never assume identity surfaces are cosmetic. In email, “cosmetic” signals are often the only signals receivers have.
Mini-story 2: The optimization that backfired
A finance company wanted faster outbound throughput for time-sensitive statements and alerts. Their mail team tuned concurrency and pipelining,
and they deployed multiple egress IPs to distribute load. On paper: good engineering.
Then they “optimized” the HELO to be unique per node, thinking it would help with troubleshooting. Each server greeted as
mx-out-01.example.com, mx-out-02.example.com, and so on. They forgot the nasty detail: reverse DNS was only updated for half the IPs,
and some EHLO names didn’t even exist in public DNS yet.
Within days, deliverability became uneven. Some recipients got mail instantly, others hours later. The new behavior created a false narrative:
“It must be content filtering.” So they tweaked templates and headers and went down the wrong rabbit hole.
The real story was that they’d increased their identity variance while simultaneously increasing sending volume. That’s exactly when providers tighten the screws.
More IPs plus more EHLO names multiplied the opportunities for mismatch.
The eventual fix was unglamorous: reduce the HELO set to a single stable name, align PTR for every outbound IP, and roll out changes with a canary node.
The “optimization” for debugging made the system harder to debug because the receiver side started treating them as inconsistent senders.
Mini-story 3: The boring but correct practice that saved the day
A healthcare org ran their own outbound relay because they needed tight control for auditing and message handling.
They were conservative: one primary name, documented DNS ownership, strict config management, slow and steady changes.
Nobody got promoted for it. That’s usually a good sign.
One quarter, they had to rotate outbound IPs due to a network provider change. This is where organizations often melt down:
PTR changes take time, old IP reputation evaporates, and every vendor’s “just update DNS” advice is incomplete.
They had a checklist that included HELO alignment as a first-class item: the new IPs received PTR records pointing to mail.example.org,
forward DNS already mapped that name to the correct IP, and Postfix had smtp_helo_name pinned.
They also had a canary: one low-volume relay took the new route first.
When one provider started deferring the canary’s traffic, they caught it early, limited blast radius, and adjusted by temporarily reducing concurrency
for that destination while reputation warmed. The main pool never hit a queue crisis.
Their “boring practice” was simply treating SMTP identity as an interface contract, not a suggestion. It didn’t prevent all pain, but it made the pain containable.
Joke #2: Email deliverability is like plumbing—nobody wants to pay for it, and everyone notices the minute it smells funny.
Checklists / step-by-step plan (safe rollout)
Step-by-step plan: fixing HELO/EHLO without creating a second incident
-
Pick one outbound identity name.
- Use a stable FQDN you control, like
mail.example.comorsmtp.example.com. - Avoid per-node names unless you have strong reasons and equally strong DNS hygiene.
- Use a stable FQDN you control, like
-
Ensure the name resolves publicly.
- Publish A (and AAAA if you send over IPv6) for the chosen name.
- Don’t rely on split-horizon DNS for an internet-facing identity.
-
Align reverse DNS for every outbound IP.
- Set PTR to a hostname in your domain family.
- Prefer PTR that matches your EHLO exactly, or at least matches your sending domain’s namespace.
-
Set the MTA’s outbound HELO explicitly.
- Postfix: set
smtp_helo_name. - Exim: set
helo_data(and verify per-transport if needed).
- Postfix: set
-
Audit pool consistency.
- Diff
postconf -nacross nodes. - Confirm no node uses a different resolver or search domain that alters hostname resolution.
- Diff
-
Canary the change.
- Shift a small percentage of outbound mail through one node or one egress IP with corrected HELO.
- Watch deferrals and bounces per destination domain.
-
Deploy gradually, then flush queues carefully.
- After fix, you can
postqueue -f, but be aware of rate limits: you may slam providers and trigger fresh throttling. - Consider staged flushing by destination if volumes are large.
- After fix, you can
-
Add a regression test.
- In CI or post-deploy, run an SMTP conversation against a test receiver that asserts the EHLO string.
- Make it fail the build if EHLO contains
localhostor an internal suffix.
Operational checklist: what “good” looks like
- EHLO name is a valid FQDN, stable across retries and nodes.
- EHLO name has public A/AAAA records.
- Outbound IP has PTR that is sane and preferably aligned with EHLO.
- PTR hostname resolves back to the outbound IP (FCrDNS).
- TLS certificate name is consistent with mail identity (especially if you terminate TLS yourself).
- Logs retain remote reply strings for rejects/deferrals (so you can see “Bad HELO” instead of “delivery failed”).
- Queue monitoring includes per-destination deferral rates (because “queue size” alone is a liar).
FAQ
1) Is HELO/EHLO the same as the domain in the “From:” header?
No. HELO/EHLO is the SMTP client greeting. “From:” is a message header that users see.
Receivers correlate many identities, but they are different layers and can differ legitimately (relays, third-party senders, etc.).
2) If I have SPF/DKIM/DMARC, can I ignore HELO/EHLO?
Don’t. Authentication helps, but providers score consistency. A broken EHLO is still a sign of sloppy infrastructure or malware.
You’re trying to look like a real mail system, not win an argument with a spec.
3) What should I set the EHLO name to in Postfix?
Usually a single stable FQDN like mail.example.com. In Postfix, set smtp_helo_name to that value.
Ensure it resolves publicly and aligns with your outbound IP’s PTR.
4) Should EHLO match reverse DNS exactly?
“Should” depends on your environment, but exact match is the least controversial choice.
If you can’t make it exact (multiple IPs, provider constraints), keep it within the same domain family and keep DNS consistent.
5) Can I use an IP address in HELO/EHLO?
Avoid it. Some systems accept bracketed address literals, but many receivers treat it as suspicious.
Use a valid FQDN with proper DNS instead.
6) My hostnames are internal by policy. Can I keep them internal?
You can keep the OS hostname internal and still present a public EHLO for outbound SMTP by configuring it explicitly in the MTA.
That’s often the cleanest compromise between internal naming policies and external deliverability reality.
7) Why did this break “suddenly” if it was wrong for months?
Because receivers change scoring, your traffic patterns change, and your IP reputation changes. A minor penalty becomes decisive when other signals degrade.
Also: infrastructure changes (new images, new NAT, IPv6 enablement) can silently alter the greeting name.
8) What about inbound SMTP—does my smtpd_banner matter?
Yes, especially if your server is internet-facing. A banner advertising localhost or internal names looks amateurish and can affect how other MTAs treat you.
It’s not the same as outbound EHLO, but it’s part of your mail server’s public identity.
9) Does HELO/EHLO affect TLS?
Indirectly. Some receivers correlate the EHLO name with TLS certificate names and SNI behavior.
Mismatches add up. You want a coherent story: name, DNS, IP, and cert shouldn’t contradict each other.
10) If I use a third-party relay (smarthost), do I still care?
Yes, but differently. If you hand mail to a relay, their EHLO and IP reputation controls delivery to final recipients.
Your risk shifts to the SMTP session between you and the relay: make sure you present a sane identity and don’t trigger their policy limits.
Conclusion: next steps you can ship this week
HELO/EHLO is not glamorous. It’s a single line of text. And it can absolutely ruin your week.
Providers read it as a competence signal. When you send “EHLO localhost,” you are telling them your infrastructure is either mismanaged or compromised.
They respond accordingly: throttle, defer, reject.
Practical next steps:
- Pick a stable outbound FQDN for EHLO and make sure it resolves publicly.
- Align PTR for every outbound IP and confirm forward-confirmed reverse DNS where feasible.
- Set EHLO explicitly in your MTA (don’t rely on OS hostname defaults).
- Canary and observe deferrals/bounces per destination before full rollout.
- Add a regression test so the next rebuild doesn’t reintroduce “localhost” into production email.
Do the boring identity work now. Your future incident channel will be quieter, and your users will stop treating email like a roulette wheel.