Gmail SMTPの設定方法：ポート・認証・アライメント

設定方法の選び方

Googleの3つの方法の使い分けです。

• SMTPリレーサービス（推奨）：smtp-relay.gmail.comをポート25、465、587のいずれかで使います。GoogleはIPアドレスでメッセージを認証するため、管理者がリレーのポリシーを設定する必要があり、固定のパブリックIPアドレスが必要になる場合もあります。組織の内外に送信する必要がある管理下の機器やアプリに選びます。この方法の上限は、ユーザーあたり一日最大10,000人の受信者とGoogleは案内しています。
• Gmail SMTPサーバー：smtp.gmail.comを、TLSならポート587、SSLならポート465で使い、GmailまたはGoogle Workspaceの完全なアドレスと、アカウントで許可された認証情報で認証します。1つのアプリが1つのメールボックスとして送信する場合に選びます。この方法の上限は一日2,000通とGoogleは案内しています。
• 制限付きGmail SMTPサーバー：aspmx.l.google.comをポート25で使います。SMTP認証もTLSも不要ですが、GmailとGoogle Workspaceの受信者にしか送信できません。Googleは管理者に、機器やアプリのIPアドレスを確認して許可リストに登録するよう指示しています。ほかの方法の認証やTLSの要件を満たせず、ほかの受信者に届ける必要もない古い機器に限って選びます。

これらの設定と上限はGoogle Workspace管理者ヘルプによるものです。認証、受信者、ポリシーの前提をそのままにして、接続先だけを入れ替えないでください。

Googleの現在のドキュメントでは、選択肢とその値が分けて示されています。

方法は、ポートだけでなく、アカウントと送信パターンから選びます。

ソフトウェアが現在のGoogle OAuthフローに対応しているなら、アプリパスワードの例をOAuthのパラメータに置き換えるのではなく、その製品の公式なGoogle連携手順に従ってください。OAuthのクライアント、スコープ、同意、トークンはアカウントごとに異なり、汎用的なホストとポートの表では扱えません。

Gmail SMTPサーバーの設定手順

1. テストの送信者と範囲を決める

管理下のメールボックス1つと、表示されるFromアドレス1つを使います。例として、アプリがalerts@example.comから送信し、alerts@example.comとして認証し、一日300通未満のトランザクション通知を送り、Gmailの受信者と組織が管理するメールボックスにテストを一通ずつ届けるとします。本番のメーリングリストから始めないでください。

2. 接続先と転送の値を入力する

認証付きの送信では、ホストにsmtp.gmail.com、ポートに587を入力し、STARTTLSかクライアントで同等のTLSアップグレード設定を選びます。クライアントが暗黙的SSLを必要とする場合は、ポート465を使います。認証を必須にし、ユーザー名にはアカウントの完全なアドレスを入力します。この認証付き送信の例では、ポート25は使わないでください。

3. 許可された認証情報を使う

アカウントの現在の認証ポリシーに従います。Googleとアプリが明示的にアプリパスワードに対応している場合は、2段階認証プロセスを有効にした後にそのアプリ用に作成し、シークレットとして保管します。通常のGoogleパスワードを非対応の機器に入力したり、アプリパスワードをリポジトリにコミットしたり、スクリーンショットに写したりしないでください。ポリシーでこの方法が禁止されている場合は中止し、対応している連携かリレーの構成を選びます。

4. 表示される送信者を許可する

最初のテストでは、認証するメールボックスと表示されるFromアドレスを同じにします。別のFromを使うには、確認済みのエイリアス、委任、リレーのポリシー、アプリ固有の許可が必要になる場合があります。235の認証成功やSMTPの250の受理は、任意のドメインに対する「Send As」の権限を与えるものではありません。

5. 追跡できるメッセージを一通送る

件名はSMTP validation 2026-08-25 14:30 UTCのようにし、gmail-smtp-630184のような秘密でない実行IDを含めます。アプリ側の時刻、接続先、ポート、From、受信者、サーバーの応答を記録します。記録に認証情報や顧客データを含めないでください。

この設定がDMARCに与える影響

SMTP認証が答えるのは、アプリがGoogleの送信サービスを使えるかどうかです。DMARCが答えるのは、認証されたドメインが表示されるFromアドレスのドメインと一致するかどうかです。両者は別の仕組みです。

example.comの送信元がGoogle Workspaceだけなら、GoogleのSPF手順ではv=spf1 include:_spf.google.com ~allを最初のレコードとしています（Google WorkspaceのSPF設定）。ほかにも送信元があるドメインは、2つ目のSPFレコードを公開するのではなく、ルックアップの上限内で1つに統合したSPFポリシーを作る必要があります。

Google WorkspaceのDKIMは、テナントが生成するTXTの値を使います。Googleの設定手順では、標準で2048ビットの鍵が選ばれ、セレクタの既定値はgoogleです。アカウントで生成されたホスト名と値を管理コンソールからコピーします。例の値や他のアカウントの鍵は絶対に再利用しないでください。Googleによると、Gmailを有効にしたばかりのテナントでは、DKIM鍵を生成できるまで24〜72時間かかることがあります（Google WorkspaceのDKIM設定）。

ベンダーが公開している現在の手順に、テナントがレコードを生成する場所が示されています。

アカウントで生成した値を使い、模式図のサンプルレコードは使いません。

RFC 9989は、DKIMとSPFについてrelaxedとstrictのアライメントを定義しています。DMARCに合格するのは、対応する仕組みの少なくとも1つが認証に成功し、その識別子がRFC5322のFromドメインと一致する場合です（RFC 9989のセクション4.4）。そのため、Googleが署名したメッセージでも、DKIMの署名ドメインとSPFで認証されたドメインのどちらも一致しなければ、SMTPでは受理されてもexample.comのDMARCには不合格になります。

設定の検証方法

DNSの値を確認する

SPF、DKIMセレクタ、_dmarc.example.comのレコードを、複数の公開リゾルバーで照会します。テナントが生成したDKIMのホスト名と値が完全に一致するか比べます。DNSにレコードがあるだけでは、Googleがテストメッセージに署名している証明にはなりません。

ベンダーの状態を確認

DNSを公開した後、Google管理コンソールで、対象のドメインのDKIM認証が有効になっているか確認します。Googleの手順では「認証を開始」を使うよう説明しており、ステータスはAuthenticating email with DKIMと表示されます（GoogleのDKIM検証）。表示名は変わることがあるため、記憶にあるスクリーンショットではなく、現在のテナントの案内に従ってください。

届いたメッセージのヘッダーを確認する

テストメッセージのソースを開き、受信側が追加したAuthentication-Resultsを探します。受信側の信頼境界の外で追加されたフィールドが信頼できない理由は、RFC 8601のセクション1.2で説明されています（RFC 8601のセクション1.2）。spf=pass、dkim=pass、dmarc=passを確認したら、passの表示だけで判断せず、smtp.mailfrom、header.d、header.fromを比べます。ヘッダーの解析にはPalisadeのメールヘッダー解析ツールを使えます。ただし、認証情報のテストや受信トレイへの到達の保証はできません。

DMARCレポートと配信を確認する

許可したGoogleの送信元がFromドメインのDMARC集計データに表示され、運用開始後に想定外の送信元が増えていないか確認します。次に、対象の送信についてGmailへの配信と受信トレイへの到達を比べます。Googleの現在のガイドラインでは、個人のGmailアカウントに送るすべての送信者にSPFかDKIMを、Gmailアカウントに一日5,000通を超えて送る送信者にはSPF、DKIM、DMARCを求めています（Googleのメール送信者のガイドライン）。

一通のテストに合格しても、チームが本番の送信元をすべて把握できない場合は、PalisadeのDMARC Agentがドメイン全体のDMARC集計データを整理できます。Smart DNS Deploymentが書き込めるのは、人が承認したDNSの変更だけです。Googleの認証情報の設定、まだ送信していないアプリのテスト、受信トレイへの到達の保証はしません。ヘッダーのテストで、残る課題が継続的な可視化だと分かったら、Palisadeを始めましょう。

よくあるトラブル

認証が拒否される

アカウントの完全なアドレス、許可された認証情報の種類、2段階認証プロセスとアプリパスワードの利用条件、Workspaceのポリシーを確認します。ロック中やポリシーで禁止された認証情報で何度も再試行しないでください。

TLS接続に失敗する

ポート587にはSTARTTLS、ポート465には暗黙的SSLを組み合わせます。必要な通信の保護に対応できないクライアントは、証明書やTLSの検証を無効にするのではなく、更新してください。

送信できるがDMARCに失敗する

表示されるFromドメインをheader.dやsmtp.mailfromと比べます。署名、エイリアスの許可、送信者の設定を実際の送信元で修正します。DNS側の対策はGmailのメール認証ガイドで説明しています。

サーバーは受理するが配信が悪化する

送信レートと一日の上限、苦情、送信内容の変更、Google Postmasterのデータを確認します。サーバーが受理しても、受信トレイへの到達が約束されるわけではありません。送信元を特定しないまま、ポートを替えたり内容をむやみに書き換えたりしないでください。

この手順が当てはまらない場合

この手順で扱うのは、認証付きのGmail SMTPサーバーです。リレーと制限付きの方法も比較していますが、テナントのリレーポリシーの完全な導入、認証なしでMXに直接送る一般的な配信、大量送信のマーケティング基盤、Gmailの受信設定、個人アカウントの復旧は扱いません。認証付きの方法のポリシーを満たせない機器には、Gmailアカウントのセキュリティを弱めるのではなく、管理者が制御するリレーか、組織内の受信者に限る制限付きの経路が必要になる場合があります。

根拠

出典と参考資料

• Googleの機器・アプリ向けSMTPオプション
• Google WorkspaceのSPF設定
• Google WorkspaceのDKIM設定
• Googleのメール送信者のガイドライン
• RFC 9989（DMARC）
• RFC 8601（Authentication-Results）