Amazon SES（Simple Email Service）入門｜メールサーバーをクラウドに移行するSMTP設定と料金ガイド

自社のメールサーバーを運用している方なら、こういった経験があるはずです。「深夜にスパム踏み台にされてIPがブラックリスト入りした」「Postfixの設定を変えたら一部キャリアへのメールが届かなくなった」「ハードウェア更新のたびにIP評判をゼロから積み直さないといけない」。

オンプレのメールサーバーはSMTPの仕組み自体はシンプルに見えますが、SPF・DKIM・DMARCによる送信ドメイン認証、IP評判管理、バウンス処理、キャリアごとの受信ポリシー対応など、地味に手間のかかる作業が重なります。

Amazon SES（Simple Email Service）は、こうした「メール送信インフラの面倒事」をAWSが肩代わりするマネージドメール送信サービスです。この記事では、オンプレのSMTPサーバーと比較しながら、SESの基本的な仕組み・設定手順・料金・運用のハマりポイントを現場目線で整理します。

なぜAmazon SESなのか？オンプレSMTPとの違い

まずSESがオンプレのメールサーバーと何が違うのかを整理しましょう。

オンプレの最大の問題は「送信インフラそのものの維持コスト」です。月に10万通しか送らなくても、サーバーを24時間365日稼働させ続けなければなりません。SESは従量課金なので、送信量が少ない月は費用もほぼゼロに近くなります。

また「IPブラックリスト対応」という頭痛の種がなくなるのも大きいです。AWSの共有IPプールはAmazon自身が評判管理をしているため、自前でIPを育てる必要がありません（送信量が多い場合はDedicated IPという選択肢もあります）。

Amazon SESの基本的な使い方（コンソール操作）

1. 利用可能なリージョンを確認する

SESはすべてのAWSリージョンで利用できるわけではありません。2026年6月時点で主要な対応リージョンは以下のとおりです。

・米国東部（us-east-1）: 最も機能が充実しているリージョン
・米国西部（us-west-2）: 北米向け送信に適す
・欧州（eu-west-1）: GDPR対応を考慮するならここ
・東京リージョン（ap-northeast-1）: 国内システムとの連携や日本のエンドユーザーへの送信に適す

日本のエンドユーザーへのメール送信や、同じVPC内のEC2・Lambdaからの呼び出しなら東京リージョン（ap-northeast-1）が適切です。

2. 送信元ドメインの認証（DKIM設定）

SESでメールを送るには、まず「このドメインからメールを送る権限がある」ことをAWSに証明する必要があります。これが送信元ドメインの認証です。

AWSコンソールで「Amazon SES」→「Verified identities」→「Create identity」に進み、「Domain」を選択して自社ドメイン（例: example.com）を入力します。するとAWSが3つのCNAMEレコードを提示するので、これを自社のDNSに追加します。

# SESが提示するDKIM用CNAMEレコードの例（Route 53やお名前.comに追加する）
# 実際のCNAME値はAWSコンソールに表示されるものを使用すること

xxxxxxxx._domainkey.example.com  CNAME  xxxxxxxx.dkim.amazonses.com
yyyyyyyy._domainkey.example.com  CNAME  yyyyyyyy.dkim.amazonses.com
zzzzzzzz._domainkey.example.com  CNAME  zzzzzzzz.dkim.amazonses.com

DNS反映には最大72時間かかることがありますが、多くの場合は数分～数時間で完了します。AWSコンソールのステータスが「Verified」になれば準備完了です。

合わせてSPFレコードも追加しましょう。既存のSPFレコードにinclude:amazonses.comを追加するだけで対応できます。

3. サンドボックスモードからの脱出

SESアカウントは最初「サンドボックスモード」になっています。この状態では、認証済みのメールアドレスにしか送信できず、送信上限も1日200通・毎秒1通に制限されています。

本番利用にはサンドボックスからの「脱出申請」が必要です。AWSコンソールから「Request production access」を行い、以下の情報をAWSに提出します。

・ユースケースの説明: どんなメールを誰に送るか（例: Webサービスのトランザクションメール、会員へのメルマガ）
・バウンス・苦情への対処方針: バウンス率をどう管理するか
・送信量の見込み: 月間の見込み送信数

申請から承認まで通常24時間以内です。きちんとユースケースを説明すれば問題なく通過します。

4. SMTP認証情報の作成とアプリへの組み込み

SESにはSMTPインターフェースがあり、既存のアプリからほぼ設定変更だけで切り替えられます。AWSコンソールで「SMTP settings」を確認すると、エンドポイントが表示されます。

# SES SMTPエンドポイント（東京リージョンの場合）
SMTPエンドポイント: email-smtp.ap-northeast-1.amazonaws.com
ポート: 587（STARTTLS）または 465（TLS/SSL）

# Postfixからの移行例（/etc/postfix/main.cf の relayhost を変更する）
relayhost = [email-smtp.ap-northeast-1.amazonaws.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

SMTP認証情報（ユーザー名とパスワード）はSESコンソールの「SMTP settings」→「Create SMTP credentials」から作成します。注意点として、これはIAMの通常のアクセスキーとは異なるSES専用の認証情報です。IAMコンソールからは作成できません。

料金の仕組み（コスト感覚）

SESの料金は非常にシンプルな従量課金です（2026年6月時点）。

月10万通送った場合のコスト試算（2026年6月時点）：

・SES料金: 100,000 ÷ 1,000 × $0.10 = $10.00/月（約1,500円）
・オンプレSMTPサーバー: サーバー代＋電気代＋管理工数（数万円～）

また、EC2インスタンスからSESを使う場合は最初の62,000通/月が無料枠として提供されています。小規模なアプリであれば実質コストゼロで使い始められます。

応用・実務Tips

【重要】バウンス率と苦情率の管理

SESで絶対に外せないのがバウンス（配信不能）率と苦情（スパム報告）率の管理です。AWSはこの2つの指標を常時監視しており、閾値を超えるとアカウントの送信能力が制限・停止されます。

・バウンス率の警告閾値: 5%（これを超えると警告、10%を超えると制限）
・苦情率の警告閾値: 0.1%（0.5%を超えると制限）

メーリングリストを使っている場合は、定期的にサプレッションリスト（バウンスや苦情を出したアドレスのリスト）を管理する仕組みを実装しましょう。SESにはアカウントレベルのサプレッションリストが組み込まれており、バウンスや苦情があったアドレスへの誤送信を自動でブロックします。

設定セットでメール種別ごとに追跡する

SESの「設定セット（Configuration Set）」を使うと、メールの種類ごとに送信イベント（配信成功・バウンス・苦情・開封・クリック）を追跡できます。

例えば「トランザクションメール用設定セット」と「メルマガ用設定セット」を分けておくと、バウンス率をメール種別で把握でき、問題が起きたときの切り分けが容易になります。

EC2からの送信はSES APIを使う

EC2上のアプリからメールを送る場合は、SMTPではなくSES APIを使うのがパフォーマンス的に有利です。Python（boto3）・Node.js・Javaなど主要な言語のSDKが揃っています。

# Python（boto3）でSES APIからメール送信する最小例（AWS CLI環境: ap-northeast-1）
import boto3

client = boto3.client('ses', region_name='ap-northeast-1')

response = client.send_email(
    Source='sender@example.com',
    Destination={
        'ToAddresses': ['recipient@example.com'],
    },
    Message={
        'Subject': {'Data': 'テスト送信', 'Charset': 'UTF-8'},
        'Body': {
            'Text': {'Data': '本文テキスト', 'Charset': 'UTF-8'}
        }
    }
)

print(response['MessageId'])

IAMロールにEC2インスタンスを紐づけておけば、アクセスキーをコードに埋め込む必要がありません。IAMロールには ses:SendEmail と ses:SendRawEmail のみを付与する最小権限設計が推奨です。

よくあるトラブルと対処法

「Email address is not verified」エラーが出る

原因: サンドボックスモードのまま、認証していないアドレス宛てに送信しようとしている。

対処: テスト段階では宛先メールアドレスをSESで認証するか、本番利用のためにサンドボックス脱出申請を行う。

メールは送れているがGmailの迷惑メールに入る

原因: DKIMやDMARCが未設定、または送信ドメインとFromアドレスのドメインが一致していない。

対処: SESコンソールでDKIM設定が「Verified」になっているか確認する。さらにDNSにDMARCレコードを追加する（最初は p=none で様子を見てから段階的に強化するのが定石）。

# DMARCレコードの追加例（TXTレコードとしてDNSに設定）
_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

# p=none     → 監視のみ（メール拒否しない）
# p=quarantine → 認証失敗メールを迷惑メールへ
# p=reject   → 認証失敗メールを完全拒否

バウンス率が急上昇した

原因: 古いメーリングリストを使い回した、無効アドレスへの一括送信、送信先が長期間非アクティブになった、など。

対処: SESのサプレッションリストを確認してバウンスアドレスを洗い出す。今後は新規登録時のダブルオプトインや定期的なアドレスクリーニングを実施する。

東京リージョンからの送信でタイムアウトが多発する

原因: EC2のセキュリティグループで送信ポート（587や465）がアウトバウンドで許可されていない。

対処: セキュリティグループのアウトバウンドルールに以下を追加する。

# EC2セキュリティグループのアウトバウンドルール追加（AWS CLI）
aws ec2 authorize-security-group-egress   --group-id sg-xxxxxxxxxxxxxxxxx   --protocol tcp   --port 587   --cidr 0.0.0.0/0   --region ap-northeast-1

本記事のまとめ

Amazon SESについて、オンプレのSMTPサーバーとの違いを交えながら整理しました。

Linuxサーバー上でPostfixを自前管理していた経験があれば、SESへの移行は思ったよりずっとスムーズです。sasl_passwdファイルの設定感覚がそのまま使えますし、DKIM対応もOpenDKIMを自前で設定する手間が一切かかりません。Linuxサーバー管理の基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。