EHLO と HELO は、SMTP セッションのいちばん最初に登場するたった2つの短いコマンドですが、メール配信性、スパム判定、そしてメールボックスプロバイダがあなたの送信トラフィックを「正当なもの」と見なすかどうかに、大きな影響を与えることがあります。
ログに「HELO domain」「EHLO string」「HELO does not resolve」といった表記を見たことがあるなら、それはまさにこの“握手”の部分を指しています。多くのチームがこの存在に気づくのは、何かが壊れたときです。メールが急に迷惑メールに入る、メールゲートウェイが接続を拒否する、あるいは DMARC のプロジェクトでレポート上に不審なトラフィックが浮かび上がる、といったタイミングです。
このガイドでは、EHLO/HELO とは何か、どのように機能するのか、良い設定とは何か、そしてよくある問題の切り分けと修正方法を解説します。
あるメールサーバーが別のメールサーバーに SMTP で接続するとき、最初に「自分は誰か」を名乗ります。歴史的には、その挨拶が HELO（元祖 SMTP の挨拶）でした。その後 SMTP が拡張され（ESMTP と呼ばれます）、挨拶は EHLO（Extended HELO）になりました。
ポイントはシンプルです。
この挨拶にはホスト名（場合によってはドメイン名）が含まれます。この値はしばしば HELO domain や EHLO name と呼ばれます。ここで重要なのは、これはユーザーがメールクライアントで見る「From」ドメインとは別物だということです。HELO/EHLO はサーバー同士の識別子であり、接続時の信頼性チェックやレピュテーション評価に使われます。
典型的な SMTP 配送の順序に当てはめると、EHLO/HELO の位置が見えやすくなります。
DMARC が評価するのは可視の「From」ドメインのアライメントですが、多くのメールボックスプロバイダやセキュリティゲートウェイは、HELO/EHLO も次の用途で重要なシグナルとして見ています。
まず前提として、DMARC は EHLO/HELO に「基づいて」判定するものではありません。DMARC は、可視の「From」ドメインと、SPF もしくは DKIM の認証結果のアライメントを評価します。ただし、HELO/EHLO がメール運用に影響するポイントはいくつかあります。
SPF は、あるドメインがその送信元を許可しているかどうかを評価します。SPF で検査に使われる「ドメイン」は通常 MAIL FROM（Return-Path）ドメインですが、SPF には HELO identity という概念もあります。受信側によっては、他のシグナルが怪しいときに「HELO/EHLO 名が妥当で一貫しているか」を補助的に見ます。
DMARC の実施（enforcement）に向けて SPF のアライメントを整える段階では、こうしたインフラ由来のシグナルも同時に整備するケースが多いです。手順は DMARC問題のトラブルシューティングと解決方法 で詳しく説明しています。
SPF、DKIM、DMARC を正しく設定していても、SMTP の挨拶が明らかにおかしい場合、配信性に影響が出ることがあります。たとえば次のようなケースです。
これは特に大量送信で受信箱到達率（inbox placement）を重視する送信者にとって重要です。より広いチェックリストは DMARCによるメール配信性の向上 を参照してください。
健全な SMTP の挨拶は、地味で、一貫していて、検証可能です。理想的なセットアップはだいたい次のルールに沿います。
mail.yourdomain.com、smtp.yourdomain.com）。DMARC を初めて導入する際に送信インフラも整備する場合、DNS 作業を含む全体手順は 完全なDMARC実装ガイド が参考になります。
自社運用の MTA、アプライアンス、古いシステムなどでよく起きます。受信側から見ると「設定ミス」か、悪意があって身元を隠しているように見えることもあります。
修正：MTA が公開用の FQDN を名乗るように設定します。例：
myhostname を設定し、SMTP 挨拶に使われていることを確認。primary_hostname を調整。多くのゲートウェイは「HELO は解決できるべき」というチェックを行います。ハードリジェクトしなくても、信頼スコアが下がりフィルタリングが強くなることがあります。
修正：挨拶に使うホスト名に対して A/AAAA レコードを公開します。自分で DNS を触れない場合でも、DNS 管理者に依頼すれば短時間で対応できることが多いです。
大量送信では、送信 IP に PTR がない、または PTR が無関係な名前を指していることで問題が起きがちです。スパムフィルタは、reverse DNS の欠落や不一致を「品質の低いインフラ」のシグナルとして扱うことがあります。
修正：送信 IP に PTR を設定し、あなたが管理するホスト名（たとえば mail.yourdomain.com）を指すようにします。さらに、そのホスト名が送信 IP に解決し戻ることを確認します。
ESP、CRM、チケッティング、決済などのベンダーを使っている場合、SMTP の挨拶をあなたが制御できないことがあります。それ自体は問題ではありません。現実的なゴールは、認証とアライメントが正しく、ベンダー側のインフラが安定していることです。
修正：ベンダーのオンボーディングを構造化します。まず SPF、DKIM、DMARC のアライメントを検証し、配信性に問題が出る場合に reverse DNS などの補助シグナルも評価します。
これは必ずしも間違いではありません。SMTP 挨拶のホスト名と Return-Path ドメインが別になる構成は一般的です。ただし、すべてがバラバラで「意図が見えない」状態だと、他の問題（苦情率の増加、エンゲージメント低下、認証失敗など）と組み合わさって疑わしく見られることがあります。
修正：一致させることよりも「正しく、安定していること」を優先します。全識別子を同一にする必要はありませんが、どれも DNS 的に整合し、設定として意図が見える状態にするのが重要です。
どこまで手を動かせるかに応じて、確認方法はいくつかあります。
DMARC の作業中に認証失敗が多発している場合は、まず認証とアライメントの問題を解消し、その後に HELO の一貫性などの二次的シグナルを整えると効率的です。ワークフローは DMARC問題のトラブルシューティングと解決方法 にまとめています。
Google と Yahoo は大量送信者に対する基準を引き上げています。公開されている要件は主に認証（SPF、DKIM、DMARC）とユーザー体験シグナル（苦情率、解除のしやすさ）に焦点がありますが、実運用の配信性は、信頼できる SMTP アイデンティティのような基本的なインフラ衛生にも依存します。
コンプライアンス関連の配信エラーや、わかりにくいバウンスメッセージを調べている場合は、こちらが補助ガイドとして役立ちます：DMARCモニタリングとコンプライアンス：2026年完全ガイド。
DMARCeye は、EHLO や HELO のような低レイヤーの SMTP シグナルが、認証や配信性の結果とどう結びつくかを理解するのに役立ちます。EHLO/HELO 自体は DMARC の評価対象ではありませんが、SMTP 接続レイヤーの問題は、認証失敗、想定外の送信元、異常なトラフィックパターンといった形で間接的に表面化することがよくあります。
DMARC の集計レポートを解析し、送信 IP やインフラ挙動と相関させることで、DMARCeye は次のことを可能にします。
自社管理インフラで EHLO/HELO の問題がある場合、reverse DNS の欠落、送信ホストの不安定さ、認証アライメントの不完全さなど、他の課題と同時に発生していることが少なくありません。DMARCeye は、何を優先して修正すべきかを判断し、変更が認証成功率や配信性の改善につながったかを検証するための可視化を提供します。
今すぐ DMARCeye の無料トライアル に登録して、メールドメインの保護を始めましょう。