Amazon SESでFCrDNSチェック対策を試みた記録：サンドボックスでの検証 (1)

　この記事は、最終的には採用に至らなかった構成の検証記録です。

先日、ConoHa VPS上に専用SMTPリレーサーバーを構築しましたが、実は当初、Amazon SES(Amazon Simple Email Service)をSMTPリレーとして利用する構成を検証していました。

mail.exiv.netから直接外部へメールを配送する方式を見直し、Amazon SES経由でメールを送信することで、FCrDNSチェックへの対策になるか確認するためです。

実際に、Amazon SESの初期設定、DNS認証、SMTP認証情報の作成、Postfixからのリレー送信テストまでは完了、サンドボックス環境内での検証では、SPF/DKIM/DMARCがPASSすることも確認できました。

一方で、Amazon SESは初期状態ではサンドボックス環境のため、送信先が検証済みメールアドレスなどに制限されます。そのままでは通常の外部向けSMTPリレーとして利用できません。
　Amazon SESを通常のSMTPリレーとして利用するには、AWSへサンドボックス解除、つまり本番利用（Production Access）の申請を行い、承認を受ける必要があります。

今回、本番利用申請を行いましたが、AWS側の審査の結果、残念ながら承認されませんでした。そのため、Amazon SESを本番用のSMTPリレーとして採用することは断念しました。

なお、今回の申請では、承認されなかった具体的な理由までは通知されませんでした。以下は推測になりますが、Amazon SESはスパム送信や大量メール送信への悪用を防ぐ必要があるため、本番利用申請の審査が以前より厳しくなっている可能性があります。

　このような経緯から、最終的にはAmazon SESではなく、ConoHa VPS上に専用SMTPリレーサーバーを構築することになりました。

FCrDNS問題への対策や、Amazon SESを利用したSMTPリレー構成を検討している方にとって、少しでも助力になればと考え、サンドボックス解除前までのAmazon SES構築記録として本記事を公開します。

Amazon SES(Amazon Simple Email Service)の概要

　Amazon SES（Simple Email Service）は、AWSが提供するクラウド型のメール送信サービスです。
本来は、マーケティングメール等、大量のメール配信するためのプラットフォームとして設計されています。
一般的には「アプリケーションに組み込んでメールを送るための基盤」として利用されますが、今回は「SMTPリレー」として利用する計画です。

メールサーバから外部へ直接メール送信するのではなく、SESを経由してメール送信することで、メールの到達性や信頼性の向上が期待できます。

FCrDNSチェックの回避：
　正引き/逆引きが不整合となる環境でも、AWSの信頼されたIPアドレスからメール送信されるため、受信拒否されにくくなります。
IPレピュテーションの確保:
　AWSが厳格に管理するクリーンなIPアドレス群を利用することで送信元としての信頼性を担保、メール到達率の向上が期待できます。
認証設定（SPF/DKIM）の簡略化:
SES側でこれらを代行・補完できるため、送信元メールサーバのセキュリティ設定が不完全な状態でも、近年、厳しくなってきたメールセキュリティ要件を容易にクリアできます。

本来の「大量送信」という主目的からは外れた使い方になりますが「配送性と運用性を両立する構成」として、小規模環境や検証環境において非常に有効な手段です。
　今回は、逆引き（PTR）問題の回避のためにAmazon SESを利用します。

Amazon SES 費用感

Amazon SESは従量課金型のサービスであり、いわゆる「月額固定料金」ではありません。
利用した分だけ課金される仕組みとなっています。

まず、AWSアカウントの作成時にはクレジットカードの登録が必須となります。
また、初回登録時に付与される無料クレジット（プロモーション）が存在する場合がありますが、これを使い切ると通常の課金が開始されます。私の場合は100USドルのクレジットが付与されました。

Amazon SESのメール送信料金は、基本的に以下の通りです。

メール送信数に応じた従量課金（約 $0.10 / 1000通）
500通 / 月で試算すると ≒ $0.05（約7〜8円程度）
添付ファイル等のデータ転送量に応じた課金（通常は微小）

今回のように個人用途で月に数百通程度の送信であれば、実質的には無視できるレベルのコストです。

なお、AWSは「使った分だけ翌月に請求される」後払い方式のため、数円単位であってもクレジットカードに請求が発生します。

以上の通り、Amazon SESは無料ではありませんが、今回、私の用途であればコストは気にならないレベルの費用感です。

AWSサインアップ

アカウント作成
メールアドレス認証が必要です。メールアドレスは今回の対象ドメインのメールアドレスではなく、管理用のgmailアドレスを利用することにしました。

ステップ1: アカウントプランの指定
Amazon SESによるSMTP リレー運用では、特にサポートは不要と思います。無料プランを選択しました。

ステップ2: 連絡先情報の入力
　[電話番号の国コード]と[国または地域]がものすごくわかりづらい。んー、何順のソートなんだろう。
コンボボックスの真ん中ぐらいに日本はあります。

[携帯電話番号]は先頭の0は省略して入力しました。
　[住所]の入力は英語表記で入力するのが良さそうです。[住所]の表記順は戸惑う方もいらっしゃるかも。
[住所1]に部屋番号-建物名ｰ番地として入力、[住所2]は空欄に。残りは、区と都道府県の順に入力しました。

ステップ3：請求情報としてクレジットカード情報を入力します。
ステップ4：携帯電話SMSによる本人確認を行えば、AWSサインアップ完了です。

Amazon SES（Simple Email Service）の設定

無事に登録が完了、AWSマネジメントコンソールにログインできたら、画面上部の検索窓に「SES」と入力、「Amazon Simple Email Service」を選択します。

Amazon SESスタートページに移動します。

セットアップが開始されます。

ステップ１：メールアドレスを追加

　セットアップの最初に、管理用のGmailアドレスを登録しました。この画面ではメールアドレスの入力が必須となります。
　Amazon SES初期状態(サンドボックスモード)では、検証済みのメールアドレスに対してのみメール送信が可能です。ここで登録したメールアドレスは、Amazon SESにおける送信先（宛先）として使用可能な検証済みアドレスとして登録されます。
登録メールアドレスの検証が完了すると、登録アドレスを宛先としてテストメールの送信が可能となります。

ステップ2：送信ドメインを追加

　SESでメール送信に使用するドメインを登録します。送信ドメインは後の工程でDNSレコードでドメインの所有者確認が行われます。

送信ドメイン
対象ドメインの所有権を検証する設定です。指定されたDNSレコードを登録、検証が完了すると、そのドメインをFromとしてメール送信できるようになります。
MAIL FROM ドメイン
今回は、MAIL FROMドメインとして、新たにsesサブドメインを設定することにしました。
バウンス（配信エラー通知）の送信元ドメインを指定する設定です。
デフォルトではamazonses.comが使用されますが、独自のサブドメインを設定することで、SPFやDMARCの整合性が向上し、メールの信頼性を高めることができるそうです。
MX即実行時の動作
MAIL FROMドメインに設定したMXレコードが利用できない場合の動作を指定します。
「デフォルトのMAIL FROMドメインを使用」：カスタムMAIL FROMドメインの代わりに、SES側（amazonses.com）のドメインにフォールバックして送信が継続されます。
一方、「メッセージを拒否」を選択すると、MXが正しく設定されていない場合に送信自体が停止します。
通常はデフォルトのままで問題ありません。

送信ドメイン（exiv.net）の検証が完了すると、exiv.netドメインのメールアドレスについては、個別のID登録は不要となります。

ステップ3：配信性能の強化

Virtual Deliverability Managerは、主にマーケティング用途（大量配信）向けの機能です。

配信率・開封率・クリック率の分析
レピュテーション管理
配信最適化の提案

オフに設定しました。

ステップ4：専用IPプールを作成

大量配信（数万〜）、マーケティングメール向けの機能です。オフに設定しました。

ステップ5：テナント管理を追加

今回は単一用途となり、分離も不要なため、テナント管理は行いません。
SaaS事業者向けの機能であると考えます。そのまま次へをクリックしました。

ステップ6：SESを確認して使用を開始

これまでの設定内容を最終確認する画面です。
設定内容に誤りがないことを確認、問題がなければ「使用を開始」をクリック。セットアップを完了させます。

リソース作成の完了

　完了メッセージが表示されます。検証メールを送信したので確認するようにとのご指示です。

設定したメールアドレスで検証メールを確認します。検証メールのイメージです。

リンクをクリックすると検証完了となります。

あ、はい。ご丁寧にありがとうございます。よろしくお願いします。

送信ドメインを検証

ドメインを登録すると、次にドメインの所有確認を行います。このステップでは、Amazon SESが指定するDNSレコードをドメインのDNS設定に追加し、ドメインの所有権を証明します。

「DNSレコードを取得」をクリックすると、設定に必要なレコード情報が表示されます。

これらのレコードをDNSサーバに設定します。設定後、しばらく経つと、ドメインの検証が完了します。

SMTP認証情報の作成

　Amazon SESをSMTPリレーとして利用するためには、SMTP接続用の認証情報（ユーザー名とパスワード）が必要です。SESへ接続する際に使用するSMTP認証情報を作成します。

この画面では、Amazon SESのSMTP認証にIAMユーザーを作成します。
「ユーザーの詳細を指定」ユーザー名は自動生成されます。ユーザー名は変更可能です。私はわかりやすい名前に変更しました。
　また、このユーザーにはメール送信に必要な権限（ses:SendRawEmail）が付与された専用のユーザーグループが自動的に設定されます。[Create User]ボタンをクリックします。

　このIAMユーザーは、SMTP認証で直接使用するログイン情報ではありません。IAMユーザーは、SMTP認証情報を生成するための元となるユーザーです。SMTP認証情報（ユーザー名・パスワード）は、このIAMユーザーの作成処理の中で内部的に生成されます。

　次の画面では、生成済みのSMTP認証情報（ユーザー名・パスワード）が表示されます。

この画面に表示されている情報は、この画面でのみ確認可能であり、後から再表示することはできません。必ず記録して控えるようにしてください。
　ユーザー名とパスワードはクリップボードにコピーすることが可能です。また、パスワードは表示リンクをクリックすることで、マスク（アスタリスク表示）を解除して確認できます。SMTP認証情報はCSVファイル形式でダウンロードすることも可能です。
次のステップでは、このSMTP情報をPostfixに設定します。

Amazon SES連携確認用：送信ルーティング設定

　Amazon SESは初期状態ではサンドボックス環境（非本番環境）で提供されます。
この状態では、送信先は検証済みのメールアドレスに限定され、送信数にも制限があります。
　そのため、本番環境での運用を見据え、サンドボックス環境で連携設定や送信テストなどの事前検証を十分に行うことが重要です。
これらの検証および動作確認が完了した後に、サンドボックス解除（本番アクセス申請）を行います。

　最初にサンドボックス解除申請前の動作確認として、Postfixを経由した送信テストを実施します。
検証のため、特定の宛先に対してのみ送信経路をSESへ切り替える構成とし、IDとして設定したGmailアドレス宛のメールのみをSES経由（SMTP認証）で送信するようPostfixを構成します。

1. SMTP認証情報の設定

sasl_passwdファイルにSMTP認証情報を設定します。

[root@exiv ~]# vi /etc/postfix/sasl_passwd

接続先SMTPサーバと認証情報を設定します。

接続先とポート
[email-smtp.ap-northeast-1.amazonaws.com]:587 ※ STARTTLS
※角括弧 [ ] はDNS MXレコードを参照せずに指定ホストに直接接続
区切り：
スペース（半角スペース）
SMTP_USER：
SESのSMTPユーザー名を設定します
区切り
:（コロン）を入力
SMTP_PASSWORD：
SESで生成されたSMTPパスワードを設定します。

[email-smtp.ap-northeast-1.amazonaws.com]:587 SMTP_USER:SMTP_PASSWORD

入力内容を保存して終了。設定した情報をpostmapコマンドでpostfix参照用のデータベースに変換します。
作成したファイルのパーミッションをオーナーのみに制限します。

[root@exiv ~]# postmap /etc/postfix/sasl_passwd
[root@exiv ~]# chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

2. transport設定

transport は「宛先ごとに送信経路を切り替える」機能です。特定のメールアドレスだけをAmazon SES経由で送信するためのルーティング定義を設定します。transportは、宛先ごとの配送ルール（transport map）を定義するファイルです。

[root@exiv ~]# vi /etc/postfix/transport

ファイルには初期状態でコメントが記載されていますが、そのまま最下行に配送設定を追記します。

#宛先（IDとして登録したメールアドレス） smtp:[email-smtp.ap-northeast-1.amazonaws.com]:587

[email protected] smtp:[email-smtp.ap-northeast-1.amazonaws.com]:587

transportファイルの行の構文は以下のとおりです。

宛先を指定：
IDとして登録したメールアドレスを指定します。
ルーティング対象となる送信先メールアドレスです。
区切り：
スペースまたはタブで区切ります（1つ以上で可）。
プロトコル/接続先/ポート
smtp:[email-smtp.ap-northeast-1.amazonaws.com]:587
※角括弧 [ ] はDNS MXレコードを参照せずに指定ホストに直接接続

入力内容を保存して終了。設定した transport ファイルを postmap でPostfix用のデータベース（.db）に変換します。その後、作成したファイルのパーミッションをオーナーのみに制限します。

[root@exiv ~]# postmap /etc/postfix/transport
[root@exiv ~]# chmod 600 /etc/postfix/transport /etc/postfix/transport.db

3. main.cf 設定追加

　main.cf には、transportによるルーティングの参照設定、SES接続時に必要となる認証参照設定（sasl_passwdとの連携）、外部SMTP接続時のTLS動作条件（smtp_tls_security_level）を追記します。
　postconfコマンドを使い、現在の設定値を確認、既存設定がある場合は重複追記しないように調整します。

relayhostは、Postfix全体のリレー先を指定する設定です。
transport_mapsは、宛先ごとに配送経路を指定する設定です。

[root@exiv ~]# postconf relayhost transport_maps
relayhost =
transport_maps =

smtp_sasl_auth_enableおよびsmtp_sasl_password_mapsは、リレーサーバーへ接続する際の送信認証についての設定です。
smtp_tls_security_levelは、リレーサーバーへ接続するときのTLS利用に関する設定です。
smtp_sasl_security_optionsは、SMTP認証(SASL)のポリシー設定です。

[root@exiv ~]# postconf smtp_sasl_auth_enable smtp_sasl_password_maps smtp_tls_security_level
smtp_sasl_auth_enable = no
smtp_sasl_password_maps =
smtp_tls_security_level = may

[root@exiv ~]# postconf smtp_sasl_security_options
smtp_sasl_security_options = noplaintext, noanonymous

main.cf には、transportによるルーティングの参照設定、SES接続時に必要となる認証参照設定（sasl_passwdとの連携）、外部SMTP接続時のTLS動作条件（smtp_tls_security_level）を追記します。

確認したところ、smtp_tls_security_level = may はmain.cfに記述されていました。この設定を上書きするため、ファイルの記述をコメントアウトします。その他の設定項目については、Postfixのデフォルト値が適用されている状態でした。今回は、コメントを追記したいため、直接main.cfを編集して設定変更を行います。

[root@exiv ~]#  vi /etc/postfix/main.cf

# ルーティングの参照設定
transport_maps = hash:/etc/postfix/transport

# SES接続時に必要となる認証参照設定
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

# 外部SMTP接続時のTLS動作条件
# サンドボックス解除後、SES経由に完全に切り替えるタイミングでencryptに変更する
smtp_tls_security_level = may

　テスト構成では、transportファイルに記述した条件に合致したメールのみSES経由で送信され、その際に限り認証情報が使用されるため、通常の外部送信には影響しません。また、標準のsmtpトランスポートを利用するため、master.cfの設定は不要です。

※テスト段階では、relayhost はまだ設定しません。

4. postfix設定反映と動作確認

設定変更を反映するため、Postfixをリロードします。

[root@exiv ~]# systemctl reload postfix

メールログを確認しつつ、exiv.netドメインのメールアドレスを送信元、IDとして設定したGmailアドレスを送信先としてテストメールを送信します。

[root@exiv ~]# tail -f /var/log/maillog

（ログ抜粋）
Apr  7 04:25:21 exiv postfix/submission/smtpd[140683]: connect from localhost[127.0.0.1]
Apr  7 04:25:22 exiv postfix/submission/smtpd[140683]: 0CA043028581: client=localhost[127.0.0.1], 
sasl_method=LOGIN, [email protected]
Apr  7 04:25:22 exiv postfix/cleanup[140692]: 0CA043028581: message-id=<20260407042522.0CA043028
[email protected]>
Apr  7 04:25:22 exiv opendkim[129742]: 0CA043028581: DKIM-Signature field added (s=default, 
d=exiv.net)
Apr  7 04:25:22 exiv postfix/qmgr[140512]: 0CA043028581: from=<[email protected]>, size=877, 
nrcpt=1 (queue active)
Apr  7 04:25:22 exiv postfix/smtp[140693]: 0CA043028581: to=<[email protected]>, 
relay=email-smtp.ap-northeast-1.amazonaws.com[13.114.114.157]:587,
 delay=0.44, delays=0.14/0.08/0.08/0.14, dsn=2.0.0, status=sent (250 Ok)
Apr  7 04:25:22 exiv postfix/qmgr[140512]: 0CA043028581: removed

IDとして設定したGmailアドレス宛の送信がAmazon SES経由で配送されていることが確認できればOKです。
SES経由で送信したGmailのメールのヘッダを確認しました。

配送経路

Received: from e234-4.smtp-out.ap-northeast-1.amazonses.com (… [23.251.234.4])
        by mx.google.com with ESMTPS …

SES経由で送信されているメッセージであることが確認できます。

SPF判定（送信元IPの正当性）

Received-SPF:pass (google.com: domain of …@ses.exiv.net designates 23.251.234.4 as permitted sender)

envelope-from（MAIL FROM）ドメインを取得、取得した「ses.exiv.net」について、DNSに公開されているSPFレコード（TXT）を参照します。そのSPFレコードに記載された評価ルール（include 等）に基づき、
SMTP接続元IPアドレス（23.251.234.4）が許可された送信元に含まれているかを判定し、結果として「pass」と評価されている状況です。

※ SPFはメールヘッダのFromではなく、SMTPのMAIL FROM（Return-Path）を評価します。

DKIM / DMARC 結果

Authentication-Results: mx.google.com;
       dkim=pass [email protected] …
       dkim=pass [email protected] …
       spf=pass …
       dmarc=pass …

DKIM（自ドメイン）、DKIM（Amazon SES）、SPF、DMARC すべてのチェックを「pass」として評価されている状況です。

Return-Path

Return-Path: <…@ses.exiv.net>

Return-Path（MAIL FROM）には ses.exiv.net が設定されており、配送エラー（バウンス）や苦情通知はこのアドレス宛に返送されます。Amazon SESでは、このReturn-Pathを通じてバウンス情報を受信・解析し、
SNS通知や送信制御（レピュテーション管理）に利用します。

今回はここまで

　Amazon SESのサンドボックス環境において、Postfixから特定の宛先へメールを送信できる状態まで構築しました。残りの作業は以下の通りです。

配信監視の設定（Amazon SNS）
　バウンスおよび苦情を検知できるようにします。
バウンスおよび苦情の対策
　問題のある宛先を記録、以降の送信対象から除外する運用方法を検討します。
サンドボックス解除申請
　利用用途・送信対象・スパム対策・運用体制を整理して申請します。
Postfixの本番設定への切り替え
　transport設定を解除し、すべての送信をSES経由に変更します。
本番送信テスト
　任意宛先への送信および認証結果（SPF / DKIM / DMARC）を確認します。

本記事は、Amazon SESのサンドボックス環境での構築・検証記録として公開します。FCrDNS問題への対策や、Amazon SESを利用したSMTPリレー構成を検討している方にとって、事前検証や構成判断の材料になればと思います。

(つづく)