今回は、Amazon SESからiCloud（@icloud.com）へ送信しているメールで、8月から急にエラー（バウンス）が増えた件について、この1か月ほど調査・検証した結果と、その対応についてまとめてみたいと思います。
同様の現象に遭遇した方の参考になれば幸いです。
この記事の結論
- 現象：Amazon SESの共有IP帯からiCloud（
@icloud.com）宛てにメールを送信する際、554 5.7.1 Command rejectedによるバウンスが発生する。特定の時間帯（夕方～夜間）に集中しており、これまで同じ 554 5.7.1 でも付加されていた [BS01] や [HM08] といった詳細コードが、今回は付加されていない。- 今回の検証結果：送信元ドメインの評判（レピュテーション）や宛先アドレスそのものが原因というより、Amazon SESの共有IPを経由した送信に対して、iCloud側で時間帯などに応じた一時的な流量制御が行われている可能性が高いと考えられた。
- 対応：少なくとも今回の環境では、
554 5.7.1を通常の恒久的なハードバウンスとは区別し、時間帯をずらして自動再送（リトライ）する運用が有効だった。
発生した環境と症状
送信環境
-
送信インフラ：自社サーバー（Postfix） → Amazon SES（Shared IP） → 受信サーバー
-
送信制御（Postfix）：iCloud専用のトランスポートを構築し、過剰な接続・送信を制限
-
icloud_destination_concurrency_limit = 1（同時接続数1） -
icloud_destination_rate_delay = 4s（1通送信ごとに4秒遅延、最大15通/分） -
ドメイン認証：SPF / DKIM / DMARC すべてPass
-
メールヘッダのレピュテーションのスコア：
X-ICL-Score: ~2.3
※iCloudで受信したメールのヘッダに付与されていたカスタムXヘッダです。一般的にはそのメールのレピュテーション評価値（低いほど好ましい）と言われていますが、Appleから公式な説明は確認できていないため、参考値として記載しています。
発生したエラー
-
エラーコード：
554 5.7.1 Command rejected -
発生率：iCloud宛て送信数の 0.3%～1.6%程度
-
発生時間帯の偏り：
- 全発生数の 約75%が18:00～22:00の夜間ピーク帯に集中
- 1通/4秒まで流量を制限しても、該当時間帯に数件～十数件のバウンスが継続して発生
このため、単純に「短時間に大量のメールを送信したこと」が直接の原因なのか、それとも送信元IPなどを含む別の要因があるのかを調査することにしました。
仮説の検証とデータ分析
「メールアドレスの不備」なのか「送信経路・IP側の問題」なのかを切り分けるため、以下の検証・実測データの集計を行いました。
1. バウンス発生アドレスの重複検証
過去1か月のエラー履歴を突き合わせた結果、**554 5.7.1 が発生したアドレスのうち、過去にも同じエラーが発生していた宛先は106件中8件（約7.5%）**でした。
特定の宛先アドレスそのものに恒久的な問題があるのであれば、同じ宛先で繰り返し失敗するケースが多くなると考えられます。
今回のデータでは、約92.5%が初回のバウンスでした。
この結果から、少なくとも今回観測した 554 5.7.1 の大部分については、宛先アドレスそのものが恒久的に無効であることが原因とは考えにくいと判断しました。
2. 送信抑制の解除と再送信テスト
私の運用するメール配信システムでは、Amazon SES等でソフトバウンス（受信拒否やメールボックスフルなど）が発生した場合、通常は15日間の送信抑制を行っています。
今回の 554 5.7.1 については、手動でこの抑制を解除し、異なる時間帯に再送信するテストを行いました。
- 結果：23/26件（約88.5%）で正常に送信完了
- 再発した3件：いずれも夜間のピーク時間帯（18時台後半～21時前半）に送信
この結果から、少なくとも今回テストした宛先については、554 5.7.1 発生後に時間帯を変えて再送することで、高い割合で正常に配送できることが確認できました。
一方で、再送によって必ず成功するわけではないため、「一時的な拒否である可能性が高い」ことを示す材料の一つとして捉えています。
3. 別ドメインでの並行検証
さらに、全く異なる送信ドメインから、同じ構成のPostfix / Amazon SES共有IPを経由してiCloud宛てに送信するテストも行いました。
その結果、こちらでも朝夕の特定の時間帯に 554 5.7.1 が発生する現象が確認されました。
送信ドメインを変更しても同様の傾向が確認されたことから、今回の現象については、送信ドメイン固有のレピュテーションだけでは説明しにくく、Amazon SESの共有IPや、そのIPからiCloudへ流入するトラフィック量などが関係している可能性が高いと考えました。
ただし、Amazon SESの共有IPで他の利用者がどのようなトラフィックを発生させているかは確認できないため、「他社トラフィックが直接の原因」とまでは断定できません。
対策と運用上の回避策
今回の検証結果から、554 5.7.1 Command rejected を、メールアドレス不存在などの恒久的なハードバウンスと全く同じ扱いにすることには問題があると考えています。
特に、時間帯を変えて再送することで正常に配送できるケースが多かったため、一時的な拒否として扱い、通常の恒久的な送信抑制とは区別するという運用を検討しています。
対策A：システム側でのバウンス判定と自動再送
Amazon SNS経由でバウンス通知を受け取った際、エラー内容が 554 5.7.1 Command rejected に該当する場合には通常のハードバウンスとは異なる処理を行います。
- メールアドレス不存在などの恒久的なハードバウンスとは区別して、限定的な再送処理を行う
- 再送の際には一定時間待機する。可能なら夜間ピーク帯（18:00～22:00）を避け、翌朝や深夜など別の時間帯に再送する
- 再送回数には上限を設ける
今回の検証では、時間帯を変えることで正常に配送できるケースが多かったため、この方法が比較的実装しやすい回避策になると考えています。
なお、無条件に再送を繰り返すのではなく、エラーコードやエラー内容を確認した上で対象を限定することが重要です。
Amazon SESでは、Amazon SNSと組み合わせることで、バウンス通知と元の送信メールを対応付ける仕組みを比較的容易に構築できます。
対策B：SES Managed Dedicated IP（マネージド専用IP）の導入
共有IPによる影響を切り分けたい場合は、Amazon SESの Managed Dedicated IP（マネージド専用IP） の導入も選択肢になります。
共有IPではなく専用IPを利用することで、自社の送信トラフィックと他のSES利用者のトラフィックを分離できます。
今回のように「共有IP側の要因が関係しているのではないか」という仮説を検証するという意味でも、専用IPへの移行は検討する価値があります。
ただし、専用IPに変更すれば必ず 554 5.7.1 が解消するとは限りません。
また、送信量や送信パターンによっては専用IPの運用上考慮すべき点もあるため、現在の送信規模に適した構成かどうかを確認する必要があります。
まとめ
今回、Amazon SESの共有IPからiCloudへメールを送信した際に発生した 554 5.7.1 Command rejected について、約1か月にわたって発生時間、宛先の重複、再送結果、送信ドメインを変更した場合の挙動などを調査しました。
その結果、
- 特定の宛先に恒久的に発生するエラーではないケースが多い
- 特定の時間帯に発生が集中する
- 送信速度を大幅に制限しても発生する
- 別の送信ドメインでも同様の傾向が確認された
- エラー発生後に時間帯を変えて再送すると、多くのケースで正常に配送できた
という傾向が確認できました。
これらのことから、今回の環境では、送信元ドメインや宛先アドレスそのものよりも、Amazon SESの共有IPからiCloudへ流入するトラフィックや、iCloud側の動的な流量制御などが関係している可能性が高いと考えています。
そのため、554 5.7.1 Command rejected を通常の恒久的なバウンスとは区別し、時間帯を変えたリトライを行う仕組みを導入することが、現時点では現実的な対策の一つだと考えています。
また、根本的に共有IPの影響を排除する方法としてAmazon SESのマネージド専用IPへの移行についても検討していますが、現在は送信量がそこまで多くない（iCloud宛てでは～1000通／日、～2万通／月）ので慎重になっています。
「専用IPへ移行して安定したレピュテーションを構築するには、この程度の送信規模では十分ではない」との情報も多いので、専用IPを安定して運用するために必要な送信量や、段階的な移行（ウォームアップ）の期間等を考慮した上で判断する必要があります。
以上、同様にAmazon SESからiCloudへメールを送信していて、554 5.7.1 Command rejected に悩まれている方がいましたら、参考になれば幸いです。