Help us understand the problem. What is going on with this article?

AmazonSESから携帯キャリアメールに届く確率を上げる

More than 1 year has passed since last update.

この記事は

  • とあるサービスを運営しています
  • そのサービスでは、(よくある動きですが)一度ユーザ仮登録メールを送ってリンクをクリックして本登録画面に遷移するような動きをします
  • AmazonSESからこのメールを送信しているのですが、携帯キャリアのメールアドレス(特にdocomoとau)の大半が本登録リンクをクリックしていない事象が発生しました
  • どうやらそもそもメールが到着していないようです
  • この記事はこの問題へ対処するにあたり色々調べたのでそのメモです

よくあるワークアラウンド

  • エンジニアの守備範囲としては「mydomain.netからのメールが到着するように許可してください」という注意書きを入れてお茶を濁してもいいのですが、はっきり言ってそんな設定してくれる人は一握りなので、もっと効果的な対処をしたかったです

結論からいうと

  • あまりに当たり前みたいな結論ですが、DNSに自サイトのドメインのSPFのTEXTレコードを入れるというのが結論です
  • なんだSPF設定してない情弱か!で終わりそうですがちょっと待って!「AmazonSESはそれ自体がSPF対応しているから個別には入れないでOK」という理解をしている人が(以前の自分も含めて)多いのです
  • だってGMail含む「普通のメール」では普通にSPFチェック通って到着するんですから

前提として(メールのFrom)

Fromの種類

  • そもそもの前提知識ですが、メールのFromには下記の2種類あります
    • (1)エンベロープFrom
    • (2)ヘッダFrom
  • (1)はバウンスを処理するような場合などに利用される「システムが利用するアドレス」的な役割です
  • (2)はメーラでFromとして表示される「人間が利用するアドレス」的な役割です
  • メールファイルをテキストエディタで開くとどちらも書いてあります

SESで送った場合

  • SESでメールを送信すると、各Fromには下記のように指定されます
    • (1)・・・xxxxx.smtp-out.us-west-2.amazonses.com
    • (2)・・・xxxx@yourdomain.net
      • 自サービスのドメイン

普通のメールサーバのSPF確認

  • 普通のメールサーバ(例えばGMailなど)は基本的にSPFは上記の(1)エンベロープFromのドメインのみチェックします
    • つまり、上記の例でいうと、amazonses.comドメインを管轄しているDNSにSPFの問い合わせをかけるわけです
    • この場合、おそらくAmazon自らが管理しているDNSサーバに、SPFレコードが元々登録されていると思われます
    • これが、SESはSPF設定不要説の根拠だと思われます
  • 逆に(2)ヘッダFromはチェックしません
    • だから、mydomain.netのDNSにSPFレコードの設定をしなくても問題ないわけです

携帯キャリアのメールサーバのSPF確認

  • 一方、携帯キャリアのメールサーバについては下記の記載があり、要するに設定によってヘッダFromをチェックすると書いてあるのですが、よくよく仕様を付き合わせると、標準的なオススメ設定(かんたん設定)で強度を高めに指定するとほとんどのケースでヘッダFromをチェックすることになります
  • (これが情報が散っていて非常にわかりづらいのですが・・・)

au

※お客さまが迷惑メールフィルターの「なりすまし規制 (高)」をご利用になる場合、エンベロープFromに加えてPRAに記述されているドメインを使用したSPFレコードの確認を行い、SPFレコードが無い場合はメールを拒否します。
PRAとして以下の順にヘッダをチェックします。
Resent-Sender → Resent-From → Sender → From

  • このPRAというのが表現は異なりますがヘッダFromのことです
  • さらにいうと、auの「オススメ設定」にすると、「なりすまし規制 (高)」が自動的に付いてくるので、多くのauユーザはヘッダFromのSPFチェックが走るわけです

docomo

したがいまして、お客様が、「全て拒否する」と設定された場合には、DNSサーバに必要な対処を行っていないISP事業者様や企業様などからのメールは認証ができないため受信できません。
...
SPF(TXT)レコードの確認には、メールヘッダのFROMフィールドを使用します。なお、メールヘッダのFROMフィールドが存在しない場合はエンベロープFROMを使用します。

  • こちらは直接ヘッダという表現がでてきました
  • さらにいうと、docomoについては「かんたん設定(強)」に設定すると自動的に「なりすましメールの拒否設定(パソコンなど) = 全て拒否する」に設定されます
  • なので、こちらについても、やはり多くのdocomoユーザはヘッダFromのSPFチェックが走ります

softbank

というわけで

  • 様々な情報を組み合わせると、結論として携帯キャリアメールに到達させるためには、自ドメインのSPFレコードを自ドメインを管理しているRoute53なりから設定してやる必要があります
  • ちなみに、上記キャリア公式にも書いてありますが、ほんとのSPFレコードには対応していないので、TEXTレコードで追加する必要がありますので注意

結果

  • 実際、これを設定する前は、auとdocomoのおよそ60%のメールが到達していなかったようなのですが、設定したところほぼ100%到達するようになったようです

終わりに

  • キャリアメール爆発しろ!
shouta-dev
Railsが大好き!
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした