Amazon SESの受信ルールでやらかした話
概要
AmazonSESの受信ルールを利用する際は複数登録したMXレコードに注意しないといけない。
メール受信テストをする際は複数回確認する方がベター。
対象読者
AmazonSESの受信ルールを利用する方
起こったこと
弊社はAmazonSESの受信ルールとLambdaを使ってメール転送処理を実装しています。
簡単に言えば受信したタイミングをトリガーとして、Lambdaで定義した設定に基づいてメール送信してくれるといった感じです。
まず初めにサービス送信されたメールが半分程度転送されていないと開発者から報告を受けました。
弊社はEC2にサービスを乗せており、postfixを使ってメール送信をしています。そのためまずはEC2にあるPostfixのログを確認しました。
しかし、該当のメールはバウンスしている様子もなく正常に送信できている模様・・・。
そもそもアプリケーションから送信できていないのかな？と思いアプリ側のログも見ましたが、やはり送信できている。
そうなるとAWS側が怪しいよね？ってことでSESの設定を見直し。
・S3のバケットポリシー
・Lambdaの設定（同時実行数等）
・SESの受信ルールの見直し
ダメだ・・・。どこを見ても合っている気しかしない。開発していて一番恐怖なのはなぜ動いているか分からない時。原因の分からないエラーほど怖いものはない。
原因判明
途方に暮れてしまってかれこれ3時間ほど経ってしまった。stackoverflowとか公式ドキュメントを見直していた時にrepostでとある記事を発見。
その中にこんな一文がありました。
注: ドメインに複数の MX レコードがある場合は、受信メール (SES) の MX レコードの優先度が最も高いことを確認してください。MX レコードの前の数字は優先度を示します。数字が小さいほど、優先度が高くなります。
おや、これではないか？試しにローカルで問題となっているメールドメインのMXレコードを確認すると
10 inbound-smtp.ap-northeast-1.amazonaws.com
10 mail.example.com
優先度同じやん・・・。
MXレコードには優先度がある
この時初めて知ったのですが、MXレコードには優先度があるんですね。
メール配送先の優先度を設定します。
半角数字の整数を入力してください。0～65535の範囲内で、値が小さいほど優先度は高くなります。
同じ優先度だとラウンドロビン方式で割り当てられる模様。つまり半分はSESで受信したから転送できていたけど、半分は別のメールサーバーで受信していたってことね。
対応
repostにある通り、SESの優先度を一番高くしました。その後複数回メールを送信したところ無事全てのメールが転送されました。
そもそもなぜ複数あるのか？という疑問については、旧システムからのリプレースでメールサービスも切り替えたからです。旧システムのメールシステムはブラックボックスすぎて廃止することもできなかったので一旦レコードを残していたのですが、それが仇になりました。。。
幸いアプリケーションのログで転送できていなかったメールを抽出することはできたので、後日転送できなかったお客様に謝罪のメールを送信し解決しました。
まとめ
大体のバグはエラーログに出力されればなんとか追えるのですが、こういった深いレイヤーの事象については知識不足もありかなり手間取ってしまいました。
最善はバグを起こさないことですが、起こってしまった時の監視フロー、起こさないためのテスト等課題が見えた問題でした。
皆さんもAmazon SESの受信ルールを利用する際は、MXレコードの設定を必ず確認するようにしてください！
Discussion