この記事は、エンジニアが知っておくべき メール送信・運用ノウハウ、メールの認証技術やセキュリティについて投稿しよう！ by blastengine Advent Calendar 2024 (シリーズ 1) の 20 日目の記事です。
こんにちは、まっぴぃです。
今回は、GSP (Google Spam Protection) 対応で、当時、会社のメールドメインに DMARC を設定する業務を担当したのですが、その過程でいろいろなことを経験したので、それを振り返りってみたいと思います。
企業で利用しているメールドメインに対して、DMARC の quarantine や reject を設定することは、セキュリティ的にも重要で、内容としては一見単純そうに見えるのですが、実際はかなりパワーが必要で大変なことであるという点を実際に経験したので、ちょうど良い機会と思い、自分の備忘録として残そうと思った次第です。
DMARC 設定に至るまでの経緯
今回、対象となったドメイン群は、主に Exchange Online で使用していました。Exchange Online では、Microsoft によって提供される hogehoge.onmicrosoft.com のドメインの他、カスタムドメインとして自社のドメインを使用できるため、通常はカスタムドメインとして登録しているドメインを使用したメールアドレスを従業員に発行している状況です。（たぶん、Exchange Online を使っている会社さんはどこもそうじゃないかな、と思います）
カスタムドメインとして Exchange Online に登録する過程においては、最低限 SPF (Sender Policy Framework) レコードの登録が必要なので、こちらは確実に済ませている状況でした。
ただし、Exchange Online においては、カスタムドメインの DKIM (DomainKeys Identified Mail) の設定は必須でない仕様だったので、設定していたりしていないものがありました。
私は当時、Exchange Online 含む社内の Microsoft 365 を管理・運用するチームのリーダー的な立場にいたため、GSP (Google Spam Protection) が発表された時、社内で
- 不必要な SPF レコードはきちんと棚卸を行い
- DKIM は Exchange Online として登録しないといけないものは登録し
- メールアドレス提供側が関与しない (認めていない) ものはすべて削除し
- DMARC を none ではなく最低でも quarantine で設定する
という方針を打ち立て、上長の承認を得たうえで、対応に臨む準備を整えていました。
...ただ、今この記事を書いている通り、物事はそんなにうまくいかない、ということですね。
実際に GSP 対応を進めるうえで発覚したこと／対応したことのあれこれ
ここからは、実際に私が DMARC を設定するまでに起こったあれこれを紹介しつつ、エンジニアとしてどう向き合ったか／結果どうしたか、についてを紹介していきたいと思います。
正直、対応した後の今の現状が正しいとは思わない部分もあるものの、会社の業務を止めさせないことを最優先した結果の紹介なので、その点ご了承ください。
企業において GSP 対応として DMARC を設定するうえでどのような点が見えない壁として立ちはだかったのか、というのを共有させていただきながら、今後、私と同じような境遇にあってしまう人が 1 人でも少なくなれば良いな、と思い、この記事を残します。
不要となっている SPF レコードの棚卸
私の場合、メールで使用しているドメインの SPF レコードについては、実は GSP 対応を始めた当時、DNS ゾーンにおける設定状況だけは把握していました。というのも、私は中途入社で今の会社に入り、途中から Exchange Online の管理・運用も行うようになったのですが、Exchange Online に対する仕事で最初に行ったのが SPF レコードの棚卸しだった気がします。（違ったらごめんなさい）
（今だからもう時効で言えると思っていますが）自分が担当になった当初は、include 制限の部分が正しく対応されていない状況が維持されていることに誰も気づかず、SPF レコードが正常に機能していない状態に陥っていたため、速攻で修正しました。笑
その甲斐もあり、メールで使用する自社ドメインの SPF レコード設定状況についてはある程度把握はしていたものの、GSP 対応のため 今設定している SPF レコードが果たしてすべて必要なもののみになっているのか について、改めて棚卸しが必要な状況になったため、改めて DNS サーバに設定されている SPF レコードの中身を見てみたのです。
そうしたら出てくる出てくる...会社の歴史が長いところとかですと、過去経緯などでいろいろあるとは思うのですが、私の場合は 20 年弱前に登録されたまま放置されている SPF レコードだったり、なんでこれ登録してるの？っていうレコードがあれこれ出てくることになりました。そして登録経緯について自チームのメンバーは誰も把握していないかったり...泣
SPF レコードの棚卸に際し、一番私の頭を悩ませたのが ip4 で設定している SPF レコードでした。まだ include を使ってドメイン指定しているものについては、ドメインから確認先を想定しやすいと思うのですが、ip4 については「この Global IP は誰のどこの人のもの？」と 1 つずつ調査が必要で、これが会社で保有する IP であるのか、あるいは社外の IP だけど業務システムの関係で登録が必須なのかについて把握するのに、非常に時間を要しました。
ip4 で指定されている SPF レコードの場合、IP アドレスについては、whois などで情報検索をすれば所有者情報を確認できるので、そこで自社の名前が出てくれば問題ないものの、例えば AWS の IP や特定のデータセンター側で保有されている Global IP など、自社でない会社の情報が出てきた場合、その IP が自社で保有できているのかを 1 つずつ確認しなくてはならなかったため、時間をだいぶ取られた記憶があります。
じゃあ include でドメイン指定をしているものについてはどうなんだ、という話なのですが、別にドメインで合っても今思い返すと手間はあんまり変わらなかった気もしています。笑
そのドメインが社内のどこで／何目的で利用するために設定されているのか、今もその設定は必要なのか、について確認が必要だったのですが、10 年以上前に設定されたものだと当時の責任者や知見者も異動や退職などで追跡が困難で、対処に困ったものもありました。
すでに過去の自社サービス/社内システムのドメインだね、となれば、消しても問題出ないよね、で済むと思うのですが、それを確認するまでに意外と時間を取られた気がします。結論、GSP 対応を優先したため、実害がなさそうであればいったん棚卸を見送ったドメインも実際にあります。（過去自社で使っていたという確証を得るまで対応し、現時点での要否は申し送りにした）
今思えば、include 数の是正に着手したタイミングで、SPF レコードの設定値についても時間を取ってきちんと棚卸しをしておくべきだったと思っています。GSP では、SPF と DKIM が正しく設定されたうえでの DMARC 情報が参照されるため、SPF が適切に設定されていることは非常に重要な事項です。
長年同じ担当者が対応しているのであれば問題ないのかもですが、担当者の入れ替わりが発生しうる環境では、しっかり SPF や DKIM などの設定値や設定経緯（依頼元や背景情報など）をしっかり残すことが重要だと感じました。
DKIM の登録依頼が殺到
当時、GSP 対応は世の中的にも大々的にアナウンスされ、キャリアメールなども利用者へ周知を行ったりしたため、「メール技術よくわからんし自分が今どういう仕組みでメール送っているのかわからないけど、DKIM 登録してと言われたから登録してくれないか」という連絡を取ろうとしてくるユーザーが多くなりました。
こちらは社用メールを管理しているからドメインについても管理を行っているというわけですが、私自身が知らない、どこぞの知らない個別システム側で用意されているメールサーバから、勝手に会社メールのドメインでメールを送られるのは、正直管理者としては対応に頭を悩ませました...こちらが管轄しない外部メールサーバから SPF/DKIM 未検証のメールを大量送信されたら、迷惑メール率が上昇してしまうリスクも上がり、結果、一番守るべき社用メール基盤側にも影響を及ぼしてしまう可能性が上がってしまうためです。正直、当時これは心を鬼にしていろんな対応をした記憶があります。
全社員が共通して利用するような全社システム級のものだけ、システムが持つ外部メールサーバを利用することを特例として認め SPF/DKIM の登録を許可し、個別の DM 送信サービスなどで使われるようなシステムに関しては一律でドメインの利用をお断り（後述の代替策を案内）していた気がします。
じゃあ、個別のシステムたちは困るしかないじゃないか、という話ですが、回避のために
- サブドメイン/独自ドメインの発行
- 社用メールにエイリアスとしてサブドメイン/独自ドメインのメールアドレス紐づけ
この 2 点を対応するようにしました。
個別システムなら、個別システム用のドメイン取って SPF/DKIM/DMARC を個別に設定した上で使ってね、とした感じですね。
サブドメインの場合はメールヘッダー検証の手前、親ドメイン側に影響を及ぼす部分もあるものの、SPF/DKIM をあれこれ親ドメインのゾーンに設定してカオスな管理になることを避けるために、時間がない中で取れる最善の方法としてこの形を選びました。
GSP 対応のためにメールの仕様を一般ユーザーに案内するのは非常に高度なスキルが必要
エンジニアに対して「管理者が認知/許可しない外部のメールサーバからの社内ドメインを使用したメール送信は認めません」ということを伝えるのは、(仮にメール技術に対してそこまでの深い理解がなかったとしても) ある程度、言われていることへの理解はできるんじゃないかな、と思います。
例えば、Exchange Online であれば Microsoft、Gmail であれば Google がサービス元である訳ですから、彼らのサービスを使うこと即ち、Microsoft や Google が管理しているメールサーバを使ってメールを送受信している、ということになります。
システムによっては、リレー的な感じで Microsoft や Google のメールサーバを経由してメールを送信する方法もありますが、基本的にそういった設定をしないものについては外部の独自のメールサーバを使用しているという判断ができます。
ただ、そういった外部システム (SaaS) を単に業務の 1 ツールとして契約して利用している、主に非エンジニア職の方に説明し、自分の契約して利用しているシステムが対象であるかどうかを認識してもらうことは非常に大変でした。
非エンジニア職のユーザーからすれば、自分のシステムがどこのメールサーバから送っているかなんて正直興味もないし、送信出来ていればいいじゃん、というような思いもあると思います。でもそれが蔓延すると GSP の影響を受け、全社的な影響を出してしまいかねないリスクがある...ということで、自分が把握できる領域だけでなく、さまざまなルートを通じて、相談だったり変更のご説明・お願いをすることになったのですが、エンジニアではない方にも説明する資料を作る際、IT 用語をできるだけかみ砕いたり、不必要に使用しなかったり、問題ある/なしのパターン例を説明などに奔走しました。
実際に説明をする身になって感じたのは、やはり説明するのにも様々で高度なスキルを要するんだな、という部分でしたね。
DMARC を quarantine にしたら各所から問い合わせが殺到
というわけで、2024/02/01 をマイルストンに DMARC を設定し、その後時間がたったタイミングで DMARC を none から quarantine に引き上げることとしました。
社内での広報対応や、会社として許可/承諾していないメールサーバからのメール送信は一律影響を受けます、という形で草の根的な周知活動もしてはいたものの、やはり設定直後から問い合わせがぽつぽつ......ドドド、と発生する羽目になりました。
受信側のメールサーバに届かない／届いたけどスパムフラグが付けられてしまっている／業務影響があるから直ちに切り戻せ etc. と、様々な声が自分のところに届き、秒で設定値を切り戻すことになってしまいました。泣
どれだけ説明や周知をしても一定数はそういった問い合わせが発生することは予想していたのですが、思った以上の反応だったり、「業務影響」というパワーワードにあらがうには大変なパワーがいることだと実感しました。
GSP 対応からわかった社内メールドメインの在り方についての所管
結論、社内メールは社内メールとして利用することを情シスとして厳しく制限するのが大事かな、と感じました。企業における社内メールのアドレスは、あくまで従業員が社内/社外に対して行う個人的な連絡だったり、全社規模の社内システムなどにおいて通知や問い合わせ目的で利用するための送信元アドレスとして利用するだけにとどめるのがベターだと思います。
それ以外の用途、例えば社外への DM 送信だったり、個別システムの通知メールだったり、自社が提供するサービスの送信元アドレスとするための利用については、社内メールドメインは絶対に利用させない／利用を蔓延させないのが大事だと感じました。
ゼロトラストが当たり前の現在、社内メールドメインをあっちこっちに流用してしまっている中で SPF/DKIM/DMARC にちゃんと対応していないと、企業のセキュリティやコンプライアンスとしてはリスクにしかなり得ないと思います。ですが、社内メールの利用の仕方をきちんと統制しないと、そのための施策を迅速に遂行するのに弊害となってしまい、最悪の場合、取り返しがつかない結果を及ぼす可能性もあるのではないかと個人的に感じました。
社内の一部で利用されるような個別システムや自社サービスに関連するものなどの送信元アドレスは、一律で社内メールとは異なる独自ドメインだったり、サブドメインの利用だったり、あるいはサービス既定のドメインの利用を検討する方が良いと思ったということを自身の備忘録としてここに記録しつつ、同じような苦労にあう方が 1 人でも少なくなれば良いな、と思う次第です。