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