「スロットリング（throttling）」と聞いて胃が痛くなる人は、きっとメール（SMTP）システムを本格的に運用されているんだと思います。
知らない人は、知らないままでいた方が幸せかもしれません…
スロットル（throttle）は、動詞だと「抑圧する」・「首を絞める」という意味です。
名詞としては、自動車などのエンジンで燃料の流量を調整する「絞り弁」のこととなります。
概ね「流れを止める」というニュアンスのようです。
メールシステムにおいてそんなことをしたら、すなわち「メールが届かない」ということになります。
迷惑な話だと思われるでしょうが、実際に時々行われていますし、そこには一応ちゃんとした理由もあります。
決して、偶発的な事故や悪意のある攻撃ではありません。
そもそもメールは、その基礎的な部分においてセキュリティ的に「ざる」です。
（なんでも、初期のインターネットは性善説に基づいて発達したそうです。）
そのためにスパムメールが横行してしまい、様々なセキュリティ強化策が「後付け」さ れてきました。
スロットリングもその一つで、受信側のメールシステムが実行する防衛手段という位置付けになります。
ざっくり言うと、「急に大量のメールを送って来るようになったIPアドレス」を検知し、そこから送られてくるメールをブロックする仕組みです。
（類似のスパマー対策としてブラックリストもありますが、それは今回のテーマであるスロットリングとは違います。それについてはまた後日取り上げます。）
つまり、「あのIPアドレス（を使っているメールサーバー）は、スパマーに乗っ取られたんじゃないか？」と疑うわけです。
「疑う観点」は、どうやら「メール送信量急増」の他にもあるようですが、それをスパマーに知られるわけにはいきません。
そのため、「急増」を検知する基準も含め、具体的なことはほとんど公開されていません。
（セキュリティにおいては当然のことです。）
メールホスティング事業者が公開している情報もありますので、参考にしてみて下さい。
１、スロットリングの原因と対策（SendGrid）
２、IP スロットリングについて（Microsoft）
３、【ホスティング】Gmailへのメール配送遅延に関するご案内（Zenlogic）
２、のリンク先を見ると分かるように、Exchange Online（Office365のメールサービス）にもスロットリングの機能があり、「IPスロットリング」と呼称されています。
基本的にはOffice365利用者をスパムメールから守ってくれる有難い機能なのですが、厄介な点もあります。
それは、利用者（Office365契約企業）からは、スロットリングの実態を把握・制御できないことです。
検知基準の設定や実行の判断はMicrosoft自身が一括して行なっているため、各Office365契約企業のExchangeOnline管理コンソールには一切表示されません。
受信のログにも、「IPスロットリングによりブロックした」ことは記録されません。
（リンク先にはEOPの機能だと書いてありますが、実態としてはおそらく、EOPによる検疫の前に独立したフィルターを設けてブロックしていると思われます。）
また、個別のOffice365契約企業からの要望を受けて、その企業だけで実行/解除することもできません。
送信側メールサーバに記録されるエラーや、送信者に返って来るNon-Delivery Reportの記述を見れば、「Exchange OnlineのIPスロットリング機能によってブロックされたのだろう」と判断できます。
しかしそれを直接確認できるのは送信側であり、受信側（Office365契約企業）ではありません。
さて、タイトルにある「安否確認」ですが、ここでは「大規模自然災害等の際に、家族や勤務先へ自身の状況を報告すること」を指します。
家族間であればチャットアプリを利用する人が多いと思いますが、企業の場合はまだメールの方が主流かもしれません。
すると、発災直後にはインターネット上を膨大な量の安否確認メールが急に飛び交い始めることになります。
おそらく、今週月曜(2018/6/18)に発生した大阪府北部の地震でも、そのような状況になっていたと思われます。
その結果、スロットリングが行われてしまったケースもあったのではないでしょうか。
特に、安否確認専用のメールシステムの場合は、ほぼ必然的に「特定IPアドレスからのメール送信量急増」が起こるわけですから、スロットリングされやすいと言えます。
そのせいで安否確認ができなかったら、「本当に必要な時に役に立たないシステム」というレッテルを貼られてしまいます。
もちろん、スロットリングは安否確認メールだけを狙ってブロックするわけではありません。
対象IPアドレスから送られて来る、他のメールもブロックします。
一つのIPアドレスが複数の企業により共用されているメールホスティングサービスの場合、被災企業が安否確認メールを大量送信したせいでスロットリングされると、災害とは無関係の企業まで業務に支障が出てしまいます。
そのような事態を回避するために、様々な方策が考えられます。
思いつくままに挙げてみると・・・
[1] 発災後、直ちにスロットリングの基準を緩和する。（受信側メールシステム運営者が実施）
[2] 膨大な量の安否確認メールを、多数のIPアドレスから少しずつ送る。（安否確認メールシステム運営者が実施）
[3] スロットリングされて送信が滞ったら、別のIPアドレスから送り直す。（安否確認メールシステム運営者が実施）
[4] 安否確認メールの送信には利用しないよう、予め契約企業に通達しておく。（メールホスティング事業者が実施）
[5] 安否確認のためにメールを使わない。企業向けチャットアプリ等、その他の通信手段を利用する。（被災企業が実施）
[6] 少なくとも発災直後には、安否確認を行わない。（被災企業が実施）
だいたい、こんなところでしょうか。
メールが送れなくなる（届かなくなる）原因は意外なところに潜んでいる、というお話でした。