blastengine を本番サービスに組み込んで運用を始めてから困ったこと

これは エンジニアが知っておくべき メール送信・運用ノウハウ、メールの認証技術やセキュリティについて投稿しよう！ by blastengine Advent Calendar 2025 シリーズ 1・17 日目の記事です。

昨日（16 日目）のシリーズ 1 は ktdatascience さんでした。

ついでに…シリーズ 2 のほうも興味深い話でした。

---

昨年のカレンダーで blastengine を本番運用に使い始めた記事を書きました。

そして実際に運用を始めてから困ったことが出てきました。

エラー停止の運用が大変

私の所属組織では、blastengine を「SaaS からの通知メール送信用」として使っています。

blastengine の場合、API ドキュメントに

1つの宛先に対し2週間以内に2度以上のハードエラーが発生すると、宛先はエラー停止対象となります。期間は最大で2週間となります。

と書かれているとおり、2 週間以内に 2 回以上のハードエラーが発生するとエラー停止状態に入ります。

正確には、blastengine における「ハードエラー」には

• 受信側サーバーから「ハードエラー」にあたる応答コード・メッセージが返ってきた
• 受信側サーバーに TCP / SMTP(S) レベルで接続できなかった（接続が確立しなかった・通信中に遮断された← Connection timed out や Connection refused など）

の両方が含まれます。

また、「2 回以上」ですが、これは

• 同一メールに対するリトライ（再送信）

を指すのではなく、

• 別のメールを同一の宛先に 2 通以上

という意味のようです。
（1 通のメール送信について 3 回以上リトライしているログを確認済み）

エラー停止状態に入ると、最大 2 週間は対象のメールアドレス宛のメール送信ができなくなります。

そして最大のポイントですが、これを書いている 2025/12 現在、blastengine には API でエラー停止状態を解除する機能はありません。

つまり 「（最大）2 週間待ちたくなかったら手作業で解除しなければならない」 です。

とはいえ他社のメール送信サービスのように「API で停止解除できる」のも…闇雲に停止解除した結果、送信元 IP アドレスのレピュテーション（評価）を下げてしまったり、メール送信サービス自体から ban されかねないので一概に良いわけではないのですが。

ちゃんと原因を調べて対象アドレスを削除・更新したりエラーの原因を取り除いたりしてから停止解除しないといけないですね。

でも、そんなにエラーで止まるの？

はい、止まります。

全体の中ではごくわずか（1% よりもはるかに小さい割合）ではありますが。

実際に運用している中では、応答ベースで見て以下のケースが多いです。

• 551 宛先のメールアドレスがありません
• 552 宛先のメールボックスがいっぱいです
• 554 宛先サーバでエラーが発生しました

（話の流れの都合上、順番を変えて触れていきます）

552 宛先のメールボックスがいっぱいです

大体メッセージどおりなので対処は比較的楽です。
（「頼むからメールボックスを整理して！」と思いながらも、自分自身整理ができないタイプなので何も言えません）

551 宛先のメールアドレスがありません

こちらについても「利用者が通知先のメールアドレスを変えたのに SaaS 側の登録を変え忘れているんだろう」と推測できる…かと思いきや、それほど単純なものではありません。

実際には、それ以外に

• 受信側でドメインの更新・移管やレンタルサーバー・メールサービスの移行作業でミスをして受信ドメインの名前解決トラブルが発生していた
  • そしてそのトラブルが解消されずに続いている…（放置していて大丈夫なのか？）
• 受信側の迷惑メール対策システムに迷惑メール（の送信者と）判定された上、嘘の応答コード・メッセージを返された
  • 特定ベンダーの迷惑メール対策システムを導入しているレンタルサーバーでは、このような挙動に

というケースもありました。
（意図せず移行前のメールサーバーと移行後のメールサーバーの両方にメールが送られていたり…）

554 宛先サーバでエラーが発生しました

こちらについても、

• 受信側サーバーの障害・メンテナンス停止
• 受信側サーバーでのメンテナンス作業ミス
• 受信側の迷惑メール対策システムに迷惑メール判定された
  • 迷惑メール判定された上で IP フィルタリングやサービスへの接続フィルタリングを動的に操作する仕組みで一定期間受信側への TCP / SMTP(S) 接続を遮断された
    • 遮断対象は単一 IP アドレスの場合もあれば同じ送信サービスがもつ複数のアドレス・アドレスブロックの場合もありそう
    • このケースでは、送信側サーバーの立場では受信側サーバー障害との区別がつかない
    • そして、原理上同じ送信側サーバー・受信側サーバーの組み合わせのすべてのメールが一定期間遮断される
      • 場合によっては遮断のトリガーを引いたのが自社サービスからの送信ではなく他社サービスが blastengine から当該受信サーバーに送信したメール、というケースもありうる（ここまでくると原因調査は混迷を極める）

などのパターンがあり、ログに記録された応答コード・メッセージだけでは原因が判然としないケースが多いです。

「あれ？」と思われた方もいらっしゃるかもしれませんが、blastengine では「そもそも受信側サーバーから応答コード・メッセージが返らなかった」ケースも 554 をログに記録します。

551・554 などの場合は

利用者に確認してもほぼ原因特定につながる回答は返ってこないので（それはそう）、

• blastengine の送信（配信）ログ
• 受信側（宛先）ドメインの登録状況
• 同・DNS レコードの登録状況

などを一とおり眺めて原因を推測し、アクションを起こしています。
（blastengine のサポートにも問い合わせをするケースがありますが、比較的細かいところまで調べた上で回答していただけるので助かっています← Connection timed out や Connection refused などについてもサポートへの問い合わせで発覚）

「受信拒否される」って言うけど、SPF / DKIM / DMARC はちゃんと設定してる？

もちろんです。ルックアップ回数、鍵長などで問題が生じないようにしています。

ついでにいうと文面はテンプレート的ですが、詐欺メールとしてよくある文章・キーワード・怪しい URL などは含まれていません。

じゃあ「受信拒否」は何が原因？

いかなるときも 100% これが原因、と断言できるわけではありませんが、これまでによく発生している（と思われる）のがこれ↓でした。

SaaS などからの通知メールとして気を付けなければならない点として、

• 短時間に大量のメールを同一メールアドレス（場合によっては同一ドメイン・同一宛先サーバー）宛てに送らないようにしなければならない

があります。

メールの送信量に関わる問題行為としては、

• 取得したばかりのドメインや使い始めたばかりの IP アドレスからいきなり全力大量送信

というものがありますが、それとは別の話です。
（すでに長期間利用していてそれなりに送信実績のあるドメインで、自社運用の MTA から少しずつ blastengine による送信に切り替えていく流れで移行したので）

マーケティング目的の一括送信であれば送信レートに対する配慮は常識ですが、通知系メールの場合、SaaS アプリケーション側での考慮が漏れているケースが意外と多く、何も考えずにメール通知機能を実装してしまうと、利用者の通知設定次第でほぼ同じタイミングに何通もの通知メールが同じ宛先に送信されてしまう可能性があります。

これが受信側で「迷惑行為」と判断された結果、一時的に受信拒否（遮断）されてしまうわけです。

先日、高知で IAjapan 第 25 回 迷惑メール対策カンファレンス（JPAAWG 8th General Meeting 併催）がハイブリッド開催されましたが、その中でも、日本のキャリアメールや Gmail などでの受信レート制限について、具体的な数値や、計測手法の概要などを示す形で言及されていました。

（講演資料が公開されていないようですので、ここで詳細を書くのは控えます）

受信側としては、

• 一気にメールがやってきたのでしばらく受信を停止
• その後解除

という処理の流れになるわけですが、blastengine は冒頭に書いたとおり「2 週間以内に 2 回以上のハードエラーが発生するとエラー停止状態に入る仕様」であり、

• 受信側が受信を停止（遮断）している間に 2 通目の送信→ハードエラー→エラー停止状態へ
• 受信側が受信停止をやめても送信側（blastengine）でエラー停止状態に入ってしまっているので、手作業で解除するまでそのメールアドレスには送信不可

なので、受信側の処理との相性が悪いわけですね。

なお、blastengine ではこのあたりを含む各種問題への対処のためにリトライ送信の方法を工夫しているそうですが、ここで詳細を書くのは控えます。

回避するには？

ワークアラウンドとしては「通知設定を調整して大量のメール通知が送信されないようにしてください」と利用者にお願いすることになります。

ただ、これだけでは心許ないので、同一メールアドレス宛への通知が一気に送信されないよう（場合によっては 1 通のメールにまとめて通知するなど）、システム的な対応も必要です。

なお、送信（受信）レート以外にも、当然レピュテーションなどのスコアの総合評価で迷惑メール判定されることはあります。

ただしそのケースでは、どちらかというと受信拒否ではなく「迷惑メールボックスへの振り分け（またはラベリングなど）」や「受信側での破棄」が行われやすいようです。
（blastengine にはエラーが返らないのでエラー停止状態には入らない）

ちなみに

さらっと流しましたが、「受信側サーバーの障害・メンテナンス停止」も DNS やネットワークの障害、DoS 被害などを含めると割と頻繁に発生しているようです（宛先ドメインのレンタルサーバーに関するメンテナンス・障害告知で確認できる範囲だけでも）。

---

シリーズ 1・18 日目は ussu_ussu_ussu さんです。

…見てみたらカレンダーの趣旨に合わない記事を投稿されていたので、シリーズ 2・18 日目のエントリにリンクしておきます。