AWS SES と送信ドメイン認証
メールのプロトコルにおいては、送信元はヘッダーのFromによって表現されるが、これは送信者が自由に設定をおこなえる。
なりすましでないのか、本当に送信元を信頼して良いのかということを検証する仕組みとして、現在は SPF と DKIM という送信ドメイン認証の仕組みがある。 それら、送信ドメイン認証の仕組みと、SESにおける留意事項を調べる。 Header From と Envelope From
SMTP では定められたいくつかのコマンドを用いてメールを送信する。 そのうちの一つの MAIL FROM コマンドは、送信サーバは受信サーバに送信元のアドレスを伝える。
そして、DATA コマンドでメールの内容を送る。 DATA コマンドの内容はヘッダとボディに分けられるが、そのヘッダの From: に記載されたものが、ユーザが目にする差出人アドレスになる。
前者を Envelope From 、後者を Header From と区別して呼ぶ。
SPF
SPF は Envelope From で称された送信元ドメインを認証する。 送信者はあらかじめ、DNSに、メールの送信サーバのIPアドレスを記載したレコードを公開しておく（SPFレコード）。
受信者は、メールが実際に送信されたIPアドレスと、SPFレコードが一致するかどうかを調べ、ドメインの認証する。
SESのおいては、デフォルトでは、 Envelope From は amazonses.com もしくはそのサブドメインとなる。
Envelope From が amazonses.com になるのは、基本的には合理的で、まず、当然AWSが管理するドメインなので、SPFに対応しているため、自身が管理するドメインにSPFレコードをつくらなくてよい。また、送信エラーの際のバウンスの通知先が amazonses.com となるため、送信状況がSESで正しく管理された状態になる。
ところが、実際には、次のような考慮が必要になる。
一部のキャリアは、Header From をドメイン認証に用いる。（これは SPF ではなく Sender ID とよばれる）
そのため、SPF レコード を自ドメインに登録しておくのが望ましい。(後述)
DMARC 対応（後述）を行う場合は、Envelope From は Header From と同じドメインもしくはサブドメインであることを要求される。
SES で対応する場合は、 MAIL FROM を自ドメインに変更する必要がある。
DKIM
DKIM では電子署名を用いて、ドメインの認証、また改ざんの検知をおこなう。 送信者は、公開鍵をDNSのレコードに登録しておく。そして、送信時には、秘密鍵で生成した署名をヘッダに付与する。
受信者は、 Header From に記載されたドメインから公開鍵を得て、署名をデコードし、送信元の認証を行う。
SESにおいては、比較的簡単な設定で、送信されるメールに署名を自動で付与できる。
バウンス
送信したメールが何らかのエラーにより配信できなかったことをいう。
中継するSMTPサーバはエラーが起きると送信元にそれを通知するメールを送り返す（バウンスメール）。
なお、バウンスメールの宛先は前述した Envelope From に宛てられる。
バウンスには、大きく分けてハードバウンスとソフトバウンスがある。ハードバウンスは、宛先が存在しないなど恒久的な理由、ソフトバウンスは、サーバ障害などの一時的な理由による。
ハードバウンスした宛先は Suppression List に登録される。（後述）
バウンス率が高い場合には、配信停止の対象となる場合があるので、行儀が良い挙動としては、バウンスが発生したアドレスはアプリケーション側で送信対象から外すなどの対処をする必要がある。
送信メールのレピュテーション
メールを受信するISPでは、信頼に足る送信元であるかを定量的なスコアで評価し、それに基づいてフィルタを行う。
このスコアを一般にレピュテーションと呼ぶ。
評価は、ISPが自身で行う場合と、 SenderScore のような専門の第三者サービスによって行われる場合がある。 レピュテーションは、送信元のIPアドレスやドメインごとに評価が行われる。
レピュテーションの評価に関する基準は様々だが、一つにはバウンス率がある。
バウンス率が高いと、適当なアドレスに無作為に送っているのではないか、つまりスパムとしての疑いが強くなるため、レピュテーションは下がる。
SES においては、 アカウントごとの 専用IPで送ることも可能であるが 、一定の送信ボリュームを持つユーザ向けであり、基本的には、アカウント間での共有IP で送信される。 そのため、SES はレピュテーションを高めるために、バウンスが多いユーザに対して制限をかけたり、Suppression List のような仕組みを用いている。
SES の Suppression List
SES では、宛先が存在しないなどの理由で送信メールがハードバウンスした場合は、そのアドレスは Suppression List に登録され、以降そのアドレスに送信しようとした場合はメールが破棄される。
Suppression List は最大14日間保持される。
Suppression List はアカウント間で共有される。
送信元IPが共有されるSESにおいては、レピュテーションを維持するために合理的な仕組みだが、日本の携帯キャリアの事情を考慮すると注意が必要である。
キャリアメールでは、送信元のドメインで拒否を行うような設定をなされているユーザがいまだに多い。たとえ自社のドメインからのメールの受信を許可するように設定されていても、他のアカウントから配信されたメールがフィルタにかかりバウンスしてしまうと、 Suppression List にそのメールアドレスがのり、自アカウントからの配信も失敗してしまうような事が起こりうる。
Suppression List から削除すれば送れるようになるが、またすぐ他アカウントでバウンスする可能性もあるため、その場合は対処が難しい。
また、Suppression List に登録されたアドレスに送って自動破棄された場合も、バウンスとしてカウントされるため注意する。
国内キャリア
各携帯キャリアにおいて、スパムフィルタなどを含めた仕様は非公開の部分も多いが、SPFなどに関する仕様は公開されている部分もあるので確認をしておく。
AU
SPFレコードの確認には、エンベロープFromに記述されているドメインを使用致します。
※お客さまが迷惑メールフィルターの「なりすまし規制 (高)」をご利用になる場合、エンベロープFromに加えてPRAに記述されているドメインを使用したSPFレコードの確認を行い、SPFレコードが無い場合はメールを拒否します。
PRAとして以下の順にヘッダをチェックします。
Resent-Sender → Resent-From → Sender → From
基本は、 Envelope From だが、場合によって Header From が用いられることもある。
Docomo
SPF（TXT）レコードの確認には、メールヘッダのFROMフィールドを使用します。なお、メールヘッダのFROMフィールドが存在しない場合はエンベロープFROMを使用します。
Header From が用いられる (Sender ID)
Softbank
特に詳細な情報なし
その他
モバイル以外のISPも含めてこちらにまとまっている。
DMARC
未調査
参考