Gmailのメール送信者ガイドライン

どの設定方法を使うべきか

実際にメッセージを送るシステムの認証手順を使います。この流れでは、Gmailは受信側のサービスです。マーケティングプラットフォームのDKIMセレクタ、トランザクションプロバイダーのReturn-Pathのターゲット、送信IPのPTRレコードをGmailが生成するわけではありません。

送信プラットフォームに自動のドメイン認証機能がある場合は、選んだドメインについてアカウントで生成されたDNSの値を使います。DNSをInfrastructure as Codeや変更管理プロセスで管理している場合は、選んだプラットフォームのアカウントから正確な値を書き出し、その手順で申請します。別の送信元を追加するときに、動作中のSPFレコードを置き換えないでください。SPFの有効なレコードはドメインごとに1つなので、プラットフォームが求めるメカニズムは、そのプラットフォームのドキュメントに沿って既存のレコードに統合する必要があります。

専用IPは、送信プラットフォームと運用モデルが必要とする場合にだけ使います。専用IPを使っても、Gmailの認証、TLS、アライメント、登録解除、PTR、迷惑メール率の要件はなくなりません。

Gmailの一括送信向けにSPFとDKIMを設定する方法

1. 本番の送信元と表示上のFromドメインを特定する

ドメインを使ってメールを送るサービスをすべて洗い出し、マーケティング、トランザクション、メールボックスから送るトラフィックを分けます。サービスごとに、表示上のFromドメイン、エンベロープ送信者またはReturn-Pathドメイン、DKIM署名ドメイン、セレクタ、送信IPまたはリレー、テスト用メールボックスを記録します。

Googleの一括送信者のルールでは、直接送信するメールのFromドメインを、SPFドメインかDKIMドメインのどちらかとアライメントさせる必要があります。認証されたドメインが、選んだアライメントモードで表示上のFromドメインと一致しなければ、SPFやDKIMに合格してもDMARCのアライメントは成立しません。

2. 送信プラットフォームのドメイン認証設定を開く

選んだ送信元のドメイン認証、送信者ドメイン、またはDKIMの設定を開きます。他のプラットフォームのアカウントで生成されたDNSレコードを公開するための、Gmail共通の設定ページはGoogleのドキュメントにありません。変更する前に、送信プラットフォームの最新の公式ドキュメントか、ログイン済みのアカウントで手順を確認してください。

送信ドメインを正確に選びます。組織のドメイン、サブドメイン、独自のReturn-Path、表示上のFromドメインが同じDNS設定を共有していると決めつけないでください。

3. アカウント固有のSPFとDKIMのレコードを公開する

SPFのメカニズム、DKIMセレクタ、DKIMの値またはCNAMEのターゲットを、送信プラットフォームのアカウントからコピーします。以下の例はレコードの構造を示すだけです。

SPFレコードタイプ： TXT

SPFのホスト： yourdomain.com

SPFの値（例示のみ）：

v=spf1 include:spf.example.net -all

DKIMレコードタイプ： TXTまたはCNAME（送信プラットフォームの生成どおり）

DKIMのホスト（例示のみ）：

selector1._domainkey.yourdomain.com

DKIMの値（例示のみ）：

v=DKIM1; k=rsa; p=example-public-key

これらの例を公開しないでください。選んだアカウントとドメイン用に生成された、完全なSPFとDKIMの値をコピーします。アカウントで生成されるセレクタ、公開鍵、CNAMEのターゲットは、プロバイダーやテナントによって異なることがあります。

DNSプロバイダーがホスト名をどう扱うかを確認します。yourdomain.comを自動で付け足す画面もあります。そうした画面に完全なオーナー名を入力すると、selector1._domainkey.yourdomain.com.yourdomain.comができてしまいます。

保存する前に、既存のレコードを確認します。ルートドメインに2つ目のSPFレコードを追加しないでください。DKIMでは、プロバイダーのローテーション手順を使わずに有効なセレクタを上書きしないでください。CNAMEは、同じDNSオーナーで他のレコードデータと共存できません。

4. DMARCレコードを公開し、アライメント設計を確認する

Googleは一括送信者に、送信ドメインでDMARCを設定するよう求めています。Googleは、DMARCの適用ポリシーをnoneにできると明記しているため、Gmailの一括送信者要件では、すぐにp=quarantineやp=rejectにする必要はありません。

DMARCレコードタイプ： TXT

DMARCのホスト： _dmarc.yourdomain.com

DMARCの値（例示のみ）：

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

この例をそのまま公開しないでください。自組織が管理するレポート用メールボックスを使い、集計レポートを受信できることを確認してください。

実際のメッセージで、表示上のFromドメインとSPFかDKIMのアライメントが成立することを確認します。Googleのメール送信者のガイドラインは、直接送信する一括メールにこのアライメントを求めています。

5. 送信プラットフォームで検証し、実際に送信する

送信プラットフォームに戻り、選んだドメインについて公開したレコードが認識されていることを確認します。次に、本番と同じ経路で、生のヘッダーを確認できるメールボックスへ新しいメッセージを送ります。

プラットフォームの緑色の表示は有用な証拠ですが、想定どおりのReturn-Pathで送られたこと、想定どおりのドメインで署名されたこと、アライメントした認証でGmailに受け付けられたことの証明にはなりません。

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

DMARCは、SPFまたはDKIMが合格し、表示上のFromドメインとアライメントしているかを評価します。一括送信者にはSPFとDKIMの両方の設定が必要で、直接送信するメールでは、FromドメインをSPFドメインかDKIMドメインのどちらかとアライメントさせる必要があります。

ポリシーを変える前に、PalisadeのDMARCチェックで公開中のDMARCレコードを確認しましょう。公開DNSのチェックでわかるのは、現在解決されるレコードです。本番の送信経路、Gmailの非公開の迷惑メール評価、今後の配信、特定のメッセージがアライメントしたかどうかは証明できません。

Palisadeは、一度きりのレコードチェックの先へ進みたいチーム向けのエージェント型DMARCソフトウェアです。DMARC集計レポートのデータを分析し、送信元と認証やアライメントの問題を特定して、優先度付きの修正チケットを作成します。証拠を確認し、DNSやポリシーの変更を適用するのは人です。

設定の検証方法

公開DNSを確認する

権威DNSプロバイダーと、少なくとも1つの公開リゾルバーに、SPF、DKIM、DMARCのオーナーを問い合わせます。最終的な完全修飾オーナー名と値全体を確認します。DKIMチェックは入力したセレクタを照会します。ドメインにまだDMARCレコードがない場合は、DMARC生成ツールで公開用のレコードを作れます。

dig +short TXT yourdomain.com
dig +short TXT selector1._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

各送信IPで、正引きと逆引きのDNSが一致していることも確認します。GoogleはPTRレコードを送信者の要件としており、SMTPエラーのドキュメントでは、PTRレコードがない、または一致しない場合を550 5.7.25で拒否される条件としています。

送信プラットフォームの状態を確認

プラットフォームが選んだドメインを認識し、認証ステータスが最新であることを確認します。選んだアカウント、ドメイン、セレクタ、検証の時刻を記録します。

これで確認できるのはベンダーの層だけです。すべてのキャンペーン、リレー、アプリケーションが承認済みの設定を使っていることまでは確認できません。

届いたメッセージを調べる

本番経路から新しく届いたメッセージを調べます。DKIM-Signatureのドメインとセレクタを確認し、受信側が付加したAuthentication-Resultsフィールドを調べます。RFC 8601はこのフィールドを定義し、受信者がその信頼境界を評価する必要があると説明しています。

メッセージ経路のテストを合格とするのは、信頼できる結果が想定どおりの認証結果を示し、SPFかDKIMのどちらかが表示上のFromドメインとアライメントしている場合だけです。一部を伏せたヘッダーの写しを変更記録と一緒に保管します。

DMARCレポートの確認

集計レポートがたまったら、送信元ごとにSPFとDKIMのアライメント結果を確認します。テストメッセージが成功しても、ドメインを使うすべてのシステムを洗い出したことにはなりません。

トラブル対応

Gmailが550 5.7.26を返す

Googleの記載は次のとおりです。

This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.

メッセージのヘッダーで実際のSPFとDKIMの結果を確認し、送信プラットフォームで設定したドメインと、公開で解決されるDNSレコードを比べます。GoogleのGmailのSMTPエラーとコードをご覧ください。

Gmailが550 5.7.27または550 5.7.30を返す

Googleは、一括メールでSPFが失敗した場合を550 5.7.27、DKIMが失敗した場合を550 5.7.30としています。本番の経路が、設定したReturn-PathとDKIMセレクタを使っているか確認します。よくある原因は、あるプラットフォームでテストしたのに、実際のキャンペーンが別のリレーやサブドメインを使っていることです。

Gmailが550 5.7.29を返す

Googleは、一括メッセージがTLSで送信されなかった場合にこのエラーを返すとしています。SMTPやリレーのログで確立された接続を確認し、実際の配信経路でTLSを必須にします。DNSのチェックツールでは、SMTPの送信ログは確認できません。

SPFは合格するがDMARCは失敗する

表示上のFromドメインと、SPFで認証されたエンベロープのドメインを比べます。アライメントしていなければ、DMARCはそのSPF合格を使いません。DKIMのアライメントも確認し、メッセージを送ったプラットフォームで送信者ドメインやReturn-Pathの設定を修正します。

迷惑メール率が0.3%に近づく

Googleは、ユーザーが報告した迷惑メール率を0.1%未満に保つよう推奨し、0.3%未満を維持することを求めています。送信者ガイドラインのFAQによると、迷惑メール率は日ごとに計算され、0.3%を超えた送信者は、七日間連続で0.3%未満になるまで緩和措置の対象外です。送信量を増やす前に、同意、リストの質、送信頻度、登録解除の処理を見直してください。

Gmail一括送信の設定を支えるDMARCレコードをチェック

一括送信者向けの設定に頼る前に、Fromドメインそのものに公開されているDMARCレコードを確認します。そのレコードを新しく届いたメッセージで確認したSPFとDKIMのドメインと比べ、集計レポートの証拠から、まだアライメントに失敗している可能性のある他の本番送信元を見つけます。

DMARCレコードをチェック

DMARCレコードのチェックでは、受信側の非公開の迷惑メール判定の証明、SMTPのTLSの確認、個々の送信者設定の修正、今後のGmailでの振り分けの保証はできません。複数の送信元やドメインにわたる継続的な証拠が必要なら、Palisadeを始めましょう。カード登録でトライアルを開始します。