はじめに
DIGGLEエンジニアのaki0344です。
2024/02/01より、Gmailのガイドラインが変更されました。
support.google.com
Gmailに対して1日5000件以上のメールを送信しているドメインはSPF、DKIM、DMARCによる認証を設定していない場合なりすましや迷惑メールと判断されて送信先に届かない可能性があります。
今回、DIGGLEではSalesチームやプロダクトから送信したメールが迷惑メールと判定されないよう、全社のメールでDMARCに対応しました。
本記事ではその際に行った作業についてまとめてみました。
実際の手順のみ知りたい方はDMARC対応の流れからお読みください。
DMARC対応作業を始めるまで
それは一通の問い合わせから始まった
ある日、Salesチームから1通の問い合わせが届きました。
翌日、開発チームのデイリースクラムで問い合わせについて共有され、対応が必要だねという話になりました。
メールのセキュリティについて全く知識が無かった私は静観していたのですが、生憎他メンバーは直近の作業に追われており、急ぎの作業のなかった私に押し付けられましたが対応することにしました。
何のことか良くわからないけど、何を設定すれば良いかは明示されてるしそんなに大変な作業でもないでしょと思っていました。実際に作業を始めるまでは…。
そもそもDMARCって何だ？
さて、DMARCに対応するためには当然DMARCが何者なのかを知らなければいけません。
まずはDMARCで検索をかけてみたのですが、SPF/DKIMというこれまた聞いたことのない言葉が出てきました。
いきなり調べることが増えてしまった…。
様々なサイトを眺めていましたが、『構造計画研究所』さんのブログ記事がとても分かりやすかったです。
それぞれを一言で表すと以下のようになります。
- SPF : 正規のサーバから送信されていることを証明する
- DKIM : ドメイン管理者がメールを送信していることを証明する
- DMARC : SPF/DKIMで認証失敗した場合にメールをどう扱うかを決める
DMARCに対応するためには、その前段階としてSPF/DKIMに対応しなければいけません。
※DMARCはSPF/DKIMいずれかのみと組み合わせての対応も可能ですが、今回DIGGLEでは全て対応することを前提に作業を進めました。
対応時の注意点
DMARCに対応するにあたり、いくつか注意点があります。
メール送信方法によって対応内容が異なる
メール送信を行うサービスを利用している場合、それぞれに対応が必要となります。
一部設定が漏れていた場合、そのサービスから送信されたメールが送付先でなりすましと判定される可能性があります。
SPF、DMARCの対応は複数サービスで同じ場所に修正を加える必要がある
詳細は後述しますが、DNSに設定するレコードはSPF、DMARCでそれぞれ1行です。
複数サービスでSPF、DMARCに対応する場合、各サービスの案内に記載されている内容をそのまま転記するとそれぞれ複数行追加してしまう可能性があります。
作業完了時、SPF、およびDMARC用のDNSのレコードはそれぞれ1行ずつと覚えてください。
なお、DKIMは各サービスごとにレコードが必要となります。
SPF/DKIM未対応の状態でDMARCに対応してはいけない
先述の通り、DMARCはSPF/DKIMの認証結果を基に次のアクションを決定する機能となります。
SPF/DKIMに未対応の状態でDMARCのみ追加した場合、送信したメールがすべてなりすましと判定される可能性があります。
DMARCは対応が必要な全てのサービスでSPF/DKIMに対応し、最後に設定を行いましょう。
定義を間違えると他のサービスにも影響を及ぼす危険性がある
複数サービスで共通する箇所に修正を入れるため、1か所失敗すると全てのサービスが正常に動作しなくなる可能性があります。
かならずクロスチェックをしましょう。
DMARC対応の流れ
ここからは実際にDMARCに対応する際に行ったことを書いていきます。
自社で保有しているドメイン一覧を特定する
複数のドメインを保有している場合、各ドメインでメールを送信している可能性があります。
今回の対応はドメイン毎に必要となるため、対応漏れが無いよう自社ドメインを全て洗い出します。
メールアドレスに使用されているドメインを特定する
メールの送信元(From)となり得る全てのドメインで対応要否の判定が必要となります。
社内の有識者に確認し、どのドメインがメール送信に使用されているかを絞り込みます。
DIGGLEでは以下の方法で絞り込みを行いました。
- バックオフィスに確認
各社員に割り当てられたメールアドレスを管理している部署に、他のドメインを利用しているかを確認します。 - プロダクト管理者に確認
プロダクトの機能でユーザーへメール送信する際に利用しているドメインを確認します。
ドメイン毎にDMARC対応が必要か判定する
Googleのガイドラインでは、1日5000件以上のメールを送信する場合にDMARCへの対応が必要となっています。
毎日大量のメールを送信しないことが明らかな場合はDMARCの対応を行わなくてもガイドラインには抵触しません。
今回のDIGGLEの対応ではドメイン毎に送信しているメールの件数について確認はしていませんが、使用用途から現在、あるいは今後1日5000件以上のメールを送信すると判断したドメインに対して対応を行うことにしました。
メール送信を行っているサービスを洗い出す
SPF/DKIMはメールサーバ毎に設定を行う必要があります。
そのため、自社内で先ほど絞り込んだドメインを送信元としてメール送信している外部サービスを確認します。
バックオフィスなど各部署の利用しているサービスを管理している部署に、自社ドメインでメール送信を行っているサービスについて問い合わせましょう。
DIGGLEでは念のためslackの全社員が登録しているチャンネルでも確認を行いました。
※文中にある各個人からのメール送信はGmailのSMTPサーバを利用しており、過去にSPF、DKIM対応済みだったため今回は対応不要としています。
各サービスでSPF、DKIMの対応方法を確認する
SPF、DKIMの対応方法はサービスによって異なるため、各サービスのマニュアルや設定画面から対応方法を特定します。
DIGGLEで利用していたサービスでは大別して4パターンあることがわかりました。
SMTPサーバを指定している
Metabaseのように自分でサーバを用意するシステムの場合、メールはSMTPサーバを指定するのが一般的です。
この場合はSMTPサーバを管理しているサービスで次に記載する内容を確認します。
SPF/DKIMを有効化するレコードをDNSに追加する
最も一般的な対応方法です。
各サービス毎に、SPF、およびDKIMを設定するための値が記載されているページを探します。
SPFは一般に公開されていることが多く、マニュアル等やFAQで記載されている個所を探します。
DKIMで設定する値はドメイン毎に異なるため、管理者画面からのみ確認が可能となっています。
ドメインや配信時のメールアドレスを設定するページで確認できることが多いです。
サービス側のDNSサーバを参照するためのレコードをDNSに追加する
SendGridなどの一部サービスでは、サービスが用意しているDNSサーバがSPF/DKIMの認証を行う機能があります。
その場合、自社で用意しているDNSではサービス側のDNSサーバを参照するためのレコードを定義する必要があるため、その値が記載されているページを探します。
レコードの値はドメイン毎に異なるため、管理者画面からのみ確認が可能となっています。
ドメインや配信時のメールアドレスを設定するページで確認できることが多いです。
対応方法が何も書かれていない場合
DIGGLEで利用しているサービスの中には、FAQ等のドキュメントや管理者用設定画面のどこを探してもSPF、DKIM、DMARCに関する記載が一切存在しないサービスがありました。
こちらは実際にメールを配信する手順で社員へメールを送信し、ヘッダ情報でSPF、DKIM、DMARCに対応しているかを確認し、未対応の場合は問い合わせる方向で作業を進めました。
※ヘッダ情報の確認方法は後述しています。
結果的には全て対応済みだったため事なきを得ました。
DNSで各ドメインにSPF、DKIM、DMARCのレコードを追加する
各サービスで追加する内容が明確になったので、ドメイン毎にレコードを追加していきます。
ここで2点注意事項があります。
※サブドメイン毎に設定する場合はこの限りではありません。
SPFのレコードは1ドメインに1つ
複数のサービスを利用している場合、『SPF/DKIMを有効化するレコードをDNSに追加する』でサービス毎のSPFを確認していると思いますが、DNSには1つのレコードにまとめて登録する必要があります。
複数の場合はincludeをサービス数分定義し、各サービスの値を設定します。- 誤った設定例
v=spf1 include:spf.corp01.value ~all v=spf1 include:spf.corp02.value ~all v=spf1 include:spf.corp03.value ~all - 正しい設定例
v=spf1 include:spf.corp01.value include:spf.corp02.value include:spf.corp03.value ~all
- 誤った設定例
DMARCのレコードは1ドメインに1つ
DMARCはサービス数に関わらず共通の値を使用します。
SPF、DKIMのレコードを追加する
ドメインを管理しているDNSで、ドメイン毎にSPF、DKIMを有効にするためのレコードを追加します。
SPFは1つにまとめた値を、DKIMはサービス毎に指定された値の数だけレコードを追加します。
値に誤りがあると他サービスにも影響する可能性があるため、クロスチェックを行う等、確認は念入りに行ってください。
レコード追加後、各サービスからメールを送信し、ヘッダの内容からSPF、DKIMが有効になっているか確認します。
※有効になるには一定時間を要する場合があります。
Gmailの場合は『メッセージのソースを表示』で確認することが可能です。
DMARCのレコードを追加する
ドメインを管理しているDNSで、ドメイン毎にDMARCを有効にするためのレコードを追加します。
パラメータは必要に応じた内容を設定します。
www.naritai.jp
認証失敗時の動作pについてはいきなりrejectなどの厳しい制限を指定すると今までメールを受け取れていた相手に届かなくなる可能性があります。
一旦noneを設定し、レポートで状況を確認しながら段階的に制限を強めていくのがおすすめです。
以下は設定値の一例です。
v=DMARC1; p=none; rua=mailto:report-rua@my.corp.com; ruf=mailto:report-ruf@my.corp.com;
rua、 rufを設定しておくとメールでレポートが送られてくるため、後から到達率等の振り返りが可能となります。
レコード追加後、各サービスからメールを送信し、ヘッダの内容からDMARCが有効になっているか確認します。
※有効になるには一定時間を要する場合があります。
SPF、DKIMと同様に、Gmailの場合は『メッセージのソースを表示』で確認することが可能です。
サービス導入時の対応手順を整備する
以上の手順で現在利用しているサービスについてはSPF、DKIM、DMARCが有効になりました。
一方、今後各部署で利用するサービスを追加した場合は、今回と同様の手順でSPF、DKIMの追加が必要な可能性があります。
そのため、社内でまとめているサービス導入時の手続き等の文書にDNS管理者へ設定の依頼を行う手順を追加しておくことをお勧めします。
DIGGLEでは以下の条件を満たすサービスの場合にはDNS管理者へ通知するよう手順をまとめました。
- 自社ドメインを利用してメールを送信する
- 初期セットアップで送信メールサーバを指定しない
これで今後の新規サービス導入がスムーズに進むことが期待できます。
おわりに
今回はDIGGLEから送信したメールがGmailでなりすましや迷惑メールと判定されないよう、SPF、DKIM、DMARCを有効化するために行った作業をまとめてみました。
本記事では効率的で漏れのない手順をまとめていますが、実際には私の知識不足により各手順を行ったり来たりしながら無駄の多い作業となってしまいました。
幸い、DIGGLEでは最近立ち上がったSREチームにセキュリティに強い方がいたため、その方に叱られながらアドバイスをいただきながら無事作業を完了させることが出来ました。
本記事が、メールのセキュリティ強化に対応する際の一助となれば幸いです。
We're hiring!
DIGGLE では共にプロダクトを開発してくれるエンジニアを大募集中です。
少しでも興味があれば、ぜひ下記採用サイトからエントリーください。
カジュアル面談も実施しているので、気軽なお気持ちでご応募いただければと思います！
