When an SMTP connection starts, the sending server introduces itself to the receiving server. Historically this was done with HELO<\/strong>; modern servers use EHLO<\/strong>, 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 \u201cSMTP identity\u201d for the session.<\/p>\n 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\u2014especially when other signals (like IP reputation) are not yet strong.<\/p>\n 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.<\/p>\n Because EHLO happens so early, it often shows up prominently in logs and policy checks. If you ever have to investigate \u201cwhy are we getting deferred?\u201d or \u201cwhy is that partner rejecting our mail?\u201d, the recorded helo value is one of the first things you\u2019ll look at.<\/p>\n The most reliable approach is to use a fully qualified domain name (FQDN)<\/strong> that you control, such as mail.example.com or mta1.example.com. Avoid single-label names (like \u201cmail\u201d or \u201cserver\u201d), internal-only naming (\u201cmail01.local\u201d), or anything that looks random.<\/p>\n A PTR<\/strong> 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.<\/p>\n Reverse DNS is often treated as \u201cinfrastructure hygiene.\u201d It doesn\u2019t prove you\u2019re authorized to send for a domain (that\u2019s 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.<\/p>\n This \u201ctriangle\u201d of consistency reduces false positives in some filtering stacks and makes your mail flow easier to support.<\/p>\n Forward-confirmed reverse DNS (fcrDNS)<\/strong> 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.<\/p>\n 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\u2019t always mean rejection, but it can contribute to higher spam scoring or stricter handling\u2014especially for new senders or high-risk traffic patterns.<\/p>\n Some systems are configured to send \u201cEHLO 203.0.113.10\u201d. While not strictly forbidden, it often looks like low-quality automation and can be treated as a negative signal.<\/p>\n Values such as \u201cEHLO mail01.local\u201d or \u201cEHLO exchange01\u201d do not resolve publicly and can trigger policy checks or simply make your organization look poorly configured.<\/p>\n It\u2019s common for providers to assign a default PTR like \u201cstatic-203-0-113-10.isp.example\u201d. This is not always fatal, but for business sending it\u2019s usually better to set a PTR under your own domain to improve consistency and operational clarity.<\/p>\n 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.<\/p>\n If you send mail from multiple outbound IP addresses, assign each IP a dedicated hostname and align it end-to-end:<\/p>\n 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 \u201cwho said hello\u201d and \u201cwhich IP actually connected.\u201d When possible, keep the identity clean and predictable.<\/p>\n Forward DNS (A\/AAAA) for your hostname is managed in your domain\u2019s 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\u2019t always set PTR in the same DNS control panel where you manage your domain records.<\/p>\n DNS TTL planning can make forward-DNS changes more predictable, but PTR TTL is not always under your control.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n If you are standardizing your email setup as part of a migration or a DNS cleanup\u2014whether on MX1Mail or any other well-managed business email environment\u2014add HELO\/EHLO and reverse DNS consistency to your checklist alongside SPF\/DKIM\/DMARC. It\u2019s a practical step toward a more predictable mail flow.<\/p>\n","protected":false},"excerpt":{"rendered":" Learn how to set a proper SMTP HELO\/EHLO identity, align it with PTR and forward DNS, and avoid common hostname mistakes that can hurt deliverability.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[293],"tags":[383,446,226],"class_list":["post-170","post","type-post","status-publish","format-standard","hentry","category-email-deliverability","tag-email-infrastructure","tag-reverse-dns","tag-smtp"],"_links":{"self":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/170","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/comments?post=170"}],"version-history":[{"count":0,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/170\/revisions"}],"wp:attachment":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/media?parent=170"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/categories?post=170"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/tags?post=170"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Where HELO\/EHLO fits in the SMTP conversation<\/h2>\n
Best practice: use a real FQDN as your HELO\/EHLO name<\/h2>\n
What a good HELO FQDN should look like<\/h3>\n
\n
PTR (reverse DNS) and how it relates to HELO<\/h2>\n
A practical consistency model<\/h3>\n
\n
What fcrDNS is (and what it is not)<\/h2>\n
Common mistakes that can hurt deliverability<\/h2>\n
1) Using an IP address in EHLO<\/h3>\n
2) Using internal or non-resolvable names<\/h3>\n
3) Leaving a generic PTR in place<\/h3>\n
4) Expecting multiple PTRs per IP to solve naming<\/h3>\n
Designing hostnames for multiple MTAs and multiple outbound IPs<\/h2>\n
\n
The DNS pieces you need: A\/AAAA and PTR (and who controls them)<\/h2>\n
A sensible change plan<\/h3>\n
\n
How HELO relates to SPF\/DKIM\/DMARC<\/h2>\n
Quick pre-flight checklist<\/h2>\n
\n
Conclusion: cleaner signals and fewer surprises<\/h2>\n