神奈川県立高校ネット出願システムのGmail到達性問題、改めて深堀りしてみた
2024.09.022024年1月、神奈川県のネット出願システムでGmailにメールが届かないトラブルが発生しました。
身内が受験するため、出願システムのトラブルに巻き込まれた当事者として原因調査を試みていました。
先日『日経クロステック』より、本件について取材を受ける機会がありました。
取材協力した記事で取り上げられた問題について、さらに深堀り、詳細な分析を行った内容を以下に紹介いたします。
問題の概要
- 概要
- 志願者登録時、二次元コード読み取りと空メール送信が必要
- "@gmail.com"アドレスへの返信メールが届かない不具合発生
- 原因
- システムのメールサーバ設定が不十分
- 大量メール送信により、Gmailで迷惑メール判定
- 対応
- システムのメール設定見直し
- "@gmail.com"アドレス登録者623名に別メールアドレス提供
対応経緯の詳細
2024年1月9日
- 出来事：出願システムのアカウント登録、本稼働日
- 問題：「@gmail」のGmailアドレス使用者がメールを受信できないトラブル発生
2024年1月10日
- 送信状況：
- 生徒のGmailに2万3685通送信
- 成功したのは約800通（3.38％）
- 注目点：送信できたメールも、届くまでに十数時間を要したケースあり
2024年1月18日
- 対応：ベアメールへの切り替え作業を実施
2024年1月24日
- 出来事：受験生の出願期間開始日
- 問題：「@gmai」のGmailにメールが届かないトラブルが再発
- 送信状況：
- 午前11時台に送信したメール186通
- 正常に送られたのは4通（2.15％）
2024年1月25日
- 対応：県教委管理のメールアドレスを生徒に貸出
一連の対応を深堀
グーグルにスパム扱い解除を依頼
通常のGmail (@gmail.com) については、Gmail が提示する メール送信者のガイドラインの遵守 が求められ、窓口対応は期待できません。
受験生の Gmailアドレスが 有償の Google Workspace、もしくは Google Workspace for Education で発行された 独自ドメイン であった場合には、 独自ドメインの Google Workspace の管理者操作で許可リストの設定や、Google Workspace のカスタマーケア オプションの範囲で、サポートを受けられた可能性はあったと思われます。
https://support.google.com/a/answer/7663057?hl=ja#zippy=%2C管理者が行う対応%2C外部の送信者が検討すべき対応
Amazon SESの「標準IP」から「マネージドIP」に変更
Amazon SESを専用IP（マネージド）で利用することで、自身で評価を高めたIPアドレスの継続利用や、 他のSES利用者により評価が低下、汚染されたIPアドレスの利用を回避できる可能性が高まります。
今回、Gmailによってすでにスパム発信元と判定されている状態での専用IPへの切り替えは、自ら評価を落としたIPアドレスを継続して使用することになりかねず、逆効果だった可能性もあったと推測されます
マネージドIPは従来の標準の専用IPと比較して自動的にウォームアップを行う機構を備えるため、ウォームアップ期間を短縮できる可能性はありますが、依然として適切なウォームアップ過程が重要でした。
専用 IP を介して送信する E メールの数を徐々に増やすことで、専用 IP を自動的にウォームアップします。1 日あたり最大 E メール数は初日から増え、45 日間で最大 50,000 通に達します。このように段階的に増加させることで、IP はインターネットサービスプロバイダー (ISP) から高い評価を得られます。
専用 IP アドレス (標準) のウォームアップ
理想的にはリリースの数ヶ月前、新規取得したドメインであれば1日あたり数十通、実績のあるドメインでも最初は数千通の送信頻度でウォームアップを開始すべきでした。
バウンスや遅延が発生していないことを確認しつつ、段階的にメール送信数を目標数まで増やす事前準備が必要でした。
さらに、受付や出願の開始日などに出願システムの利用が集中、扱うメール数が大きく変化する場合、十分余裕を持たせたウォームアップと、ウォームアップ状態を維持するため一定量のメールを継続して送信する仕組みを用意する必要がありました。
エンベロープfromとヘッダーfromの不一致
メール認証(SPF、DKIM、DMARC)が適切に設定されていれば、エンベロープfromとヘッダーfromの不一致については、通常問題となる事はありません。
2024年1月15日、出願システムから送信されたメールのメール認証に不備はありませんでした。
- エンベロープfrom: @pref.kanagawa2.mail.shutsugankanagawa.jp
- ヘッダーfrom: @mail.shutsugankanagawa.jp
Amazon SESを利用して送信されている「Amazon.co.jp」のメールも同様の構成となっています：
- エンベロープfrom: @bounces.amazon.co.jp
- ヘッダーfrom: @amazon.co.jp
エンベロープfromとヘッダーfrom、サブドメインが一致しない状態でも、過去の送信実績とメール認証が適切であれば、@gmailのメールアドレスで問題なくメールを受け取ることが可能です。
また、Amazon SESではエンベロープfromとヘッダーfromを完全に同じドメインで利用することはできません。これは、バウンスしたエラーメールをSESで確実に受信するために必要な仕様です。
DMARCのDKIMアライメントを厳格（Strictモード）に設定した場合、エンベロープfromとヘッダーfromが完全一致しないAmazon SESから送信したメールのDMARC認証は失敗（Fail）することになりますが、この仕様はSendGridなど他の主要なメールサービスでも同様であり、Amazon SES特有の制限ではありません。
SendGridから送信されるメールのエンベロープFrom（Return-Pathヘッダに記載されるアドレス）は、SendGridにて自動的に生成されるため、送信側で指定することはできません
エンベロープFromを自由に指定できないのは、バウンス発生時の不達通知（NDR）をすべてSendGridにて受け取る仕組みになっているためです。
https://support.sendgrid.kke.co.jp/hc/ja/articles/360000226322-エンベロープFromを変更したいのですが
Postmaster Tools では原因特定不能
Google が提供する Postmaster Tools には速報性がありません。
数日以上の反映ラグが存在するため、1月9日に発生した問題については、Postmaster Tools で即時に確認できなかったことはやむを得ないと考えられます。
急激な変化や即時の問題については、他の手段（例：メールログの分析、バウンス率の監視など）と併用して調査する必要がありました。
後述のバウンスメールの受け取り不備があった事で、調査が難しくなったと推測します。
DNSサーバーのMXレコードの設定ミスを発見、修正
1月16日15時に指摘された、MXレコードの不適切な設定が修正されました。
- IPアドレスの直接記述を解消
- 末尾の余分な「.」を削除
変更前
10 13.113.157.93.
10 52.193.62.66.
10 52.194.140.218.
20 feedback-smtp.ap-northeast-1.amazonses.com.
変更後
$ dig mx mail.shutsugankanagawa.jp +short
10 ec2-13-113-157-93.ap-northeast-1.compute.amazonaws.com.
10 ec2-52-193-62-66.ap-northeast-1.compute.amazonaws.com.
10 ec2-52-194-140-218.ap-northeast-1.compute.amazonaws.com.
20 feedback-smtp.ap-northeast-1.amazonses.com.
この設定ミスの影響、以下の理由から致命的ではなかったと推測されます：
-
初期の正常動作：1月4日から8日の間、受験生の利用が少ない期間にGmailへのメール配信が正常に機能していた。
-
部分的な配信成功：8日以降も、3〜8%のメールはGmailに到達していた。
-
Gmailの評価システム：Gmailの送信者評価は複数の要因に基づいており、MXレコードの軽微な設定ミスだけで完全な遮断は起こりにくい。
MXレコードの設定は、メールシステムにとって非常に重要な箇所。
事前にメール設定に詳しい技術者によるレビューや、生成AIの活用などでも、望ましくないとされる設定は回避できた可能性はあったと思われます。
- プロンプト
「dig mx mail.shutsugankanagawa.jp +short」を実行しました。
次の応答が戻る状態は、MXレコードの設定として正しいですか？
回答をマークダウンの箇条書きで出力してください。
<text>
10 13.113.157.93.
10 52.193.62.66.
10 52.194.140.218.
20 feedback-smtp.ap-northeast-1.amazonses.com.
<text>
- Claude3.5 sonnet応答結果
- 設定は部分的に正しいですが、いくつかの問題があります：
- ✅ 複数の MX レコードが設定されており、冗長性が確保されています。
- ✅ 優先度（MX プリファレンス）が適切に設定されています（10と20）。
- ✅ Amazon SES のレコードは正しい形式です。
- ❌ 最初の3つのレコードは IP アドレスを直接使用しており、これは推奨されません。
- ❌ IP アドレスの末尾にピリオドがついていますが、これは不要です。
- 改善のための推奨事項：
- IP アドレスの代わりに、適切なホスト名を使用してください。
- IP アドレスを使用する必要がある場合は、A レコードを設定し、そのホスト名を MX レコードで参照してください。
- IP アドレスの末尾のピリオドを削除してください。
- この設定は機能する可能性はありますが、ベストプラクティスに従っていないため、将来的に問題が発生する可能性があります。
また、神奈川県が保有するドメインを利用できていれば、MXレコードを登録するタイミングで、県のドメインの管理部門から指摘を受け、是正できた可能性もあったと思われます。
バウンスメールの受信設定の不備が判明し修正
受信用のアドレス設定が誤っており、バウンスメールを受け取れない状況だった
「ネット出願システムは最初に学生が空メールを送る仕組みであるためバウンスメールは発生しないはずだが、正しく設定できなかったことをこのタイミングで発見した」（県教委）
1月18日に発見されたバウンスメール受信設定の不備は、Gmail配信問題を深刻化させた主要因の一つであった可能性が高いと考えます。
出願システムを利用する学生のGmail、ストレージ上限や転送設定の不備などでメールを受け取れない状態だった場合、 Gmail は バウンスメールを Return-Path(エンベロープfrom)、Amazon SESが用意したアドレスに送信する可能性がありました。
Return-Path: <[email protected]>
また、GmailのSPAM判定の仕組みについては公開されていませんが、Greylisting（グレイリスティング）方式相当の仕組みが採用されていた場合、実績の少ないドメインからGmailにメールを送信するためには、適切なバウンスメールの受け取りと、再送が必須となる可能性がありました。
- 実績のないドメインのメールは一時的な配送拒否
- 規格に沿ったメールサーバは、適切な間隔で再配送された場合のみ配送を許可
- 大量に迷惑メールを送信するツールは再配送を試みないか即座に再送する。遅延と引き換えにして効率的な遮断を実現
Gmailが一時的な配送拒否で戻したバウンスメール、受取拒否する状態であった場合、大量に迷惑メールを送信するSPAM送信元と判断された可能性は否定できないと思われます。
MXレコード(1)
エンベローブfrom (Return-Path) のドメインpref.kanagawa2.mail.shutsugankanagawa.jp
1月18日夜、バウンスメールを正しく受信できるように設定された後のタイミングで、確認した MXレコードについては正しい状態でした。
$ dig mx pref.kanagawa3.mail.shutsugankanagawa.jp +short
10 feedback-smtp.ap-northeast-1.amazonses.com.
バウンスメールを受け取れなかった当時の設定は不明ですが、
- 1月15日: @pref.kanagawa2.mail.shutsugankanagawa.jp
- 1月17日: @pref.kanagawa3.mail.shutsugankanagawa.jp
1月15日〜17日にかけて、kanagawa2、kanagawa3 、カスタム MAIL FROM 設定の変更が試みられていた可能性があります。
-
SESの機能不全
- Gmailで受取拒否されたメールアドレスに対し、SESが本来備える適切な再送および再送見送りの仕組みが機能しない状態に陥った可能性があります。
-
バウンスメールの大量発生
- 学生がGmail宛のメール送信を繰り返すことにより、さらに大量のバウンスメールが発生した可能性があります。
-
Gmailによる厳格な制限
- 上記の状況により、Gmailのシステムが当該送信元を極めて悪質なスパムメール送信者として判断し、強い利用制限を発動した可能性があります。
バウンスメールを放置すると？
メールの送信方法や内容に問題がある状態で送り続けたり、存在していない宛先にメールを送信し続けていると、スパムやなりすましなどの迷惑メール送信者と誤解され、IPアドレスやドメインがブラックリストに入ってしまうことがあります。自社のIPアドレスやドメインがブラックリストに登録されてしまうと、ISPによって迷惑メールと認識され、受け取りを拒否されます。正しい対処を行わずに放置したままにすると、こうした悪循環が発生してしまい、いずれメールは届かなくなります。
今回、@gmail 以外のメールアドレスにはメールが届いていた事から、この設定不備の可能性は低いと思われますが、もし SESのカスタム MAIL FROM 設定で、「適切な MXレコードが指定されていない場合は メッセージを拒否する」 設定がされていた場合、メール送信がSESにより全て拒否される可能性もあった箇所でした。
MXレコード(2)
ヘッダーfromのドメイン mail.shutsugankanagawa.jp。
バウンスメールの設定不備が修正されたタイミングで、mail.shutsugankanagawa.jpのMXレコードに重要な変更が加えられました。
変更後のMXレコード
$ dig mx mail.shutsugankanagawa.jp +short
10 ec2-13-113-157-93.ap-northeast-1.compute.amazonaws.com.
10 ec2-52-193-62-66.ap-northeast-1.compute.amazonaws.com.
10 ec2-52-194-140-218.ap-northeast-1.compute.amazonaws.com.
注目すべき点は、SESのバウンスメール受取先の指定が削除されたことです：
20 feedback-smtp.ap-northeast-1.amazonses.com.
次の記事で紹介されているメールの欠落を招く可能性がある状態でした。
一部のメールがランダムに受信できず何通かのメールが欠落し業務影響が出る
MXレコードの優先度
MXレコードの優先度（preference）は0〜65535の範囲で指定可能で、数値が小さいほど優先順位が高くなります。一般的には「1」「10」「20」などの数値が使用されます。
1月16日時点のMXレコード
10 13.113.157.93.
10 52.193.62.66.
10 52.194.140.218.
20 feedback-smtp.ap-northeast-1.amazonses.com.
問題点の分析
-
優先度「10」のサーバーの問題
- IPアドレスが直接指定され、不要な「.」が付与されている
- EC2上で動作していたメールサーバーの証明書が自己証明書で信頼性に欠ける
-
優先順位の逆転の可能性
- 上記の問題により、Gmail送付先として正しいFQDNとサーバー証明書で設定されている優先度「20」のSESのバウンスメール用サーバーにメール送信を試みた可能性がある
ベアメールへの切り替え作業を実施
AWSを扱う立場としては Amazon SES で正しい利用を実現に至らなかったのは残念ですが、メールサービスに詳しい組織やエンジニアのサポートを受けられることを重視、ベアメールを採用された事は妥当な判断であったと思われます。
ベアメールへの切り替え後、エンベロープfromとヘッダーFromのドメインが一致するようになりました：
- Return-Path: [email protected]
- From: "神奈川県公立高等学校入学者選抜インターネット出願システム" [email protected]
メール認証に関連する設定についても不備はない状態でした。
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=mail.shutsugankanagawa.jp.202401 header.b="rRMsQd/c";
spf=pass (google.com: domain of [email protected] designates 210.168.80.145 as permitted sender) [email protected];
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=mail.shutsugankanagawa.jp
しかし、「shutsugankanagawa.jp」ドメインの評価向上が期待できる追加設定は行われておらず、ドメイン評価を高める効果は限定的だったと思われます。
- DMARCポリシーがNoneで、quarantineやreject設定がされていない
- DMARCアライメントモードが厳格モード(strict)に設定されていない
Gmail にメールが届くようになった理由は、以下と推測します。
-
送信元IPアドレスの変更：
- Amazon SESからベアメールで管理されているIPアドレスに変更
-
利用者数の減少：
- 多くの学生が「@gmail」以外のメールアドレスを利用して登録を済ませた可能性
- 結果として、Gmail宛の送信数が減少
Gmailにメールが届かないトラブルが再発
受験生の出願受付開始日、ベアメールから送信したメールがGmailには届かない問題が再発しました。
出願サイトのメールについて問題点は検出されませんでしたが、
-
急激な送信量の増加
- @gmailを登録した学生が受付開始直後に殺到した
- 短時間で多数のメールが@gmailアドレスに送信された
-
メール遅延の発生
- 大量送信による遅延が発生した
-
再送要求による悪化
- メールを受け取れなかった学生からの再送要求
- さらなる遅延が悪化
-
Gmailの防御措置
- 遅延の悪化によりGmail側からメール遮断措置が取られた
ベアメールの新しいメール環境からGmail宛のウォームアップが実施できていれば、再発を回避できた可能性がありますが、しかし、今回のスケジュールでは準備時間が不足していた可能性が高いと推測されます。
県教委管理のメールアドレスを生徒に貸出
今回の一連の対策では、最も有効なものだったと思われます。
Google Workspace for Education で発行された 独自ドメイン の管理者機能を利用して、ベアメールのメールサーバの情報を 許可リストに追加する施策が取られていたのであれば、SPAMメール判定の回避に有効だったと思われます。
1月9日のネット出願システムのアカウント登録時に発生した@gmail利用の問題に対し、以下の対策を講じていれば、Amzon SESの利用を継続したまま、早期解決の可能性はあったと考えられます
-
県管理メールアドレスの提供
- @gmail利用で問題が発生した学生に対し、即座に県管理のメールアドレスを提供
-
Amazon SESの適切な設定
- Amazon SES、ドメイン認証、MXレコードを正しく設定
-
専用IPアドレスの確保
- Amazon SESのスタンダード専用IPアドレスを取得
- 永続的に利用可能なIPアドレスを確保することで、一貫した送信元を維持
-
Google Workspaceの許可リストへの追加
- 確保した専用IPアドレスを県管理のGoogle Workspaceの許可リストに追加
-
ウォームアップ
- 県管理のメールアドレスに対し、遅延、エラーが発生しない頻度で規模を段階的にふやしながらメールを送信
- 専用IPアドレス数が不足に伴う遅延、エラーが確認された場合、AWSサポートを利用して増強手配
原因の総括
-
Amazon SESの設定と管理:
- 「標準IP」から「マネージドIP」への変更が適切に行われなかった
- ウォームアップ期間の不足
-
DNSとMXレコードの設定ミス:
- IPアドレスの直接記述や余分な「.」の付与など、基本的な設定ミスが存在
-
バウンスメール処理の不備:
- バウンスメールを正しく受信・処理する設定がされていなかった
-
急激な送信量の増加とGmailの防御措置:
- 出願期間開始時の急激な送信量増加がGmailの防御措置を引き起こした
-
ドメインの信頼性不足:
- Gmailの信頼度が低い、新規ドメインを採用した
- 信頼度を高める措置を怠った
これらの要因が複合的に作用し、Gmailへのメール到達性の問題を引き起こしたと推測します。
有効な対策
以下の対策を適切に実施していれば、メールが届かないトラブルを回避できた可能性が高いと考えられます：
信頼性の高いドメインの利用
- メールの利用実績が十分なドメインの利用許可を得る
- 既存のドメイン管理部門との調整、必要な対応工数を予め確保する
SESの適切な設定
- Amazon SESの設定を適切に行うため、メールアドレスと送信ドメインのセットアップガイドラインを活用する
- Virtual Deliverability Manager アドバイザーの機能を活用する
バウンスメールの適切な管理
- バウンスや遅延の発生イベントログを記録し、適切な通知を手配する
- バウンスメールを意図的に発生、例外系のテストを実施する
- SESのバウンス率・苦情率を監視する
ウォームアップなどの準備
- 余裕を持ったスケジュールでウォームアップを実施、ウォームアップを維持する仕組みを整備する
まとめ
適切な準備、設定、管理を行うことで、多くの問題は回避できた可能性が高かったと思われます。
本事例の分析、大量メールを取り扱うシステムで類似のトラブル再発防止に役立つことを願っています。
参考リンク
東京新聞
ITmedia NEWS
