2023年12月14日 / 最終更新日時 : 2024年1月31日 officeの杜 Google

Google WorkspaceでSPF, DKIM, DMARCを設定する

2024年2月、Google Workspaceでとある設定をしていない場合、新しいメールセキュリティポリシーによって、Google WorkspaceからGmailに対してのメール送信において、１日5000通以上の送信を行うテナントに対して、制限が加わることになりました。

当初はGoogle Workspaceのアカウントに対しての送信に対してもという話であったのですが、今回は除外になっています。今回この設定についてDNSがさくらインターネットにドメインがある場合に対してちょっとまとめてみました。

2023年アップデート Google Workspaceの新機能

今回設定する必要があるもの

Google WorkspaceのAdmin ConsoleおよびさくらインターネットのDNS設定画面の２つに対して作業を行いますが、順番があるため、１つずつ確かに行うことが重要なのと、これらの設定はデメリットなどもあるため、慎重に行う必要があります。

現時点では、Gmailアカウントに対してテナントが1日5000件以上のメールを送るか？送らないか？で対応が変わります。このあたりの要件に関してはこちらのページが参考になります。

※これからは、Google Workspaceを新規導入する場合でも必須の作業となるでしょう。

世界に於ける導入状況

今回話題になってるDKIM, DMARCの導入状況。NRI Secure Insight 2023によると、

  • 日本は実施済みの企業がわずか13%
  • 世界では80〜89%がすでに実施済みである

さらに問題なのは、未対応回答を行ってる企業が日本の場合47%も存在し、さらに「わからない」という回答を27%も平然と行ってる現状です。ITリテラシーが低い以前の問題として、現代ビジネス社会に於いてITに対して非常にお粗末な状況にあることが伺えます。

このレポートはDMARCだけに限らず、ITに疎い世代や人材が重要なポストに位置していたり、経営者自体が重要視していない姿勢が如実に数字に出てるのではないかと思われます。

問題になったケース

概要

2024年1月10日、まだ2月よりも前の段階なわけですが、DKIMを設定していないケースに於いてGmail宛のメールが届かない問題が発生しているようです。それが神奈川県の高校入試出願システムに於いて申請後のメールで、受験者がgmail.comを使ってる場合届かないという問題。

内容は、mail.shutsugankanagawa.jpがこのドメインに対してDKIMを設定をしていないにも関わらず、DMARCでnoneではない値を指定してる為、スパムとして除外されたというもの。quarantineとして指定されてるようで、検疫対象に送られたようです。実際に、DMARC設定確認のページにて、このURLを指定してチェックをかけると

  • SPF設定はオッケー
  • DKIMは未設定が検出
  • DMARCはquarantineが設定

となっており、受信者に届かず、Gmail側で検疫対象として隔離されたのが原因のようです（受信トレイじゃなく迷惑メールフォルダにいるんじゃなかろうか？）。2024年2月からじゃないのか？ということですが、そもそもこの話自体が2022年11月より出ており、すでにもう適用されてしまってるのではないか？とも思ったのですが上記のDMARC設定がおそらく原因ではないかと。公式ページの該当のガイドラインは2024年2月からとなっていますが、WebArchiveの2023年2月頃の内容を見るとたしかにそれが確認出来ます。

考察

今回のケースでは、対象のサイト=>AWS SESでメール送信=>Gmail側で弾かれたという流れのようです。Google Workspaceは介在していませんが、この問題はもう一つの注意点を知らせてくれています。

Google Workspace=>Gmailについては2024年2月からの対策となりますが、それ以外のシステム=>GmailではすでにSPF, DKIM, DMARCがきちんと設定されていないと現時点ですでにもう届かない（Gmail側で対策済みであるため）ということです。よって、今後メール送信を伴うシステムを構築する場合に於いて、Gmail宛に送るならば必ずこの設定を考慮しなければなりません。

DMARCの指定がなければ、またはp=noneで設定されていたら問題なかったのかもしれません。もちろん他の理由で届かなくなったことも考えられますが、2月まであと僅かという時点ですので通常企業でも装備を進めたほうが良いかもしれません。Google Workspaceも近いうちにGmail基準できちんと設定していない外部からのメールを弾くようになるかもしれませんし、YahooやMicrosoft365も追随すると思われます。

また、spfの設定がGoogle側のメールサーバではなくAWS側を向いており、MXレコードについてもGoogle側じゃなくAWS側のIPアドレス(何故かIPアドレスの最後にドットが付いてる。IPは指定できず、FQDNの後にドットを付けるのが正しい記述)と１個だけFQDNで指定という状態であった為、AWS側のシステムから送信を試みて失敗したのではないかという意見があります。（４つ目のFQDN指定のサーバから送信され、GWS側で検疫されたコースなのではないかと）

spfやMXレコードの確認は以下のコマンドで確認が可能です。

各種設定を行う

SPFレコードをセットする

こちらはDNSに対して追記する必要があります。こちらは作業は簡単です。

  1. DNSのゾーン編集画面を開く
  2. さくらの場合すでにsakura.ne.jpのspfがTXTレコードで入ってるのでこちらに追加する形で設定する

    @, TXT, spfの形で記述し、さくらの場合は、内容をダブルコーテーションで括る必要があります。半角スペースでつなぐので要注意。
  3. 保存する

DNSとして反映するのにしばらく時間が掛かります。TTLで3600を指定しておくと良いでしょう。最大で48時間反映に時間が掛かります。正しくセットしていない場合や指定のドメインからの送信ではない場合、SPFのチェックが掛かり以下のような内容でブロックされます。また、The original message was receivedの送信元がlocalhostとなってる場合、送信元ドメインとSPFのドメイン不一致となるため、ブロックされます（通常は送信者のメアドが表示されるはず）。

きちんとSPFがセットされているかどうかは以下のサイトでチェック可能です。

  1. Network Toolsにアクセスする
  2. テキストボックスに自身のドメインを入力して、SPF Record Lookupをクリック
  3. 緑色のボックスにDNSに指定してあるSPFレコードが表示され、検査内容が以下に表示される

図：正しくセットされている様子

DKIMをセットする

次にDKIMをセットする必要があります。こちらはGoogle Workspaceの管理コンソールとDNS側の２箇所で作業を行いますが、さくらインターネットの場合ちょっとテクニックが必要です。

  1. Google WorkspaceのAdmin Consoleを開く
  2. 左サイドバーからアプリ=>Google Workspace => Gmailを開く
  3. メールの認証を開く
  4. 選択したドメインが正しいか確認したら、新しいレコードを生成をクリックする
  5. DKIMの鍵のビット長は2048を指定します。
  6. すると、ホスト名とTXTレコードとして登録する鍵の文字列が出てくるので控えておく。
  7. 次に、さくらインターネットのDNS設定側のゾーン編集画面を開く
  8. 新規のレコードでホスト名はgoogle._domainkeyを指定する（このgoogleというところがDKIMセレクタになります）
  9. TXTレコードを指定して、鍵のデータを書き込むのですが、さくらインターネットは1行最大255文字までなので溢れてしまいます。
  10. 鍵データのちょうど半分くらいの場所で改行を入れて、それぞれをダブルコーテーションで括ります。これで文字数制限を超えられます。
  11. 保存する
  12. こちらも反映するのに48時間程度がかかるので、それまで待機する
  13. 経過したら、Admin Consoleの3.の画面に於いて、「認証を開始」をクリックする。エラーが表示されなければオッケーです。その後ボタンが認証を停止に変わります。

これで、DKIM認証設定は完了です。

※AWSのRoute53のDNSについても同様の手法で登録が出来るようです。

※もう一つDNSとして名づけてねっとを利用してるケースがあったのですが、ここも1行当たり255文字までなのですが、10.のテクニックを利用すると勝手に行をソートしてしまいます（降順でソートしちゃうようで）。すると、2行に分けた場合に2つのブロックが前後してしまい、DKIMの値としておかしなことになりました（nslookupでも２つのTXTレコードとして認識されてしまってる）

※その後、名づけてねっとでは「改行でDKIMの2048bitのキー登録が出来ない」ことが判明。1024bitだけ登録が可能（255文字以上は改行しても入れて１つに出来ない・・・今時こんなDNSサーバあるとは・・・セキュリティ的には推奨出来ません。

※48時間経過後も1024bitでのDKIMを名づけてねっとに配置していますが、認証は通らないです。。。DNS引っ越しが必要かもしれない。

図：DKIM設定画面

Postmaster Toolに登録する

この作業はオプションですが、以下の手順でドメインをPostmaster Toolに登録しておくことをおすすめします。自社ドメインから外部向けに対してスパム判定されるようなメールを送ってるかどうかのチェックするために利用します。

  1. Postmaster Toolを開く
  2. 自社ドメインを登録する
  3. しばらく運用後に一覧からクリックして、迷惑メール率を調べる

図：迷惑メールが飛んでないか？

DMARCをセットする

SPFおよびDKIMの設定が完了してから48時間間を空ける必要があるので、すぐに設定に取りかかれません。また、DMARCの認証に関するレポートがバンバン飛んでくるとのことなので、この待機時間中にレポートを受け取る専用アカウントを用意しておくと良いでしょう。また、アカウントではなく複数名で受け取るようにグループアドレスでも可となってるので、準備しておきます。

  1. さくらのDNSゾーン編集画面を開く
  2. 新規レコードを追加し、TXTの名前、 TXT, そして、レポートを受け取るメアドを下に以下のような文字列をダブルコーテーションで括って入力

    TXTの名前は、「_dmarc」や「_dmarc.hogehoge.com」といったドメイン含めた名称で設定します。
  3. 保存する

ちなみに、p=noneの部分ですが、これらの項目はタグと呼ばれ、pの場合、SPFやDKIMでFailとなったメールについて以下の処理を行います。

  • none = メールはそのまま通過。レポートに記録送信される
  • quarantine = メールを迷惑メールフォルダに分類。
  • reject = メールの受信を拒否。バウンスメールが返る

なりすましメール対策のspfと送信者認証のdkimによってFailの判定がなされて、DMARCによって自動処理が行われるというわけです。ただ、ここで問題になるのが、Fromヘッダの書き換え（送信元偽装というか変更）をしていた場合もFailとなり、メールの転送やグループアドレス宛に送信などをした場合も、エラーとなる場合がある点です。これが届かなくなると言われる所以。

フィッシングやなりすましを防ぐためにrejectを指定するのもよいのですが、誤判定ででもそのメールは届かなくなるので見極めが必要です。

他にもpctタグやadkimといったものもありますが、基本は上記のpとruaのみでオッケーです。pは通常はnoneのままで良いでしょう。

設定の確認と注意点

影響の考慮

個人で利用してるGoogle Workspaceのドメインならば自分自身が把握しているハズなのでそれほど大きな影響にはなりませんが、一般企業で社内でGoogle Workspaceを利用している場合、この設定を施した結果影響するかどうか？は事前に調査をしておくと良いでしょう。

特に転送系やSMTPリレーで送ってる場合、他のオンプレシステムがGoogle WorkspaceのSMTPを利用して送信しているようなケースなどなど（AWSなどの独自システム等）。現在はまだ、Gmailへの送信についてだけ求められてるものですが、今後Google Workspace宛や他のメールサービス（YahooやMicrosoft365など）に対しても、この要求が広がっていくと思われるので、現時点で対応しておくことが吉です。

設定内容の確認方法

簡単な確認方法

SPF, DKIM, DMARCそれぞれ設定が完了済みとなったら、適当なgmailアカウントに対してメールを送ります。

  1. gmailアカウント側で対象のメールを開く
  2. メールの右上にある「︙」をクリックし、メッセージのソースを表示を開く
  3. メールヘッダ等の内容が表示されますが、上部にSPF, DKIM, DMARCの項目があり、ここが「FAIL」となっておらず「PASS」となっていればオッケーです。

図：すべてPASSなら設定完了

ツールを使った確認方法

以下の手順で自分のテナントのSPF, DKIM, DMARCの設定状況をまとめて確認することが可能です。個別のWebサービスでも可能になりますが、その場合はDKIMの調査だけはDKIMセレクタの指定が必要になります。

  1. DMARCドメインチェッカーを開く
  2. ドメインを入力して、Check Domainを実行する
  3. 結果が出てくるので、✔になってるものは問題なく設定されてる

DMARCに関しては、今回p=noneとして指定してるので特に何もせずに素通りさせてる関係で自分の場合NGと出ますが、そもそも設定が出来ていない場合にはここがアウトになります。その場合灰色の×印として表示されるので速やかに設定しましょう。p=quarantineの場合はびっくりマークの表記となり、ここがオッケーになるにはp=rejectにする必要がありますが、正直今現在だと色々と支障があるのでp=noneで通しています。

おかしなメールを送信しない

オンプレの社内システムに於いて、やたら古いものが存在し、通知メールなどを発砲してるものがある場合、RFC 5322に準拠していないおかしなメールを飛ばすものがあったりします。これらは届かなくなる可能性があります。

自分の身の回りでもかなり昔のシステムでメール本文が全部Subjectに突っ込まれているといったようなおかしなメールが飛んでいてメールゲートウェイシステムで補足され届かなくなったことがあります。同様のことが起きる可能性があるので、今のうちに修正しておきましょう。

また、当然ですがスパム判定されるようなメールを送らないことも要件に入ってるので、前述のPostmaster Toolでの迷惑メール率が0.3%未満になるように取り組むことが必要です。

メールが届かない可能性がある

これまでを総合すると以下のようなメールが届かなくなる可能性があります。

  • RFC5322に準拠していない古いメールシステムに基づくメール
  • 他のサイトからのメールを自社で受信し、gmailへ転送をすると差出人詐称とみなされ届かなくなる可能性があるので、gmailへのメール転送は辞めたほうが良いです（メール転送ではなく、メールの委任で読めるように許可をする手法があります）
  • 同様にFromアドレスを詐称するようなメールを送らない
  • DMARCがnoneでも、SPFやDKIMでFAILとなる事例に引っかかると届かなくなる
  • 古いメーリングリストで送信者が個人、差出人がMLのアドレスといったような場合、差出人詐称とみなされFAILになる可能性がある
  • gmail以外でもDMARC認証を要求するようになると、対応していない場合メールが届かなくなる。
  • 迷惑メール率0.3%超える場合、相手側のgmailでデフォルトでリジェクトされる
  • また、他社サーバ側でも相手側がこれらの対応をしていない場合、認証できないメールを強制リジェクトする設定にする可能性がある。
  • 今回除外されたGoogle Workspace宛への送信についても将来的にGmail同様にデフォルトでSPF, DKIM, DMARC対応が要求される可能性が高い。
  • localhostからSMTP接続で送ってるようなメールの場合、SPFによってリジェクトされます。
  • 直接的に本テーマと関係はないのですが、今回のポリシーにはメーリングリストやDM、メルマガについては、「Gmail」の受信者がワンクリックで商用メールの配信を解除できる機能を提供すること、および配信停止リクエストを2日以内に処理することが義務付けられる（守らないと迷惑メールとしてカウントされるようになるのではないかと）

GMailで転送する手段まとめ

DMARCレポート

DMARCを設定すると定期的にnoreply-dmarc-support@google.comからレポートとして、XMLファイルをZIPで固めたものが送られてきます。この中身はそのままでは正直読めるようなものではありません。

そこで使うのがDMARC Report Analyzer。XMLをアップしてどれだけのエラーが発生していたのか？といったことが検証することが可能です。

ただ、XML形式ですのでGoogle Apps Scriptで解析してスプレッドシートに書き出し、Looker Studioでビジュアライズするのを自動で行うという仕組みを作ってしまっても良いかもしれません。メールもわかりやすいタイトルで飛んでくるので、自動でスクリプトでドライブに保存し、一連の作業の自動化まで行ってしまうようにすれば、手間も掛からずいつでもDMARCレポートを監視することが可能です。

送信ゲートウェイをセットしてる場合

自身のテナントから外部にメールを送信する際に、送信ゲートウェイを経由して送り出してることがあります。その場合はGoogleのドキュメントにもあるように、以下の点に注意が必要です。

  • Google Workspace側でDKIMをセットした場合、送信ゲートウェイ先でそのまま送り出してるならば、送信ゲートウェイ側で何か設定をする必要はない（逆に干渉してメールの中身を書き換えるようなことがある場合は、送信ゲートウェイ先でもDKIMセットが必要）
  • 前述のケースに於いて送信ゲートウェイ先で書き換えが生じてるのであるならば、Google Workspace側ではDKIMをセットしないで、送信ゲートウェイ先でDKIMをセットしてあげる。
  • また、Google Workspaceおよび送信ゲートウェイ先両方でDKIMをセットするならばARC認証が別途必要かも？（送信ゲートウェイ先で設定する）。この場合、DNSにはGWSと送信ゲートウェイ先の２つのDKIMをセットしてあげる必要がある。

いずれのケースに於いても、必ずDMARCの設定確認チェックを行い、Gmail宛に届くかどうか？をチェックするといった検証をしてあげる必要はあります。

SendGridを利用した大量メール送信の外部送信でGWSと同じドメインを利用して送る場合には、必ずSPFにも対象のIPアドレスを追記し、DKIMをセットしてあげる必要があると思います。GWSを介さないでメールを送ってる外部システムに関しても、今一度整理して確認しておくと良いでしょう。

GASから送信をした場合

2年前のStackOverFlowの投稿によると、当時は

  • SPFチェックは無事に通過する
  • DKIMが失敗する
  • ただし通常Gmail上で送る場合はすべてPASSする
  • よって、GASからの送信はDMARCで検疫されてしまう

ということでした。改めて以下のような簡単なコードで動かして、受信側のソースで確認してみたところ、きちんとすべてPASSしています。よって、GASからのメール送信では、テナントできちんと設定ができていれば送信で問題になることはありません。

セカンダリドメインを追加してる場合

プライマリドメインとは別に、セカンダリドメインを追加してる場合、そのドメインに対してもSPFやDKIM、DMARCの設定が必要です。セカンダリドメインをホストしているDNSに対して作業を行うことになります。また、Google WorkspaceのDKIM生成画面ではドメインを選択できる為、セカンダリドメインを選択して生成DNSに配置後に認証を実行します。

また、セカンダリドメインとは別にプライマリドメインに対するサブドメイン（mail.hogehoge.comのような）形でメールをセットしている場合は、こちらのヘルプにあるようにドメイン単位で行う必要があり、その際にはDKIM生成画面のドメイン選択画面ではサブドメインを選択して同様の作業を行います。DNS側ではgoogle._domainkeyで配置するのではなく、 google._domainkey.mailという形でキーをセットし、認証を行う事になりますので同じドメインで２つのDKIM設定がDNSに配置されることになります。

これはセカンダリドメインを追加し、アカウントではなくエイリアス運用であった場合でも同様です。

Google Workspaceにセカンダリドメインを追加する

関連リンク

カテゴリー
Google、業務テクニック
タグ

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

Google

前の記事

Google Apps ScriptでWorkplace for Metaを弄る【GAS】
2023年12月7日
ガジェット

次の記事

防災にも役に立つ！Powerhouse90を1年間使ってみた
2023年12月17日