はじめに

Webアプリケーションのメール配信基盤として、Amazon Simple Email Service(以下、Amazon SESと表記します)を採用しました。SPF、DKIM、DMARC等の送信元ドメイン認証の設定をした上で、Gmail、Outlook、Yahooといった主要なISPへの到達確認も完了した状態でした。

しかし、メールの動作を確認したところ、icloud.com（Appleのメール）宛のみ、メールが一切届かないことが発覚しました。さらに、迷惑メールフォルダにも入らず、Appleのサーバー側で拒否されるという状況でした。

本稿では、この現象に対してのトラブルシューティングと解決までのプロセスを記録します。

1. Amazon SESの状況

以下はGmail宛に送信したメールのヘッダー情報です。すべての認証が「PASS」となっていました。

2. 問題：iCloudからの拒否メッセージ（554 5.7.1 [HM08]）

しかし、icloud.com宛にメールを送信したところ、iCloudの画面でメールを確認できませんでした。Amazon SESから連携されるバウンス通知に以下のエラーが記載されていました。

1{
2    'emailAddress': 'xxx@icloud.com',
3    'action': 'failed',
4    'status': '5.7.1',
5    'diagnosticCode': 'smtp; 554 5.7.1 [HM08] Message rejected due to local policy. Please visit https: //support.apple.com/en-us/HT204137. Txn ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
6}

この [HM08] というエラーコードを調べると、Apple側のローカルポリシーにより拒否されていることが分かりました。
まずはAppleの公式ドキュメントに記載されている要求と、当時の設定状況を比較しました。

一部の項目が未対応ですが、今回はトランザクションメールのみを扱うため無視して大丈夫と判断しました。
その他の要件は満たしているため、ドメインやIPの信頼性が足りないのではと仮説を立てました。

3. 原因の切り分け：ドメインなのか、IPなのか

今回使用するドメインは、既存ドメインのサブドメインを使用していました。
以下に検証内容と結果を表にまとめます。

検証結果から、example.com のようなセカンドレベルドメインは到達しても、sub.example.com のような実績ゼロのサブドメインは到達しませんでした。そのため、Apple側のドメインに対するポリシーが原因であると予想しました。

Appleのメールヘッダーにある「信用スコア」について

iCloudで受信したメールのヘッダーには、X-ICL-Scoreという信用スコアが存在します。

1X-ICL-Score: 3.33303334422

このスコアに明確な仕様を見つけることはできませんでしたが、検証を繰り返した結果、おおよそのことが分かりました。
スコアが低いほど信頼性が高く、迷惑メールのしきい値は4あたりであることが分かりました。スコアが4を超えると迷惑メールに格納され、4未満なら受信トレイに格納されました。

結論として、実績のないサブドメインであったこと、またAmazon SESの共有IPを使用していることが原因でAppleのローカルポリシーで拒否されたと判断しました。

4. 解決策：ウォームアップ

ドメインやIPの信頼性を高めるには通常、数週間の「ウォームアップ」が必要です。しかしAmazon SESのマネージドIPがその役割を担っていると判断して、ウォームアップを実施していませんでした。どうやらAWS側ができることはウォームアップの割合に応じて自動的に専用IPと共有IPを使い分けることだけのようで、ドメインやIPの信頼性を上げるのはAmazon SESを使用する側の責務だったようです。そのためウォームアップを開始しました。
以下条件です。

5. 結果：信用スコアが上昇し、迷惑メールフォルダへ到達

ウォームアップを実行した結果、Amazon SESからiCloud宛のメールはなんとか迷惑メールフォルダではありますが到達することができました。また送信量が一気に増えたことが影響し、Amazonから専用IPの割り当てを受けました。現在では、iCloudへの不達は発生していません。

SPF、DKIM、DMARCの設定さえできていれば、メールは届くものだと思っていましたが、今回のiCloudのようにメールが届かないISPも存在するということを知りました。
新規ドメインや新規IPを使うなら、ウォームアップは最初から計画に入れておく必要があることを学びました。

6. 補足：検証過程で見えた特異な挙動

ユーザー操作による影響

一度迷惑メールフォルダに入ったメールを受信トレイに移動したり、送信元を連絡先に登録したりすると、その受信者には受信トレイに届くようになります。ただしこれはユーザー個人の操作が反映されるだけのため、別のユーザーでは依然として迷惑メールに入ることを確認しました。

メールの本文によるフィルタリング

IPやドメインの信頼性が低い段階で、件名・本文ともに「TEST」のみにしたところ、数通に1回だけiCloudへの到達を確認できました。本文の構造も評価対象になっていると考えられます。

カスタムMAIL FROMドメイン

Amazon SESのベストプラクティスで推奨されている設定のため改めて適用しましたが、即効性のある変化は見られませんでした。とはいえベストプラクティスである以上、設定しておくことは推奨します。

7. 今後の対策

まずはAmazon SESの設定を推奨通りに設定すること、そして設定が完了したあとにウォームアップをすることの2点です。ウォームアップは想定する送信量までスロースタートから徐々に送信量を増やしていくスタイルがいいかと思います。

参考文献:

Apple: Postmaster information for iCloud Mail