SESのDomainのverifyについて

 

SESのDomainのverifiyでは何をどう設定すればよいのか、設定にどれくらいの時間がかかるのかという点にとまどうことがあります。

 

SESでは送信元となるEmailアドレスについて、あらかじめverify(有効性の事前確認)をされていなければなりません。verifiedされたEmailアドレスからのみメールを送信することが可能となります。verifyを実行すると対象となるアドレスに対して、SESから確認のメール(Amazon SES Address Verification Request)があり、メールの中にあるURLにアクセスすることで有効性の確認が行われ、verifiedになります。

 

複数のEmailアドレスからメールを送信する場合は、それぞれのEmailアドレス毎にこの作業を行うのは面倒です。DomainをverifyすればそのDomainからのメールはすべて送信可能となります。Domainをverifyでは、該当Domainに指定されたTXTレコードをDNSサーバに登録します。その後、AWSが(おそらく一定間隔でTXTレコードをルックアップして)そのDomainの有効性を確認しているようです。

 

使用しているDNSサーバがRoute 53でも企業独自DNSサーバでも同様ですが、TXTレコードに対して、下のName/Valueの値をそのまま登録します。何も余計な文字列は加えません。ただし、Valueに関してはダブルクォテーションで囲む必要があります。これはSESの仕様というより、DNS側の仕様(RFC仕様)によると思います。実際にRoute 53でTXTレコードを登録する際にValueに文字列だけを登録しようとするとエラーとなり、登録できません。文字列の最初と最後にダブルクォテーションをつける必要があります。

 

f:id:temporal:20130223230047p:plain

 

verifyにどれくらい時間がかかるのかという目安ですが、おおよそですが、Route 53の場合は10分程度、独自DNSサーバであれば3時間以内くらいが目安かなぁという感じでした。これはあくまで目安であり、正式文書では最大72時間かかる可能性もあるようです。

http://docs.aws.amazon.com/ses/latest/DeveloperGuide/verify-domains.html

If you are not using Route 53, Amazon Web Services needs to verify that the TXT Name and TXT Value have been added to your DNS settings. This may take up to 72 hour

 

上のおおよその時間を過ぎてもDomainがverifyされない、verifiyが失敗している場合は以下のコマンドを実行して、期待するtxtレコードが取得できるか確認しましょう。

$ dig testtext.ドメイン名 txt 

 

SES 複数のアカウントでのProduction Access(プロダクションへのアクセス) 申請について

 複数のアカウントでSESにProduction Access(プロダクションへのアクセス)の申請を行う際に注意が必要なようです。

 

注意点の前に、まずProduction Access(プロダクションへのアクセス)やSandbox(サンドボックス)が何かわからない方は、以下のFAQを見るとよいと思います。

    http://aws.amazon.com/jp/ses/faqs/#9

        Q: Amazon SES の使用はどのように開始できますか

        Q: Amazon SES のテストと評価を終了した後、何をすればよいのですか？

        Q: プロダクションへのアクセスのリクエストが処理された際、どのように私に通知されますか？

 

SandboxはSESの評価版のような状態で様々な制限があり、実際に使用する場合はProduction Accessの申請を行う必要があります。

 

http://aws.amazon.com/jp/contact-us/　の Amazon SES のプロダクションアクセス より申請を行えばよいようです。(英語での申請) 普通に申請すれば、普通に申請が通るはずです。

 

しかし、以下のフォーラムのように複数のアカウントでSESにProduction Access申請を行う際に理由を聞かれる場合があるようです。

 

既に、あるアカウントでProduction Access権限を持っているものの、関連する他のアカウントでもProduction Access申請を行うと以下のようなメールが届きます。

 

https://forums.aws.amazon.com/thread.jspa?messageID=416534

Greetings from Amazon Web Services,

We noticed that we already granted you Amazon Simple Email Service (Amazon SES) production access on a related account. Unfortunately, at this time we cannot grant your request for an additional Amazon SES account. Please continue to use your existing ccount for your sending needs. If you have a compelling reason for needing multiple accounts, please send a brief explanation on why you would require Amazon SES production access on this AWS account? If your reason for requesting access on multiple accounts is to send greater email volume, please submit an extended access request instead. http://aws.amazon.com/ses/extendedaccessrequest/     Please note, we are only able to provide information about the related account to the email address associated with that account.

 

 

なぜ、このように理由を聞かれるのか。

 

複数のアカウントを使用して、メールを送信し、課金されるのはユーザなのだから、別にAWS側から制限される必要もないはず。なぜでしょうか。

 

以下のフォーラムに少し記述がありました。この文章の概要ですが、複数アカウントでSESのサービスを利用しても問題はない、しかし複数アカウントでProduction Accessの申請を行い、送信可能メール数を不正に増やすことはterms of service(サービス利用規約)に反する可能性があるといっているようです。

 

https://forums.aws.amazon.com/thread.jspa?threadID=63441

For account-related questions, you can always reach out to Accounts & Billing Customer Support. Creating multiple accounts is not against the terms of service. It is OK to have different accounts for test and production systems, for example, or for separate business units which have completely distinct email sending that doesn't overlap. However, ttempting to circumvent service limits or policies is prohibited by the terms of service, and creating multiple accounts for the purpose of circumventing limits would be a violation of the TOS. Your quota will increase automatically as you send production email traffic. We recommend you gradually shift production traffic to Amazon SES as your quota grows. We describe some migration strategies in the Developer Guide. If the quota-ramp process isn't working for your circumstance, however, you can submit an Extended Access Request for additional quota, and we'll consider your request.

 

AWSがいうterms of serviceとはおそらく　http://aws.amazon.com/jp/aup/　Amazon Web Services 適正利用規約　のことでしょう。

 

Eメールまたはその他のメッセージの不正利用の禁止

サービス利用者は、商業的宣伝および情報発表を含め、大量の未承諾メールあるいはその他のメッセージ、プロモーション、宣伝、または勧誘（「スパム」等）を配信、公開、送信、または助長しないものとします。サービス利用者は、送信者の明示的な許可なしに、メールヘッダーを改変または隠ぺいしない、または送信者の認証を装うことはしないものとします。サービス利用者は、別のインターネットサービスプロバイダから送信されたメッセージが本規約または当該プロバイダの適正利用規約に違反する場合には、かかるメッセージへの返信を収集しないものとします。

 

 

SESでは大量の未承諾メール、スパムを送信しないように、送信メール数に制限をかけているようです。

    http://aws.amazon.com/jp/ses/faqs/#47

        Q: 送信できるEメール数に制限はありますか？

        Q: なぜこれらの送信制限があるのですか ?

プロダクションアクセスを受領済みの新規 Amazon SES ユーザーは、24 時間当たり最大 10,000 通のメールを、1 秒間に最大 5 通の速さで送信できます。お客様が高品質のEメールを送信していれば、Amazon SES によりこれらの制限が自動的に上昇されます。

 

バウンス(Bounce)、苦情(Complaint)、質の低いメールコンテンツ(Low Content Quality) ではないメールを送る実績を積んでいくと、メール送信制限が自動的に上昇するようです。

 

高品質のメールを送信しているかチェックされ、高品質のメールを送り続けていれば、メール送信可能数は増えていく仕組みなのでしょう。裏を返せば、実績を積まずに、2つ目以降のアカウントをProduction Access環境にして、送信クォータを増やしてはいけないということなのでしょうか。

 

単に送信クォータを増やしたいのであれば、以下の申請フォームより申請を行えるようです。

https://aws.amazon.com/jp/contact-us/

Amazon SES クォータ

 

 

理由を聞かれた場合にはどのように返信すればよいのか。

 

利用者それぞれに理由があるため、それぞれの理由を素直にAWSに返信すればよいでしょう。(テスト環境のアカウントと本番環境のアカウントと分けたいためなど)

 

とにかく、理由を聞かれた場合は、自身でメールを返信して、理由を伝えなければなりません。英語での返信は大変ですが、まあGoogle翻訳を使えばなんとかなるでしょう。

 

既に、あるアカウントでProduction Access権限を持っているものの、関連する他のアカウントでもProduction Access申請を行うと、上に記述したように理由を聞かれます。

 

ここでいう「関連する他のアカウント」ですが、支払いを行うアカウント(Payer Account)と支払いをゆだねるアカウント(Linked Account)の関係のみなのか、申請者のEメールアドレスの同じドメインのメールアドレスを持つ別の申請者との関連なのか、申請者と同じ会社に所属する別の申請者との関連なのか、どのような条件であるのかAWSから明確な情報の公開がありません。

 

上のフォーラムに書いてある「Production Accessの申請を行い、送信可能メール数を不正に増やすことはterms of service(サービス利用規約)に反する」という利用方法を防ぐことをAWSが目的としているのであれば、支払いを行うアカウント(Payer Account)と支払いをゆだねるアカウント(Linked Account)の関係のみではないかもせん。まあ、できる限り調べて、メールを返信するしかないでしょう。

SESを利用するにあたり必要な認識と対策(特にバウンス)

 

AWSのSESを利用するにあたり、あらかじめ認識しないといけないことが2つあると思います。

 

  • 場合により、SESを利用する権利を一時停止されてしまうことがある
  • 権利を一時停止されてしまった(もしくは警告を受けた)際には、その原因を自分で調査して、AWSに原因と対策を英文で報告する必要がある

 

また、あらかじめ以下いずれかの設定をしておく必要があります。(バウンスが多いために権利一時停止や警告を受けた場合原因調査のため)

 

  • メール送信プログラム側でReturn-Pathを指定し、Return-Pathに対して返信されたメールを調べる(デフォルトではSourceアドレスに対して返信)
  • Feedback NotificationsにてBounces SNS Notificationを指定し、SNS経由で通知されたバウンス情報を調べる

 

権利一時停止や警告を受けてしまった際に、主にAWSのUSのフォーラムにおいて、あらかじめ上の2点の認識せず、対策をとっていないため混乱に陥っているポストを見かけます。混乱を避けるためにどうすればよいか、どのように権利一時停止や警告を受け、どのように対応すればよいのでしょうか。

 

* 前提知識 * 

バウンスや苦情とは何か、どういうときに発生するのかという点がわからない人は以下を見るとよいと思います。

http://docs.aws.amazon.com/ses/latest/DeveloperGuide/Intro.ArchOverview.html

http://media.amazonwebservices.com/jp/wp/AWS_Amazon_SES_Best_Practices.pdf

 

 

どのように権利一時停止や警告を受けるのか。

 

権利一時停止や警告を受ける理由には主に以下の3つの理由があるようです

  • バウンス率が高い(High Bounce Rate)
  • 苦情率が高い(High Complaint Rate)
  • メールコンテンツの質が低い(Low Content Quality) 

 

フォーラムを見ると、権利一時停止の場合はAWSからメールで以下のような通知が来るようです。この例では"Critically Low Content Quality"が原因です。suspendが権利一時停止を意味します。

https://forums.aws.amazon.com/thread.jspa?messageID=369015#369015

"We have detected significant issue(s) with your sending pattern that require us to immediately suspend your SES sending privileges. This supersedes any previous probation warnings you may have received.The issue(s) triggering your suspension at this time, updated to reflect current statistics, are:

*Critically Low Content Quality: The average content quality has been critically low."

 

警告を受ける場合はAWSからメールで以下のような通知が来るようです。この例では"Unacceptably High Bounce Rate"が原因です。

https://forums.aws.amazon.com/message.jspa?messageID=283850

"Our analysis of your Simple Email Service sending pattern is showing that certain parameter(s) of your sending are at unacceptable levels. If these metrics do not improve, we will suspend your SES sending privileges. For each metric that is at an unacceptable level, we will allow you a defined number of emails to be sent to bring the metric back up to acceptable levels. Please note that if your sending quality decreases further actions may be taken before you have sent the number of emails noted below.

*Unacceptably High Bounce Rate: 1,216 of the last approximately 11,000 distinct emails addresses you have sent to have bounced.

*This issue must be fixed within the next 40,000 emails you send."

 

警告メールのタイトルは"Simple Email Service Probation Warning" のようです。Probationは、保護観察（期間）、謹慎期間を意味します。直ちに権利の利用一時停止にはならないものの改善がみられない場合は、権利の利用一時停止となる可能性があります。

https://forums.aws.amazon.com/thread.jspa?messageID=279816 

 

なお、権利一時停止の際に、AWSからのメールの通知に気づかないと以下のようにAPI callでsubscriptionを行う必要があると表示されたり、AWS Management ConsoleのSESタブで、SESのサービスに対してサインアップが必要と出るようです。最初にこの状況になった時は事態を理解できないでしょうね。

https://forums.aws.amazon.com/message.jspa?messageID=396422

"Noticed that my SES stopped working, any calls with our access/secret key result in a "403: The AWS Access Key Id needs a subscription for the service." I checked my management console and the SES tab says I'm not signed up for the service. AFAIK, we weren't breaking any rules and I didn't get any emails or anything about the service being halted."

 

 

どのような条件で権利一時停止や警告を受けるのか。

 

どのような条件で権利一時停止や警告を受けるのかについては、AWS側から明確に公開されていないようですが、Amazon Simple Email Service  E メール送信のベストプラクティスというドキュメントに「基本的に、バウンス率は 5% 以下に維持してください」、「基本的に、苦情率は 0.1% 未満に維持してください」という記述があります。こちらが一つの目安となるようです。

 

 

権利一時停止や警告を受けた理由は何であり、どのような対策をとるべきか。

 

AWSからの権利一時停止や警告の通知メールは英文ですが理由と取るべき対策が簡単に記述されているようです。

  • バウンス率が高いためか、苦情率が高いためか、メールコンテンツの質が低いためか
  • バウンス率、苦情率はどれくらいだったのか
  •  ses-support@amazon.com に原因と対策を英文で報告する必要があるのか、次のメール送信までに改善すればよいのか

 

権利一時停止や警告の通知メールだけでは状況を把握するのが困難です。そんなときには、以下のベストプラクティスを見るとよさそうです。

日本語: http://media.amazonwebservices.com/jp/wp/AWS_Amazon_SES_Best_Practices.pdf

英語: http://media.amazonwebservices.com/AWS_Amazon_SES_Best_Practices.pdf

 

苦情率が高いため、またはメールコンテンツの質が低いために権利一時停止や警告のメールを受信した場合は、上のベストプラクティスに対策に関する十分な情報が含まれているように思います。しかし、バウンス率が高いため権利一時停止や警告のメールを受信した場合への対処に関しては残念ながら十分な情報が載っていないように思えます。

 

 

バウンス率が高く、権利を一時停止されてしまった(もしくは警告を受けた)際にはどうすればよいのか。

 

結論からいうと、下のいずれかの方法による原因調査しかありません。

 

  • メール送信プログラム側でReturn-Pathを指定し、Return-Pathに対して返信されたメールを調べる(デフォルトではSourceアドレスに対して返信)
  • Feedback NotificationsにてBounces SNS Notificationを指定し、SNS経由で通知されたバウンス情報を調べる

 

ここで注意しなければならないのは、「あらかじめこれらの設定を行っていなければならない」という点です。

 

Return-PathもしくはBounces SNS Notificationを指定し、再度メールを送信した後に取得する情報を元に原因の特定をする必要があります。(ただし送信先メールアドレスが存在しないなどハードバウンスされた場合は、14日間はSESにblacklistとしてマークされ、相手側MTAまで送信されず、SES側でblaclisted addressとしてメールを送信できなかったというエラーが返ります)

 

バウンス対策に余分な費用を使いたくない、そんな方はReturn-Pathを使用するとよいと思います。ただし、Return-Pathで返ってくる情報はメール形式であり、これらの情報量が多くなると分析するために手間がかかかります。

 

* Return-Pathを使用する際の情報 *

 Return-Pathで指定するアドレスもVerifying Email AddressesでVerifyされている必要があります。

http://docs.aws.amazon.com/ses/latest/DeveloperGuide/Intro.AnatomyOfMessage.html

"Return-Path?The email address to which message bounces should be sent. We recommend that you always set the Return-Path parameter so that you can be aware of bounces and take corrective action if they occur. The address specified in Return-Path must be verified by Amazon SES?for more information, see Verifying Email Addresses"

 

SendEmail APIではReturnPathに指定する必要があり、SendRawEmail APIではReturn-Pathを指定していればReturn-Pathに指定したアドレスに情報が届き、Return-Pathを指定していない場合はSourceのアドレスに情報が届くようです。

 

なお、Verified Senders > 送信元Emailアドレス > Feedback DetailsのEmail Forwarding Feedbackが有効(デフォルト有効)になっていれば、送信元Emailアドレスに情報が届くようですが、やはりReturn-Pathに指定する方法が管理が煩雑にならずよいでしょう。送信元アドレスとバウンスとなったメールを受信するアドレスを区別することができます。どのように通知されるのかは以下のFAQに情報があります。

http://aws.amazon.com/jp/ses/faqs/#41

Q. バウンスや苦情の通知はどこに送信されますか?

 

 

 追加の費用が少々かかっても利便性を追求したい、そんな方はFeedback NotificationsにてSNS Notificationを使用するとよいと思います。

 

* SNSを使用する際の情報 *

 以下のような情報があるようです。

http://blog.suz-lab.com/2012/10/amazon-ses-mailbox-simulator-sns-sns.html

https://forums.aws.amazon.com/ann.jspa?annID=1765

 

あらかじめこれらの方法を参考に、バウンスバウンス発生時の処理を自動化させると非常に運用が容易になります。

 

しつこいようですが、バウンスの原因調査はあくまでReturn-PathもしくはSNS Notificationを使用するしか手段はありません。APIでメールを送信した際に返されるエラーメッセージを利用してのバウンス調査はできません。

        メール送信クライアントプログラム ---> SESエンドポイント ---> 受信側MTA

バウンスは受信側MTAで何らかの理由により、メールを受信できない場合に発生します。裏を返せば、受信側MTAまでメールは配達されています。受信側MTAまでメールが配達されたということは、SESエンドポイントはメール送信クライアントプログラムからの要求を正常に受け付けています。メール送信クライアントプログラムには、SESエンドポイントからエラーなどは返ってきません。

 

最後に

SESを利用する前に、あらかじめの認識及び対策をしておきたいものです。これらの認識や対策がない場合、いざ事が起こったときに、AWS、SIer、エンドユーザ企業皆が不幸な状況になってしまうことがあります。このようなことを書くと、SESを利用するハードルが高いように思えてしまいますが、実際に対策自体はそれほど難しいものではなく、過去にメール関連の仕事してきた人には簡単なことであると思います。また、SESをきっかけにメール関連の仕事を行う人にもそれほどハードルは高くないものだと思います。特徴をきちんと把握して利用すれば、SESでは非常に簡単に、低コストで質の良いメールを送ることができます。