はじめに
目的
本ドキュメントは、AWS上での25番ポート(SMTP)制限解除の手順と注意点をわかりやすく説明します。実際の申請例や、申請後に必要なメールサーバ・DNS設定、さらには代替策としてのSMTPリレーサービスについても扱います。
対象読者
- AWSでメール送信環境を構築したいエンジニアや管理者
 - 社内でメール配信を始める担当者
専門知識が少なくても理解できるよう、用語は最小限に抑え具体例を交えて説明します。 
本書の使い方
各章は申請の目的、必要な準備、手順、申請後の設定に分けています。第2章以降は順に進めると実務で使える内容です。
注意点
AWSのポリシーや管理画面は変わることがあります。本書は手順の考え方と一般的な流れを示しますので、実際の操作時は最新の画面やAWSの案内を併せて確認してください。
AWSで25番ポートが制限される理由と背景
25番ポートとは
25番ポートはインターネット上でメールをやり取りするための標準的なポート(SMTP)です。特にサーバー同士がメールを受け渡す際に使われます。普段メールクライアントが送信に使う587番や465番と役割が少し異なります。
OP25B(Outbound Port 25 Blocking)とは
OP25Bは送信側の25番ポート通信を制限する仕組みです。ISPやクラウド事業者がスパム対策や迷惑メールの拡散防止を目的に導入します。単にポートを閉じるだけでなく、疑わしい送信を検出して制限する場合もあります。
AWSが制限する主な理由
- スパム送信の抑止:共有環境で1つの悪用が他のお客様のIP評価を下げるリスクがあります。
 - 送信元の信頼性維持:大量送信や不正利用による宛先側での受信拒否を避けたいからです。
 - セキュリティ対策:自動化されたマルウェアやボットによる外向けメール送信を防ぎます。
 
利用者への影響(具体例)
- EC2で自前のメールサーバーを立てても、外部宛てに直接メールが届かないことがあります。
 - メールが相手側でブロックされたり、送信エラーになる場合があります。
 
このような背景からAWSでは初期状態で25番ポートを制限しています。次章でどんな場合に解除申請が必要かを説明します。
25番ポート制限解除の申請が必要なケース
概要
AWSで自前のメールサーバ(Postfixなど)を使って外部へSMTP(ポート25)で直接送信する場合は、事前にAWSへ送信制限解除の申請が必要です。デフォルトでポート25は制限されており、解除しないと接続が遮断されます。
対象の具体例
- EC2インスタンスから外部の受信メールサーバへ直接メールを送信したい場合。例:自社アプリがEC2から顧客へ通知メールを送る。
 - 社内やサービス向けに独自のSMTPサーバを運用する場合。例:社内アカウント管理用のメールサーバ。
 
注意点
- 申請しないまま運用すると、送信時に「接続拒否」や「タイムアウト」などのエラーが発生します。
 - 申請はAWSアカウント単位で行います。利用目的や想定送信量の説明を求められますので、事前に準備してください。
 - 審査で却下されることもあり得ます。代替としてポート587/465やAWS SES、SMTPリレーサービスの利用を検討すると安全です。
 
AWS 25番ポート制限解除申請の具体的な手順
以下は申請の流れと記入例、審査時のポイントをわかりやすくまとめた手順です。
1) AWS公式の申請フォームにアクセス
– AWSサポートページやFAQから「Eメール送信制限解除申請フォーム」へ移動します。サポートセンターの「ケース作成」や該当FAQのリンクをたどると見つかります。
2) 申請フォームで入力する内容(記入例つき)
– 利用目的:自社サービスのユーザー通知メール送信
  例:「サービスの重要な通知・パスワードリセット等の送信」
– インスタンス情報:EC2のインスタンスID、リージョン
  例:i-xxxxxxxx(ap-northeast-1)
– 送信先:自社ドメイン、外部取引先など具体的に記載
– 送信予定数:日/月ごとの想定数を具体的に
  例:1日あたり100通、月間3000通
– スパム対策:SPF、DKIM、DMARCの導入状況、逆引きDNS設定の有無を明記
  例:「SPF、DKIM、DMARCを設定済み。逆引きDNSも登録済み」
– 連絡先:管理者メールアドレスや電話番号
記入のコツ:数字やドメイン名は具体的に書くと審査が早く進みます。
3) 審査・承認待ち
– 申請後、追加質問が来る場合があります。質問には速やかに回答してください。
– 所要時間は数日〜1週間程度が多いです。用途や送信量で前後します。
– 審査で注意されやすい点:不明確な送信目的、DNS設定不備、大量送信の根拠不足です。指摘があれば設定を整えて再提出します。
申請時は記録を残しておくと後の対応がスムーズです。
申請後に必要なメールサーバ・DNS設定
概要
申請が承認されたら、実際にメールを確実に送るためにサーバ側とDNS側の設定を行います。ここでの不備は迷惑メール判定や配信失敗につながります。
メールサーバ設定(例:Postfix)
- 送信ポート:Postfixの設定で送信にポート25を使用するよう指定します(例:master.cfやmain.cfでの設定)。
 - TLS:STARTTLSを有効にし、通信を暗号化します。証明書はLet’s Encryptなどで取得します。
 - 送信ヘッダとリレー:myhostnameやmyoriginを適切に設定し、不要なオープンリレーにならないようにします。
 
重要な認証対策(必須)
- SPF:DNSに「v=spf1 ip4:あなたのElasticIP -all」などを設定し、正当な送信元を示します。
 - DKIM:署名鍵を生成してDNSに公開鍵を置き、メールに署名を付けます。PostfixはOpenDKIMなどと連携します。
 - DMARC:受信先にポリシーを伝えるためにDNSにDMARCレコードを追加します(p=quarantineやp=rejectなど)。
 
DNS設定(逆引きとレコード)
- 逆引き(PTR):Elastic IPに対してPTRレコードを設定します。AWSでは通常、Elastic IPの逆引きをサポート窓口へ依頼してホスト名を割り当てます。
 - Aレコード:メールサーバのホスト名をElastic IPへ向けます(例:mail.example.com A 203.0.113.10)。
 - MXレコード:送信だけでなく受信を行う場合はドメインのMXを設定します。
 
動作確認とチェックリスト
- ポート25に接続できるか(telnet mail.example.com 25 など)を確認します。
 - DNS反映状況をdigやnslookupで確認し、PTR/A/SPF/DKIM/DMARCが正しく見えるか確認します。
 - テスト送信して受信側での迷惑メール判定や署名検証をチェックします。
 
設定が整えば、送信成功率が格段に上がります。丁寧に一つずつ確認してください。
OP25B対策の代替策(SMTPリレーサービス)
概要
AWSで25番ポートの制限に悩む場合、外部のSMTPリレーサービスを使う方法が手軽で効果的です。自社サーバから信頼できるリレーへ送るだけで、配信の到達率や安定性を改善できます。
主要サービス例
- SendGrid:無料枠があり、メールの到達率が高いです。ダッシュボードが充実しています。
 - Mailgun:API連携が柔軟で、開発側のカスタマイズに向きます。
 - Amazon SES:AWSとの連携が強く、コストが低めで運用負荷を減らせます。
 
利用方法(簡単な手順)
- リレーサービスでアカウント作成し、送信ドメインを認証します(SPF・DKIM設定)。
 - 自社サーバからリレーの認証済みSMTPサーバへメール送信するよう設定します(ユーザー名/パスワード、専用ポートやTLS)。
 - リレー側が外部配信を代行し、バウンスや配信レポートを提供します。
 
設定で注意する点
- DNSにSPFとDKIMを正しく追加してドメイン認証を行ってください。
 - TLSを有効にして通信を暗号化してください。
 - 送信量に応じたレート制限や課金体系を確認してください。
 
メリットとデメリット
- メリット:25番ポートに悩まず配信でき、到達率が改善しやすい、運用負荷が下がる。
 - デメリット:コストが発生する、第三者に配信を依存するため設定や監視が必要。
 
SMTPリレーサービスは、申請が難しい場合や手早く安定した配信を望む場合に有力な選択肢です。
まとめと注意点
ここまでのポイントを簡潔に整理します。
1) 申請は必須です
AWS上でポート25で直接送信するには申請が必要です。自前のメールサーバから送る場合や大量通知を出す場合は、まず申請手続きを行ってください。
2) 申請時に書くべきこと
具体的な用途(例:契約通知・パスワードリセット)、見込み送信量(例:月間1,000通)、受信者の同意や迷惑メール対策を明記します。これにより審査が通りやすくなります。
3) 申請後の必須設定
申請が通っても、メールサーバとDNSの設定を正しく行わないと到達率が下がります。具体的にはSPF、DKIM、逆引き(PTR)の設定、受信停止の仕組みの整備を行ってください。
4) 代替案の検討
申請が難しい、到達率を重視したい場合はSMTPリレーサービスの利用を検討してください。配信の信頼性やレピュテーション管理、バウンス処理が楽になります。
5) 最後の注意点
送信量は段階的に増やし、ログと苦情(クレーム)を定期的に確認してください。運用中に問題が出たらすぐに設定や送信ポリシーを見直しましょう。


	









